The task of developing custom applications that access custom hardware can be daunting for even the most seasoned application developer and especially for someone who has just learned developing applications using Visual Basic and similar RAD tools. Here in this article I present an alternative way that may help even the non-programmers to do what they want. That is to develop a custom UI and then access a specific piece of hardware that is connected to their machine.
Programming Custom Hardware for Windows - The Design (Page 2 of 4 )
In order to meet all the requirements above and to get all the questions answered we need to design one solution that we can reuse on application-by-application basis. In the figure below (Figure 1) you can see the conceptual representation of the link between a DLL and a process using it. What we need to do is to exploit this flexible architecture!
What happens behind the scene is that the DLL is loaded as a separate module in the memory and is mapped in the address space of each process that loaded it. There can be n number of processes using a DLL at the same time. So what advantage do we get? Trust me its more than just one!
First, by careful design of the DLL we can make it reusable by different application. For example if we place the basic functionality of Just Reading and Writing to ports we can use it probably in any application in Visual Basic if required.
Secondly, if somehow we can make the DLL execute I/O instructions correctly It's not possible to execute I/O instructions (or, I should say, any of the instructions marked privileged in a user mode process on NT family of systems), then any of the applications that link to our DLL for performing I/O would be able to perform I/O as they'd do on Windows 95/98 operating systems without generating an exceptions.
On the x86 CPU (above 386) family the instruction set contains a set of instruction marked privileged and the hardware also provides four different privilege levels in which code can execute, generally known as Ring0 through Ring3. Windows 95 and 98 doesn't make use of these advanced features because the design goal of Windows 95 was not robustness and security but to get the system running with minimal resources. On the contrary, the Windows NT or any member of NT family uses these privilege levels for secure execution of code and defines two modes for code execution namely, the user mode and the kernel mode. The Kernel mode is implemented using the Ring0 and the User mode is implemented using the Ring3. As the applications we create run in the user mode or as Ring3 code it doesn't have the permission to execute I/O instruction and if an attempt is made a privileged instruction execution exception is raised terminating the program. For more details you can refer to the article by Dale Roberts on Direct Port I/O and Windows NT published in DDJ may 1996 issue.