From: benny AT crocodial DOT de (Benjamin Riefenstahl) Subject: Re: Accessing hardware -- nasm and gcc 12 Mar 1998 23:04:45 -0800 Message-ID: <3507C26D.AAFFA9D.cygnus.gnu-win32@crocodial.de> References: <199803111122 DOT MAA21506 AT mailnews DOT kub DOT nl> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: gnu-win32 AT cygnus DOT com Hi Tijs, Tijs Michels wrote: > Dear Paul, > 20-11-1997 you wrote: > > Under Win95, the programmer can directly access any and > > all hardware without any sort of special case scenarios > > outside of those required to understand (programmatically > > speaking) the hardware in question (things such as h/w > > specs available with a Video Card). This is probably overstating the possibilities (see your own reaction). There still are hardware drivers running in Win95 and they do use the facilities of the i386 to virtualize ports, service interrupts and use memory protection for various purposes. A DOS application in real mode could assume it was in sole control of the machine, an application running on Win95 usually can not. > > Under NT this is not the case. Right. As far as I see it the difference is that on WinNT only some device driver classes are allowed to do hardware accesses. On Win95 this is not restricted. Still the application has to share the system with other components, some of which will have protected resources that an application might want to use. > Could you please point me to some docs on how to access hardware > under Win95 using Cygwin32, or better still, to some examples? ? You don't access hardware through cygwin32, you use cygwin32 to avoid it ;-) You can of course use cygwin32 to give you an application environment (startup code, linking to API functions) like you did in the code you posted. Whatever rules there are for hardware access, do not come from cygwin32, but from the OS and the hardware platform. These areas are so large that you get the best information from the official Microsoft channels (as sad as that sounds). Independent efforts, which were the best source of information in DOS and sometimes in Win3.x, have a very hard time to generate new information for Win95 and WinNT. Most of them are only re-phrasing the official docs (which often is a good step forward already, as MS' docs are often diffcult to interprete correctly). > Back in the DOS years I used to code all my programs in pure > assembly. That was great for accessing hardware. Now that I've > upgraded to the Win95\Cygwin32 platform writing to a port or issuing > a simple interrupt seems impossible. You can write to ports in Win95. What will happen when you do this depends on whether some device driver is trapping the port and if it is, what is does with your request. Given that a 32 bits application is not *supposed* to access hardware, it's unlikely that much usefull will happen. You can not issue interrupts in Win95 from a 32 bit application. Interrupts issued from 32 bit applications would need to be caught by 32 bit interrupt handlers, and there is no system in place in Win95 to install such handlers. So by default the interrupt will be redirected to a 16 bit handler and this is most likely to crash, if only because of different assumptions about stack layout and the location of the stack. > I tried the following approach. > > ... [code to access VGA (?) registers snipped] ... > > The result is mijn.exe, for sure. Neither nasm nor gcc complains. Right. From the development environment side this seems to work. If I was you I would like to check in gdb, that the executable really has linked the code correctly, but I'd guess it will be ok. > The executable runs, both from the command.com prompt and from the > bash prompt, and the system doesn't crash. But nothing happens!! I'm not sure what you think should happen, but if these are VGA registers, the video driver is most likely to have trapped them. You would have to ask the vendor of the driver or debug his code with a kernel debugger, to find out what actually happens. > It doesn't seem to get through to the ports. When I compile mijn.asm as > a .com program and run it from command.com, however, dark blue > becomes bright blue, just as it should! That runs in either real mode or virtual x86 mode. In the first case you have the machine to yourself, in the second case the hardware drivers make every effort to make it *appear* as if you have the machine to yourself. That's after all why it's called virtual. > I know that _The Undocumented PC_, Frank van Gilluwe says > (page 43): > ... > Two other processor modes, Protected and > Virtual 86, can limit access to I/O. This > means that an advanced operating system such > as Windows or OS/2 can control who is allowed > to read or write I/O ports. [...]" > > However, ports 3C8h and 3C9h are not listed as such. By definition there is no complete list. Being that most hardware that you have installed will have it's own drivers (often already included in the retail Win95 distribution), there is no definitive list on paper of resources already reserved. To use a resource you either have to assume that the resource is free, or you have to use system services to determine it's current status. The latter implies that you write to the system specs and access the hardware through system authorized channels. Applications that make direct hardware accesses are by (Microsoft's) definition not written to the these specs. The primary sources I am aware of for docs and help: - MSDN - Microsoft Developer Network, contains all of the official docs. For hardware access you will probably want the DDK's which are free with MSDN but must be ordered separately. There are different levels of MSDN, I don't know at the moment what you would need. - comp.os.ms-windows.programmer.vxd - The newsgroup for developing hardware drivers for Win95. It's FAQ is very usefull and includes links to the important books written on the subject. OTOH, if you are only interested in these matters as a hobby you may want to stick to DOS. There is no problem writing and running DOS programs, and if V86 mode is not enough for you, you can still boot plain DOS 7. hope this helps, benny ====================================== Benjamin Riefenstahl (benny AT crocodial DOT de) Crocodial Communications EntwicklungsGmbH Ophagen 16a, D-20257 Hamburg, Germany - For help on using this list (especially unsubscribing), send a message to "gnu-win32-request AT cygnus DOT com" with one line of text: "help".