Subject: Re: Accessing hardware -- nasm and gcc
From: [email-masked] (Benjamin Riefenstahl)

12 Mar 1998 23:04:45 -0800
Message-ID: <[email-masked]>
References: <[email-masked]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
To: [email-masked]

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 ([email-masked])
Crocodial Communications EntwicklungsGmbH
Ophagen 16a, D-20257 Hamburg, Germany
-
For help on using this list (especially unsubscribing), send a message to
"[email-masked]" with one line of text: "help".