Windows 2000 Pro/Windows XP New Project I/O Device Driver

[ADAMRYANREST]

Hello M8's

I have decided to start a new project based on the common faults and programming of windows 2000 pro/windows xp.
I started this project because the siemens maxfron dongle and soft is not communicating with each other, A problem that plagues Windows NT/2000 and Windows XP, is it's strict control over I/O ports.

Unlike Windows 95 & 98, Windows NT/2000/XP will cause an exception (Privileged Instruction) if an attempt is made to access a port that you are not privileged to talk too. Actually it's not Windows NT that does this, but any 386 or higher processor running in protected mode.
This is because windows 2000 pro was not intentionaly designed for the use of applications and com+ input/output ports are limited and thus communication.

The aim of my project is create a Virtual Device Driver that will communicate with the ports and write hex address for each port mapped.
Accessing I/O Ports in protected mode is governed by two events, The I/O privilege level (IOPL) in the EFLAGS register and the I/O permission bit map of a Task State Segment (TSS).
Under Windows NT, there are only two I/O privilege levels used, level 0 & level 3. Usermode programs will run in privilege level 3, while device drivers and the kernel will run in privilege level 0, commonly referred to as ring 0.

This allows the trusted operating system and drivers running in kernel mode to access the ports, while preventing less trusted usermode processes from touching the I/O ports and causing conflicts. All usermode programs should talk to a device driver which arbitrates access.
This is basicly the permissions set up in control pannel /users, the I/O permission bitmap can be used to allow programs not privileged enough (I.e. usermode programs) the ability to access the I/O ports.
When an I/O instruction is executed, the processor will first check if the task is privileged enough to access the ports. Should this be the case, the I/O instruction will be executed. However if the task is not allowed to do I/O, the processor will then check the I/O permission bitmap.

The I/O permission bitmap, as the name suggests uses a single bit to represent each I/O address. If the bit corresponding to a port is set, then the instruction will generate an exception however if the bit is clear then the I/O operation will proceed. This gives a means to allow certain processes to access certain ports. There is one I/O permission bitmap per task.
If we was to use using a driver such as PortTalk it can become quite inefficient.
Each time an IOCTL call is made to read or write a byte or word to a port, the processor must switch from ring 3 to ring 0 perform the operation, then switch back.
If your intentions were to write, for example a microcontroller programmer which is programmed serially using a parallel port pin, it would make better sense to send a pointer to a buffer of x many bytes.
When a Windows 32 bit program is started using CreateProcess(), it will return the ProcessID for the 32 Bit Program. This is passed to the Device Driver using an IOCTL Call. DOS programs do not have their own ProcessID's. They run under the Windows NT Virtual DOS Machine (NTVDM.EXE) which is a protected environment subsystem that emulates MS-DOS. When a DOS program is called using this program, it will get the ProcessID for NTVDM.EXE and as a result changes NTVDM's IOPM.

If NTVDM is already resident (if another DOS Program is running) it will return a process ID of zero. This doesn't cause a problem if the NT Virtual DOS Machine's IOPM is already set to allow any IO operation. If the first DOS program was called from the command line without using "AllowIo", the NTVDM will not have the modified IOPM.
When the device driver has the ProcessID, it finds the pointer to process for our newly created program and sets the IOPM to allow all I/O instructions. Once the ProcessID has been given to our PortTalk device driver, the allowio programs finishes. Running a DOS/Win 3.1 program normally under NTVDM.EXE should not create any major problems.
NTVDM will normally intercept most IO calls and check these resources against the registry to make sure they are not in use. Should they be in use, a message box will pop as simular to the one shown here, giving the user the option to terminate the program or ignore the error. If the user chooses to ignore the error, access will NOT be granted to the of*****ng I/O Port.

To help me with more information for my project i need more resources if anyone could point me in the direction of a download link of Microsoft Windows NT Device Driver Kit. I also need to download Microsoft Win32 SDK too.

Also if anyone has any suggestions, comments etc.. please please let me know. . .

This is a small project and i am sure if we work together we will have a 1005 working device driver solution for the communication of hardware 2 software in a windows 2000/NT enviroment.

Best Regards

Adam Rest

Vast Gsm Team

[email protected]

[Lead]

Don't waste your time doing what has already been done. Your ideas are correct, but they are already implemented. Try looking for utilities like UserPort or PrintIO...

Btw, there is one more problem with the ****ing XP, just follow the following link: http://www.elnec.sk/sw/winxp1uk.htm

Regards, Lead.

[ADAMRYANREST]

Link Is Dead

Regards

Adam Rest

Vast Gsm Team

[Lead]

If you were not so lazy, you would find out that the link is not dead, but has changed.

Here it is: http://www.elnec.sk/appnotes/winxp1uk.php