CamTron

Yes, that's basically what I figured out. I'm using Linux, and my script creates a virtual null modem. I have the Windows 98 VM running in VirtualBox, which is connected to one end of the null modem, and I'm running the SERIAL.EXE program in DOSEmu (a DOS emulator for Linux), which is connected to the other end of the null modem and allows me to view and control SoftICE. The virtual serial connection is a bit slow, but at least now I can see and control the debugger without its output getting messed up by my WIP graphics driver.

Oh, didn't realize I was hitting a limit on attachments. Would it be possible to make the forum display a message other than Error Code -200 when that happens?

So there are a few problems using the VT100 serial, mainly that many of SoftICE's keyboard shortcuts (such as the F1-F12 keys) don't work correctly. It turns out that SoftICE comes with SERIAL.EXE, which is a DOS program that can control SoftICE over serial and has better functionality than a VT100 terminal. To use it, I copied the SERIAL.EXE to my Linux host, replaced the xterm -e screen /tmp/hostPort 57000 line with dosemu -I 'serial { com 1 device /tmp/hostPort }' -E SERIAL.EXE 1 57000 in the script, and then changed SoftICE's initialization string to "SERIAL ON 1 57000". Now, dosemu connects with the Windows 98 VM over serial, and keyboard shortcuts and colors work in SoftICE.

If you're looking to get a better resolution and color mode, the official VMware guest additions should support Windows 9x.

The corrupted text in SoftICE prevents me from further debugging this driver. Apparently, it's possible to use SoftICE over a serial port, but it somehow treats it as a modem and requires a telephone dial-in number. If anyone knows how to get that to work, it would be appreciated. EDIT: After doing some research, I figured out how to do serial debugging with SoftICE. Not sure if this is useful to anyone out there, but here's what I did. In the SoftICE settings in the Windows 98 guest, I added "SERIAL VT100 1 57000" to the initialization string. On my Linux host machine, I made this script which creates a virtual serial connection and attaches a virtual terminal to one end of it. #!/bin/bash # Script for setting up a virtual serial connection to use with SoftICE # This must be started before starting the guest VM # Create a virtual null modem # This command will create two virtual serial ports, typically named # /dev/pts/N, where N is a number. Since the numbers are unpredictable, # we use the link option which makes socat put user-specified symlinks to these # devices. # The COM1 serial port in VirtualBox must be set up to use the host device at /tmp/guestPort socat -d -d pty,raw,echo=0,link=/tmp/hostPort pty,raw,echo=0,link=/tmp/guestPort & # Create a terminal connected to /tmp/hostPort # I run this in xterm, because all of the GTK-based terminals seem to intercept # the F1-F12 keys, which we need in the debugger xterm -e screen /tmp/hostPort 57000 # Stop the serial connection when xterm exits killall socat In the VirtualBox guest settings, I enabled the COM1 serial port and set the port mode to "Host Device" and the Path/Address to /tmp/guestPort. Now, all I have to do is run that script, start my Windows 98 guest VM, and after a few seconds, I have a serial connection with SoftICE.

I finally got my driver to work in 256 color mode! However, it locks up the system when changing resolution or color depth. I'm also having issues with SoftICE not handling resolution changes correctly. Whenever my driver changes the screen resolution, SoftICE's output becomes garbled and unreadable.

For some reason, I am unable to upload any images or other files when posting on this site. Attempting to do so gives me an error box that says: I've tried on multiple browsers (Firefox 85.0 and Chromium 87.0.4280.66) with the same result. Is this a known issue?

I tried setting it to something other than 640x480x4bit, but I get the "There is a problem with your display settings. The adapter type is incorrect, or the current settings do not work with your hardware." message box, and it still always loads vga.drv. How does Windows determine whether to show that error? Is anyone familiar with SoftICE? According to the documentation, I believe the "int 3h" instruction should break into the debugger, but I'm doing that at the very beginning of my driver's Enable function and nothing happens, so I assume Windows isn't loading my driver for some reason. EDIT: It turns out I had to use the "SET I3HERE ON" command in order to make SoftICE break on "int 3h". My driver is actually loading and is being called, but errors because I haven't implemented the necessary code.

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

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.

I'm a bit confused on a few things. According to the documentation, 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).

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.

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.

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.

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?

I eventually figured it out. It seems that (with the exception of std) those are names of DLL files, and Kexstubs.dll requires a matching Kexstubs.ini file, or else it won't work. What is the difference between kexbases.dll and kexbasen.dll?

What does the contents line in core.ini mean? I have this in core.ini [BASE] contents=Kexstubs,std,kexbasen,kexbases Kstub824 desc=Base enhancements (api fixes + extensions) Are those supposed to be names of dlls, ini files, or something else? Also why should there be a newline before Kstub842? I'm trying to get Firefox 45 running, and I don't really understand what I'm doing with Kext. Ktree9 says <error code: 2> <not found> for Kexstubs. Is there supposed to be a Kexstubs.dll that I'm missing?

Have you looked into Neocities? It is essentially a spiritual successor to Geocities and they apparently offer 1GB of free storage.

The only motherboard I've had capacitor problems with was from a 2006 Dell Dimension E510 (not Windows 9x compatible). We used it as a daily driver until it failed 2016. I looked at the motherboard, and pretty much all of those cylinder capacitors were blown. I have Dell desktops from 1996 and 2001 (both compatible with Windows 98), and both still work and have good capacitors. The 2001 one got a lot of use. It was a daily driver from 2001 to 2008. I've had to replace a fan, power supply, and hard drive, but never capacitors.

I haven't been on this forum in a few years. Very to sad to hear of Loew's passing. As a fellow reverse engineer, I really admire his work.

Wow, it seems this OS is still being worked on in 2020. I need to try it out again. http://doscore.net/home.html

Muy interesante! It seems complicated to set up, though. Is there a way to get direct links to the update .exe files from archive.org? I tried downloading some earlier this year, but the archived Microsoft website isn't very functional (missing some backend content), so I wasn't able to download them from the wayback machine.

Ok, never mind. The build system is HORRENDOUSLY complex, with hundreds of thousands of lines of python, and autogenerates code in places. I'm not going to attempt building it with MinGW.

The Linux and OS X builds are compiled with gcc, so I'd think the vast majority of the code except for the Windows-specific platform code should be compatible with it. The major roadblock is getting the build system to work with it. I'm currently trying to build Pale Moon with MinGW.

Is it not possible to compile it with MinGW? I can compile C++14 programs with gcc and have them run on Windows 95.