Windows 1.0 DR5 Hi-Res Drivers

[jb881122]

These drivers allow Windows 1.0 DR5 to be run in EGA, VGA, and VESA 800x600 modes. To use, copy the driver files (inside the disk image) to your WINDOWS\TEST folder. Then (assuming WINDOWS\BIN is in your PATH), the drivers can be installed using:

Code: Select all

 EGA: drivers EGAHIBW
 VGA: drivers VGAHIRES
VESA: drivers VESA800

Download link: https://drive.google.com/uc?export=down ... 7F71yE4n5m

Let me know if there are any glitches. I tested them as thoroughly as I could, but something might have slipped through.

EDIT: Added screenshots now that I have 3 posts:

[AlphaBeta]

Wow, that's awesome!

Did you write the drivers from scratch, or port the EGA driver from Alpha?

[jb881122]

Wow, that's awesome!

Did you write the drivers from scratch, or port the EGA driver from Alpha?

They are actually modified Hercules drivers. I was considering porting Alpha's EGA driver but Alpha and DR5 are different enough that I doubt it would work. I probably could have used the CGA driver as well, but I have already tried modifying both drivers several times and the attempt that worked just happened to be with the Hercules driver.

[Overdoze]

Very nice work, didn't think the Hercules driver would be the key to EGA for DR5. Now if only there was a way to write a color driver.

[jb881122]

Very nice work, didn't think the Hercules driver would be the key to EGA for DR5. Now if only there was a way to write a color driver.

I was toying with that idea last night. While I don't think it would be impossible (especially considering that I just got a Hercules driver to work with EGA), it would probably be more difficult than just rewriting a set-mode function, changing around a few numbers, and NOPing out some interlacing code, bitshifts, and sign code. I wonder if it's possible to disassemble the Beta display driver code, as the disassembly of DR5's display drivers helped me quite a bit. I'm not planning on porting any drivers from the Beta version (as I'm sure they're highly incompatible), but looking at the difference in functions between the EGAHIBW and EGAHIRES drivers would probably be of great help.

[DJ Deedahx]

Solid work. This has been confirmed to work on 86Box! Thanks for sharing this with us.

This is the VGA (640 x 480) driver shown here.

[jb881122]

Solid work. This has been confirmed to work on 86Box! Thanks for sharing this with us.

This is the VGA (640 x 480) driver shown here.

No problem! There's no use in me hoarding these drivers, especially when other people can probably put them to better use than I can.

[vlad557776]

Great! Now just need PS/2 mouse drivers and every single version of 1.0 is in my VBox.

[jb881122]

Great! Now just need PS/2 mouse drivers and every single version of 1.0 is in my VBox.

I already modified the mouse driver to use int 33h (DOS mouse driver). Download link is here:

https://forum.winworldpc.com/uploads/ed ... 3oelqhu.7z

It might be a bit buggy. I haven't had any problems moving and clicking the mouse, but when I start Windows on the VM more than once without rebooting, it sometimes hangs. Rarely ever hangs when booting up though.

[johnlemon647]

Very nice work, didn't think the Hercules driver would be the key to EGA for DR5. Now if only there was a way to write a color driver.

I agree with Overdoze but be it nice to add colors into Windows 1.0 DR5 and Windows 1.0 Alpha. Maybe we need rewrite Windows 1.0 Beta Color Driver to get work on Windows 1.0 DR5 and Windows 1.0 Alpha.

[Lucas Brooks]

There is a big difference in size between mono and color drivers so I don't think it would be an easy task. It is impossible to port Beta Releases's EGA color driver to DR5 or Alpha Release since they are too different. I was able to disassemble a PS/2 mouse driver and compile it for Alpha Release and it works to some degrees (hangs randomly). The video driver would've been written in assembly and C and without a proper DDK, documentations and libraries, it would be a real challenge to write something from scratch.

Maybe thinking about comparing Beta Release's mono and color driver to work out the different functions and decompile them and find some way to add them to Alpha or DR5. Ghidra is capable of decompiling Beta Release's executables and IDA works without any python scripts.

[jb881122]

There is a big difference in size between mono and color drivers so I don't think it would be an easy task. It is impossible to port Beta Releases's EGA color driver to DR5 or Alpha Release since they are too different. I was able to disassemble a PS/2 mouse driver and compile it for Alpha Release and it works to some degrees (hangs randomly). The video driver would've been written in assembly and C and without a proper DDK, documentations and libraries, it would be a real challenge to write something from scratch.

Maybe thinking about comparing Beta Release's mono and color driver to work out the different functions and decompile them and find some way to add them to Alpha or DR5. Ghidra is capable of decompiling Beta Release's executables and IDA works without any python scripts.

I don't think the difference in size would be the hard part. It seems like DR5's simple NE header only needs one value changed (the size of the segment in paragraphs). As long as that value is changed accordingly, you can give yourself quite a bit of room for the color-related code, which can then be called or jumped to from the rest of the driver (I was also thinking about doing this for bank-switching code for a possible 1024x768 driver). I still don't know how to do that for the Alpha version, as those drivers have several segments within them, and it crashes every time I try to play with the segment table. I was initially going to use a TSR to store that code, but I would rather not require the user to launch a program before Windows. The BitBlt function in the Windows 2.11 Binary Adaptation Kit doesn't seem to have changed a ton since DR5, so I have been copying all of the code within the color #ifdefs into the TSR (and attempting to adjust variables accordingly); so far, some of the color code (though I'm not close to done with even one function, so don't ask for screenshots) is in my TSR, but now I am working on putting the code into the driver itself.

There might be some fatal flaw with all of this, but I will continue this until someone points it out.

[Lucas Brooks]

I wasn't saying it is hard to change the executable size but the difference in size indicates the amount of extra code. Very impressed with your work here! It is a shame that none of the documentations, libraries and DDKs of early Windows 1.0 releases are leaked. Even a DDK from 1.01 RTM would help a lot.

Maybe you can try working with John Elliott if you ever encounter any troubles since he is very experienced in patching drivers.

[Overdoze]

The DDK before 3.0 was probably just part of the OAK with driver samples and such, as we can observe in 2.11 OAK. We really could use that either way, I agree.

[NickWillis]

These drivers allow Windows 1.0 DR5 to be run in EGA, VGA, and VESA 800x600 modes. To use, copy the driver files (inside the disk image) to your WINDOWS\TEST folder. Then (assuming WINDOWS\BIN is in your PATH), the drivers can be installed using:

Code: Select all

 EGA: drivers EGAHIBW
 VGA: drivers VGAHIRES
VESA: drivers VESA800

Download link: https://drive.google.com/uc?export=down ... 7F71yE4n5m

Let me know if there are any glitches. I tested them as thoroughly as I could, but something might have slipped through.

EDIT: Added screenshots now that I have 3 posts:

Wow! Very decent work!

[jb881122]

I haven't replied in a while so here's an update:

My attempts at getting color in Windows 1.0 Alpha haven't gone very far yet. It seems like patterns and bitmaps are stored differently in color drivers than in monochrome drivers. If the differences are what I suspect (a separate copy for each color channel), I believe that I would need to copy every bitmap four times (possibly repeating every eight bytes instead of the whole bitmap at once), which would probably not fit very well in the space I have. As it is right now, it's very unstable and not pretty:

It likes to crash with the "Invalid local handle" error a lot of times. It usually happens when I change something that seemingly doesn't have anything to do with handles (maybe the amount of memory given to the driver to perform a function is too small to handle color and it overwrites a pointer somewhere?). It is sometimes resolved by switching between the original mouse driver and the PS/2 driver from the Excel runtime. I wonder if it is possible to run the Alpha Release in "slow mode" like DR5 does (with the drivers separated instead of in one big file, there was something on this forum about doing that for Windows 2.x)? If I try running it like that, it looks for some driver files, but it doesn't run.

EDIT: I got slow mode to run, but it seems more crash prone, even with normal drivers.

On a side note, while I was playing with the patterns, I realized that the values that make up the background pattern use the same 8x8 patterns as desktop patterns in Windows 3.0. If you (for some reason) have a need to use desktop patterns in DR5 or Alpha, open up the display driver with your favorite hex editor and do the following replacement:

Code: Select all

From:
    Alpha CGA and DR5:      AA AA AA AA AA AA AA AA
    Alpha Hercules and EGA: AA 55 AA 55 AA 55 AA 55

To (some common Windows 3.0 patterns):
    Boxes:    80 BE BE BE BE BE 80 FF
    Critters: FF AF 8D DF FF FA D8 FD
    Diamonds: DF AF 77 AF DF FF FF FF
    Paisley:  FD F8 F8 FD DF AF AF DF
    Quilt:    7D BB D7 EE D7 BB 7D FE
    Scottie:  BF 3F 37 87 87 B7 FF FF
    Spinner:  EB F3 37 86 61 EC CF D7
    Thatches: 07 8B DD B8 70 E8 DD 8E
    Tulip:    FF FF AB 83 83 C7 6D 83
    Waffle:   FF FF FF FF 7F 7F 7F 0F
    Weave:    77 AB DD BA 77 EA DD AE

Here is a screenshot of a pattern on DR5:

I don't know if this works on the Beta Release or later. If I had to guess, those drivers probably store a default background color instead of a hard-coded pattern, so this wouldn't work.

[Lucas Brooks]

Nice work! Do you think applications have their own colors by the time of Alpha Release? Looks like some apps already got colors since DR4 (around the time of Tandy 2000 builds) and it remained almost unchanged throughout the development of Windows 1.0.



I skimmed over some of the included source code and looks like none of them have color . I am suspecting some apps such as Calculator, Control Penal, Puzzle and Reversi already have background colors but because the driver is monochrome, they are simply displayed as different levels of "gray".

Once your patched driver is stable enough and if possible, please post a picture of an app such as Calculator running ! Your efforts are very much appreciated!

[xelloss]

I skimmed over some of the included source code and looks like none of them have color .

Yeah, however you only need to go through the included windows.h to see that applications can easily use colours: for instance, you could replace GetStockObject(LTGRAY_BRUSH) in chart.c with GetSolidBrush(RGB(255,0,0)) (remember you also need to destroy the brush before the application quits). Of course it will only paint as red with a colour display driver is used.

[Overdoze]

I am suspecting some apps such as Calculator, Control Penal, Puzzle and Reversi already have background colors but because the driver is monochrome, they are simply displayed as different levels of "gray".

I believe this is what we found out when we first looked at this a while ago - most of the apps in the screenshot still used the same colors in DR5.

[jb881122]

Once your patched driver is stable enough and if possible, please post a picture of an app such as Calculator running !

Although it is not stable enough to run anything without crashing (the background is displayed, then nothing else), here is a picture of Puzzle trying to run with the complete mess driver:

For one, I don't think the screen background is supposed to be green (that happens regardless of monochrome or color patterns). Also, Puzzle is the only program I tested that loads a correct-looking pattern for the background. It still wants to display a monochrome background, is there something that detects if it is color or monochrome other than GDIINFO and the 0101h/0103h after the first instance of the screen resolution (not GDIINFO but looks similar, I forget what it is called)? Is there maybe a dither function separate from BitBlt that I would have to change?

Yeah, however you only need to go through the included windows.h to see that applications can easily use colours: for instance, you could replace GetStockObject(LTGRAY_BRUSH) in chart.c with GetSolidBrush(RGB(255,0,0)) (remember you also need to destroy the brush before the application quits). Of course it will only paint as red with a colour display driver is used.

That sounds like an easy modification, but how would you compile it? I know ComputerHunter gave it a good try but failed. I tried renaming __cyfunc to __cyfun2 in one of the Pascal libraries. A program compiled and linked, but the program freezes Windows (probably for an obvious reason that I'm missing).

I am probably going to email John Elliott with what I have so far and see if he has any input or could help with getting color in Windows 1.0 Alpha, as he has more experience than I do with this stuff (I'm probably younger than you think ).

Also, should I start a new thread for this? It seems like I veered off of the main topic for this thread.

[Lucas Brooks]

I believe this is what we found out when we first looked at this a while ago - most of the apps in the screenshot still used the same colors in DR5.

Not exactly... Some colors have changed and not sure why the colors are much brighter in the Tandy 2000 builds than in Windows 1.01.

For one, I don't think the screen background is supposed to be green (that happens regardless of monochrome or color patterns). Also, Puzzle is the only program I tested that loads a correct-looking pattern for the background. It still wants to display a monochrome background, is there something that detects if it is color or monochrome other than GDIINFO and the 0101h/0103h after the first instance of the screen resolution (not GDIINFO but looks similar, I forget what it is called)? Is there maybe a dither function separate from BitBlt that I would have to change?

RTM's default background is also green if I recall correctly. It is possible that apps for PC compatible Windows 1.0 does not have colors and the shades of gray were simply used to make it look better or to mimic colors. If they have colors, Puzzle's color should be similar to Calculator's which I suspect is red.

Offtopic Comment

Here is a piece of text about color support in Windows 1.0:

Yeah, however you only need to go through the included windows.h to see that applications can easily use colours: for instance, you could replace GetStockObject(LTGRAY_BRUSH) in chart.c with GetSolidBrush(RGB(255,0,0)) (remember you also need to destroy the brush before the application quits). Of course it will only paint as red with a colour display driver is used.

That sounds like an easy modification, but how would you compile it? I know ComputerHunter gave it a good try but failed. I tried renaming __cyfunc to __cyfun2 in one of the Pascal libraries. A program compiled and linked, but the program freezes Windows (probably for an obvious reason that I'm missing).

I think he was talking about DR5 which some samples can be compiled. That might work only if we have a color driver. I have
compared WINDOWS.H from DR5, Alpha Release, Beta Release and Premiere Edition, Beta Release is where most of those color stuff comes in. You can download them here: https://mega.nz/file/JNt3kLCT#aeyJ0m8su ... 1xWEiy-JFE. Compiling apps for Alpha Release is basically impossible unless we find the Windows Toolkit that came with Microsoft C 3.00.

[johnlemon647]

The Windows 1.0 Background post be Green Color. I thank Tandy 2000 Beta Build is background is Light Blue. @jb881122 thank you for give your best try.

[John Elliott]

For one, I don't think the screen background is supposed to be green (that happens regardless of monochrome or color patterns). Also, Puzzle is the only program I tested that loads a correct-looking pattern for the background. It still wants to display a monochrome background, is there something that detects if it is color or monochrome other than GDIINFO and the 0101h/0103h after the first instance of the screen resolution (not GDIINFO but looks similar, I forget what it is called)? Is there maybe a dither function separate from BitBlt that I would have to change?

I haven't looked at DR5, but in the released Windows it's RealizeObject() that converts colours from 24-bit RGB to colours / dither patterns.

[Lucas Brooks]

Just confirmed that DR5 apps supports color... As expected Calculator, Puzzle and Reversi have colors - Calculator uses a red (#FF0000) background, Reversi uses a green (#00FF00) background and Puzzle uses a blue (#0000FF) background. Puzzle and Reversi are a bit special as they have other colors as well.

Calculator:



Of course, as expected, Calculator uses a red background and replacing it with black (00h) will make the entire background black .



Puzzle:



Well, this app uses both blue and green which is a bit unusual considering it has a red background in Beta Release. Tandy 2000 builds also uses blue so I guess the color change occurred at some point after DR5 and before Beta Release (yet to figure out the color it uses in Alpha Release).

Reversi:



Reversi uses red, green and blue which remained unchanged throughout the entire development of Windows 1.0.

Overall
I was a bit disappointed that only 3 apps actually used colors as I was expecting apps like MS-DOS Executive and Control Panel to have colors as well. At least we have 3 apps with colors, better than nothing and johnlemon647 - the background is definitely not light blue, it appears to be in the Tandy 2000 builds maybe due to the low picture quality. I think I have also answered why the colors in Tandy 2000 builds are brighter than the ones from Beta Release to RTM - they use true red, green and blue whereas Beta Release onward use dimmer colors. Below is a professional artist's rendition of what DR5 would look like if a 16-color VGA driver exists:



I have also attempted to compile a few DR5 apps with colors myself and well, as you may have guessed - WE DON'T HAVE THE SPECIAL LIBRARIES... Now I am starting to believe that DR5 was indeed released on 8 disks as there must've been 3 C Compiler + library disks, 2 Pascal Compiler disks and 3 Windows disks. I am thankful that even though it fails, manually running MAPSYM and NE will still produce a working app - opposed to something that hangs Windows in later releases.

I am guessing that we really need an IDA or Ghidra loader for Alpha Release (thanks to JaGoTo for making the DR5 loader) in order to know how Alpha Release would look like if there is color support - or wait for jb881122 to complete his awesome driver patch. Anyway, I am certainly not experienced enough to reverse the NE format and write a loader myself so if anyone feels like they can do that, please go ahead and I will be looking forward to Alpha Release being analysed and hidden gems being discovered.

[xelloss]

the background is definitely not light blue, it appears to be in the Tandy 2000 builds maybe due to the low picture quality

The desktop window is probably created in WINDOWS.EXE, so you may be able to find out what colour was used in DR5 by looking there (you should also find an instance of CreatePatternBrush (or perhaps CreateHatchBrush?), used with monochrome displays...)