|
I have some device simulation framework code in vb.net which I have uploaded here: https://kinectmultipoint.codeplex.com/releases/view/107451[^]
Does anyone in here know enough to figure out what's wrong with the code? (In vbscript it works just fine that's why iam scratching my head). I have tried creating com objects before in vb.net. My best guess is I am using a wrong type or class somewhere in code.
jeffery
|
|
|
|
|
In a preemptive environment, does a single CPU instruction execute atomically, even if it uses more than one clock cycle?
Or can an instruction be preempted during its second of, say, three clock cycles?
The difficult we do right away...
...the impossible takes slightly longer.
|
|
|
|
|
As far as I know it should execute completely to preempt. If the instruction can be halted in the middle of the process I am pretty sure it will need to be considered as not being executed at all (as the process of changing from one process to another will copy all the registers, including the stack pointer).
So, even if at the hardware level it may be interrupter without completing, I am sure we will never see partial values lost (but I really believe the interrupt itself will only work at the next instruction).
|
|
|
|
|
I just searched and this link gives a good information: http://www.sltf.com/articles/pein/pein9505.htm[^]
There is a part that says this: "Interrupt processing has some basic requirements from the CPU. Before it can respond to an interrupt, the processor must wait for an "interruptible" state in its processing. For example, if the processor's writing to memory, it must wait until the write is done before processing the interrupt."
So, it will never interrupt in the middle of a instruction. The instruction itself is always atomic.
|
|
|
|
|
Ah, I see. Thank you for that information. 
The difficult we do right away...
...the impossible takes slightly longer.
|
|
|
|
|
Sorry for the late reply, but I had to chime in here:
It is a common misunderstanding, unless an instruction is designed to be atomic (like x86 CMPXCHG or 680x0 TAS), an instruction can be interrupted mid-execution (e.g. INC [mem] can be interrupted after the read and before the write of the incremented value. This moment would be considered interruptible even tough the operation is not completed). If you need guaranteed atomic operation, you have to either use an instruction that is designed as atomic or you have to implement an access control mechanism that is based on these atomic operation around your non-atomic operations. Semaphores etc. are based on these guaranteed atomic operations to guard complex, i.e. non-atomic, operations.
On a side note, this concept becomes even worse when executing with multiple CPUs or cores where several instructions are executing simultaneously and they can interfere with each other even without preemption. In this situation atomically-designed operations still guarantee atomic execution while others are becoming indeterministic as they are executed in parallel.
|
|
|
|
|
Why break their WDM model? Dumb if you ask me.
==============================
Nothing to say.
|
|
|
|
|
Yep, I guess thats about 2000 miles above the heads of most CP members.
|
|
|
|
|
how do i interface with the gprs modem using j2me without using a pc...i want to use it to send a sms through the gprs modem in a home security system to a predefined mobile number...pls help me regarding this...
|
|
|
|
|
You will need an interface to the modem, normally serial (if it is uart based) or if USB some way to handle the two bulk and one interrupt pipes it will have.
You need to do this because you need to send (most likely) AT commands to it to connect it, enter a PIN, and send the SMS.
And sending an SMS is a right POTA with AT commands. But now you know you can google 'SMS AT commands' and see what you find.
==============================
Nothing to say.
|
|
|
|
|
And having given you the information you need to do this you cant even reply and say thanks.
Dear oh dear.
You should have tried learning to write SW bafore the internet existed. You had to actually work things out yourself rather than getting other people to do it for you.
==============================
Nothing to say.
|
|
|
|
|
And some one downvotes me because I try to correct someones manners....
You really thnk that I should give away the experience of many decades writing software and not be pissed off when people dont even have the courtesy to say thankyou?
modified 10-Jul-13 8:18am.
|
|
|
|
|
Hello, I need help of friends or community experts with this problem:
We have about 100 PCs of the same brand and model manufactured in 2010. I need to change in all these PCs, periodically and manually, the system and user passwords through the BIOS and would like to automate this procedure through a software and had the following idea:
The motherboard manufacturer sent me a program to read and write the CMOS. I starts with the setting up these passwords on a single PC, saving all your content to a file and after with this program, I write de CMOS to the others machines. Detail: this program is to be used with a boot disk with DOS.
As I would like to carry this procedure through the central server, copying the file with new CMOS data to a specific folder existent on all machines. In each PC there is a process running on Windows XP SP3 that as soon as received the file, make the reading the contents, writing the new passwords in its CMOS, deletes the file from the folder and restarts yourself. The theory should work, but not, inclusive on the same machine where I created the file. What happens is that every time I update the CMOS, the changed settings are retained, but the passwords always come back clean, i.e. without any protection to access to BIOS.
Now I'm basing my work on one program called CmosPwd which can be found on the site www.cgsecurity.org, but no options works properly on the motherboard that we have. Our platform apparently uses the Award BIOS 6.00 PG as base to these chinese mother boards. Tried new contact with the manufacturer, but they do not provide a map of the structure of the CMOS. I discovered that, comparing the various files, passwords are not written in ASCII mode only 5 bytes at offset 0x40, that I believe to be your CRC, as showed below:
CMOS DUMPS WITH PASSWORDS:
SYSTEM: 11111111
USER : 22222222
CMOS Bank 0:
00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F
-----------------------------------------------
0: 59 00 55 00 14 00 05 02 05 13 26 02 40 80 08 00
1: 40 f0 00 00 02 80 02 00 04 14 00 00 00 00 00 00
2: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 01 fc
3: 00 04 20 80 00 00 00 00 00 00 00 00 00 00 00 00
4: 59 00 55 00 14 00 05 02 05 13 26 02 40 80 08 00
5: 40 f0 00 00 02 80 02 00 04 14 00 00 00 00 00 00
6: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 01 fc
7: 00 04 20 80 00 00 00 00 00 00 00 00 00 00 00 00
CMOS Bank 1:
00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F
-----------------------------------------------
0: 59 00 55 00 14 00 05 02 05 13 26 02 40 80 08 00
1: 40 f0 00 00 02 80 02 00 04 14 00 00 00 00 00 00
2: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 01 fc
3: 00 04 20 80 00 00 00 00 00 00 00 00 00 00 00 00
4: 59 00 55 00 14 00 05 02 05 13 26 02 40 80 08 00
5: 40 f0 00 00 02 80 02 00 04 14 00 00 00 00 00 00
6: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 01 fc
7: 00 04 20 80 00 00 00 00 00 00 00 00 00 00 00 00
SYSTEM: AAAAAAAA
USER : BBBBBBBB
CMOS Bank 0:
00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F
-----------------------------------------------
0: 51 00 01 00 15 00 05 02 05 13 26 02 00 80 08 00
1: 40 f0 00 00 02 80 02 00 04 14 00 00 00 00 00 00
2: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 01 fc
3: 00 04 20 80 00 00 00 00 00 00 00 00 00 00 00 00
4: 51 00 01 00 15 00 05 02 05 13 26 02 40 80 08 00
5: 40 f0 00 00 02 80 02 00 04 14 00 00 00 00 00 00
6: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 01 fc
7: 00 04 20 80 00 00 00 00 00 00 00 00 00 00 00 00
CMOS Bank 1:
00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F
-----------------------------------------------
0: 51 00 01 00 15 00 05 02 05 13 26 02 40 80 08 00
1: 40 f0 00 00 02 80 02 00 04 14 00 00 00 00 00 00
2: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 01 fc
3: 00 04 20 80 00 00 00 00 00 00 00 00 00 00 00 00
4: 51 00 01 00 15 00 05 02 05 13 26 02 40 80 08 00
5: 40 f0 00 00 02 80 02 00 04 14 00 00 00 00 00 00
6: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 01 fc
7: 00 04 20 80 00 00 00 00 00 00 00 00 00 00 00 00
Has anyone had a problem like this and got a simple and cheap solution, or would have any hint to solution this? I appreciate some kind of help.
Thanks so much,
Edison Fernando.
Brazil.
|
|
|
|
|
Any technical problem is a challenge, but though I don't have an answer in this case, I'm sure you'll appreciate that you probably won't get one (here) when your aim is to remotely change passwords.
|
|
|
|
|
Contact the manufacturer of the machines. They'll usually have a BIOS command line tool that can import/export the contents or provide some other method for what you're doing.
You're not going to get code to do this here.
|
|
|
|
|
HP & DELL provide BIOS 'replication' tools.
But if your machines aren't those don't assume they will work on yours.
They also need DOS (not Windows) 
|
|
|
|
|
Hello friends,
First, thanks for the posts. I'm feeling at obligation to inform you some progress I did today.
I discovered some part of mistery. After many tries to save/restore passwords in CMOS, maybe some tool I had used for tests, did make a mess into CMOS as I posted before.
This is showed in dump where there are many bytes zeroed. I did make a hard reset on CMOS's battery and the program sent by motherboard maker, finally started to work correctly. Now I can do a copy of a configured CMOS and duplicate it on another PC or for himself, successfully. The motherboard we have, are OEM Gygabyte with security chip that encrypts the CMOS, if this feature was enabled on BIOS (default). I would also say that the manufacturer's program worked even on my home computer with a Gigabyte P35 Board with success, then I assume that it works for almost all Gigabyte boards.
A new correct dump of CMOS banks now seems like this:
SYSTEM: 'password'
USER : 'password'
CMOS Bank 0:
00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F
-----------------------------------------------
0: 21 20 26 00 11 bd 07 06 05 13 26 02 50 80 00 00
1: 40 8b f0 00 03 80 02 c0 ff 2f 2f 40 00 00 00 00
2: 00 00 00 00 00 00 ff ff 10 00 00 fe ff ff 09 a7
3: c0 ff 20 00 bc db 8e 5c c1 0e b8 0f cb d1 da cf
4: 0f 53 00 95 00 00 00 02 10 01 21 00 01 00 00 00
5: 00 00 00 0d 0a 00 00 00 00 00 c8 24 00 00 00 00
6: 00 00 00 03 00 20 13 2f 00 00 00 00 00 ff ff 00
7: 2f 00 00 00 00 00 00 00 00 fc 00 00 cc 05 92 0f
CMOS Bank 1:
00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F
-----------------------------------------------
0: ff df ff df c0 ff ff ff ff ff ff 8f 00 c0 09 09
1: 70 b0 dc 6e 77 7b c9 c8 70 b0 dc 6e 77 7b c9 c8
2: 00 00 00 00 00 00 00 00 7a c0 ca de b2 e6 c8 01
3: 10 86 80 05 00 24 00 00 00 00 00 d0 ff 13 10 0d
4: 85 4a 32 a5 39 33 02 01 02 33 33 55 56 00 00 00
5: 00 10 00 cf 8f 9f 8f 8f 4f 5e 43 9f ce c7 43 cb
6: 4f 17 f0 f4 db 8d c5 8f cc cf df 4b cd d1 cb f7
7: cf cb ef c7 c8 cf 5d 43 0a d4 8f 8f df ce cf dd
The offset for passwords (on this PC) is located at bank 1,
offset 0x10 up to 0x1f:
70 b0 dc 6e 77 7b c9 c8 70 b0 dc 6e 77 7b c9 c8
p a s s w o r d p a s s w o r d
The letter ' a ' inside the CMOS is encrypted as 0xB0, but on another occasion, for example, if we change the password for ' senha ' (password in Portuguese Brazil), the letter ' a ' may vary for other value, as I realized today.
I know that the first 16 bytes are for the RTC and the program should not duplicate them. So, there are only 112 bytes to find out if all of these are written sequentially by the program, or at worst, the program computes and writes a CRC before rewrite the CMOS.
This will be the next challenge and the last will be how to do this within Windows and not through the DOS.
Well, the people say that when we got 50, we turn children again. In my case, specifically, this is not true: I just went back to brush the bits !!
But it is the best thing to keep the mind always "insane", don't you think?
|
|
|
|
|
edinando wrote: This will be the next challenge and the last will be how to do this within Windows and not through the DOS.
Well, there's a little problem with that. You'll have to rewrite this application from scratch and supply a device driver to pull this off. User mode applications do not have any access to the hardware, hence the need for a driver.
If you've got the complete specs for reading/writing the CMOS on a Gigabyte board, the ability to write and debug kernel mode code, specically device drivers, and can write said device drivers in C (cannot use C#!), you should be able to pull this off.
|
|
|
|
|
My first post
I am building a DRO reader that will send 3, 8 bit data bytes to a LPT port, for my VB6 code I will be writing.
I know that the serial port has a good size buffer.
But do not know if and or the size of the LPT buffer is?
Did a quick search but no luck
Oldhat
|
|
|
|
|
The basic Line Print Terminal connector (parallel port) pin function specifies pins 2 - 9 for data bits 0 - 7. So I suppose you need to make a distinction between the hardware and the software you might be using. with the hardware accepting 1 byte, buffer size in your software - whatever that is - is now the question you need to address.
|
|
|
|
|
HI guys,
I m using Dell E6500 Laptop and wanted to know the cache memory information.. Can u help me that where to get the required information?? I am using Windows 7 64bit...
Regards,
|
|
|
|
|
Do you mean processor cache. L1, L2, L3 ?
copy the code from this link into Notepad, edit the drive letter for input file and output file, and Save As hw-info.vbs
create the input file named in the script, you only need to put a single dot in the file, in order to get local computer info. Save it to the same location as the .vbs file.
double click the .vbs file, or open Command Prompt (cmd.exe) and type cscript hw-info.vbs
"It's true that hard work never killed anyone. But I figure, why take the chance." - Ronald Reagan
That's what machines are for.
Got a problem?
Sleep on it.
modified 19-Apr-13 5:17am.
|
|
|
|
|
|
Oops. 
"It's true that hard work never killed anyone. But I figure, why take the chance." - Ronald Reagan
That's what machines are for.
Got a problem?
Sleep on it.
|
|
|
|
|
Thanks, looks interesting.
Use the best guess
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
