Jump to content
MSFN is made available via donations, subscriptions and advertising revenue. The use of ad-blocking software hurts the site. Please disable ad-blocking software or set an exception for MSFN. ×

Windows 9x driver programming


Recommended Posts

I'm a fairly experienced C, C++, and Assembly programmer and want to experiment with diving into the inner workings of Windows 9x drivers. Is there any publicly available documentation specifically on the format of VxD files, API references, and toolchains for compiling and testing them?

  • Like 1
Link to post
Share on other sites

Oh cool. I'll take a look at the DDK in my free time.

Is there any way to programmatically load and unload VxDs at runtime? For example, the popular hex editor HxD does this in order to have raw disk access on Windows 9x.

Edited by CamTron
Link to post
Share on other sites

I figured it out. This article was pretty helpful https://www.drdobbs.com/windows/building-vxds-in-windows-95/184410047 Oddly enough, the program loading the vxd has to be in the same directory as the vxd, and when using CreateFile to open the vxd, the filename passed in has to be \\.\mydriver.vxd instead of the full path to it for some reason.

I also find it interesting that most example drivers in the Windows 95 DDK are written in assembly with some of them partially in C. WDM and modern WDF drivers are almost always written in C.

Edited by CamTron
  • Like 1
Link to post
Share on other sites
On 2/3/2021 at 3:08 PM, CamTron said:

Oh cool. I'll take a look at the DDK in my free time.

it is not enough... you MUST also read ALL ddks and sdks begin from Win 3.0 and OS/2 for better understanding internals legacy Windows systems...

Link to post
Share on other sites

oh, i forget... you also need read Ralf Brown Interrupt List, TechHelp, etc.

also you need understand, that legacy Win based on DOS, and can make calls into DOS and BIOS layer at any time...

Link to post
Share on other sites

The biggest thing (obstacle) about driver programming to my knowledge is knowing how the hardware you're writing a driver for actually works. I guess if Linux kernel has a driver for particular piece of hardware, hints could be looked up in its source code.

Link to post
Share on other sites

I'm currently planning to make a driver for the VirtualBox GPU, in order to make it support resizing the guest resolution. This is very simple hardware, and is based on the one used in Bochs, which is very similar to VESA, and the osdev wiki has some good documentation.

What debugging tools are recommended for driver development? I'm currently playing around with SoftICE. Is there anything better?

I've written a basic driver skeleton, and gotten to the point where my driver can be installed in Device Manager, though it causes the system to hang on startup.

Link to post
Share on other sites

I'm a bit confused on a few things. According to the documentation,

Quote

A display minidriver for the Microsoft® Windows® 95 operating system is a DLL that you write to support the translation of graphics commands between GDI and the display adapter. Your minidriver will follow the same general format as a full device driver, but will reroute most GDI calls to the DIB engine. If you cannot use the DIB engine, you must write a full display driver.

From what I know, DLLs are always protected mode ring-3 and don't have direct access to ports and memory mapping IO, which is needed to set resolutions and draw things to the screen. If a minidriver is just a DLL, do I even need to write a VxD at all? I'd love to take a look at the source to the Bearwindows Universal VBE driver if it wasn't closed source to see how it was implemented. It apparently has a .vxd and a .drv file (I'm not entirely sure what. drv is).

Link to post
Share on other sites

VBE.vxd is not needed for VBEMP to work. VBEMP.DRV is enough. It's the minidriver I think.

Minidriver is what I think is seen at the top of the list if you look at a GPU Driver File Details list in Device Manager:

spacer.png

Link to post
Share on other sites

On closer inspection, it seems that the .drv files are what the DDK refers to as minidrivers and appear to be 16-bit DLLs but with the .drv extension. I'm still not sure how the minidriver, being ring 3 code, is supposed to access the display hardware directly.

Link to post
Share on other sites

To test things out, I copied the source for the FRAMEBUF example and compiled it. However, I can't seem to get Windows 98 to actually load my driver. It installs fine in Device Manager, but when I reboot and run the "mod" command in SoftICE, it shows that Windows is using vga.drv, and my vboxdisp.drv doesn't show up in the list of loaded modules. I checked in Device Manager, and it says "This device is working properly", and shows that my vboxdisp.drv is correctly installed, but it secretly isn't using it. Is there any way to find out what's going wrong?

vboxdisp.zip

Edited by CamTron
Upload files
Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
  • Recently Browsing   0 members

    No registered users viewing this page.

×
×
  • Create New...