Grzyb wrote on 2025-01-06, 11:35:

I recall getting that error back in the era, when using 24-bpp with some Cirrus 542x chip.
So I guess it's not the driver's fault.

Don't know. I did some further tests on this. Actually, the affected icons in this case were Creative Audio Software stuffs (that were installed by the Win3.x SB16/AWE driver).
- The low memory error which caused some icons to turn black only happens once. On subsequent boots the error doesn't show up but affected icons will stay black.
- When trying open the Properties window of the affected program group entry, the icon is being showed correctly, even when opening the Change Icon dialog, but when I click OK to save changes, I get an error saying something like "insufficient memory to complete the operation" and the program icon entry will be deleted, gone for good. I've already lost two entries as a result.

Perhaps I should set up a DOS startup config with a bit more RAM (e.g. 128MB or even 256MB) to see if it makes any difference... though I'm afraid the issue might indeed be elsewhere, as other programs (like Solitaire, File Manager, etc.) open just fine without complaining about low memory.

EDIT: (UPDATE: This issue has been fixed.) There's another issue with this driver that may or may not break things -- it would render garbage* over some black backgrounds under certain circumstances.

* To be precise, the driver doesn't clear those areas and would render whatever the content it had at the time. On initial system startup the content looked like garbage, but after that it would simply be whatever that was drawn on the screen before the area is supposed to be blanked.

EDIT 2: I just set up a startup config with 256MB memory (using LIMITMEM + XMGR) and it indeed doesn't make any difference. I'm still getting that "insufficient memory" error when trying to make changes to the group icons in question, and as a result a few more icons get "deleted". The system reported as much as 75% free resources when running with 256MB, and other programs can open just fine.

EDIT 3: It appeared the issue was more about Program Manager than the driver and was already known by MS back then.

Grzyb wrote on 2025-01-05, 22:51:

AFAIR even the Paintbrush shipped with Windows 3.1 supports 24-bpp.

Makes sense, MS Paintbrush had a relationship to ZSoft Paintbrush, which was available for Windows 2* and was released in 1987.
So the code base of MS Paintbrush may reflect this.

And Windows 2 in turn did support a virtual form of Tru-Color via dithering (not sure about Win 1.x).
That's because 256c graphics hardware was considered high-end when Windows 1 and 2 were current.

Info:
https://web.archive.org/web/20110414135622/ht … windows/colors/

https://gonnagan.wordpress.com/2011/07/22/win … ith-256-colors/

https://en.wikipedia.org/wiki/PC_Paintbrush#Version_history

(*That was PC Paintbrush 1.05 for Microsoft Windows, I think.
Like many Windows 2 applications it ran on Windows 1.x, as well.
I merely assume here it was made with Windows 2 in mind, given the release date and the better window managment of Windows 2.)

Does anybody know if the driver has any kind of GUI acceleration? Being VESA generic I suppose the answer is no, but I am making a lot of assumptions...

GUI acceleration needs access to the actual blitters present in variety of cards, of course all card specific. VESA 2.0 or 3.0 do not give any such kind of accelerations, you need device specific drivers for that.

Well, there was some attempt to implement VBE/AF - https://shawnhargreaves.com/freebe/
But I've never tried it...
Probably all the supported chips also have native Windows 3.1 drivers.

Theoretically a Windows 3.x driver using VBE/AF is feasible, but that standard was completely ignored by graphics vendors. In my experience, only several drivers generated from SDD 6.53 and some from FreeBE/AF (most of them are quite incomplete) are the useable ones.

Gmlb256 wrote on 2025-01-10, 15:01:

Theoretically a Windows 3.x driver using VBE/AF is feasible, but that standard was completely ignored by graphics vendors. In my experience, only several drivers generated from SDD 6.53 and some from FreeBE/AF (most of them are quite incomplete) are the useable ones.

It would still be fun and in some ways useful to "resurrect" that standard, though. As you said, some drivers or BIOS extension TSRs were in fact released that made use of it, and perhaps the paravirtualized guest drivers of popular hypervisors such as QEMU, VirtualBox and VMWare could be made to support the VBE/AF acceleration features.

FreeBE/AF could perhaps be dusted off and extended to add support for more modern GPUs.

Of course, it could be argued that modern systems are so fast these days, that even with a dumb framebuffer without any form of (2D) hardware acceleration, performance would be more than fast enough.

But then again, the developer might find it a fun challenge to add optional VBE/AF support to the vbesvga driver, even if only for the sake of completion. 🙂

digger wrote on 2025-01-10, 15:28:

It would still be fun and in some ways useful to "resurrect" that standard, though.

Impossible to resurrect something that never was alive...

Grzyb wrote on 2025-01-10, 15:48:

digger wrote on 2025-01-10, 15:28:

It would still be fun and in some ways useful to "resurrect" that standard, though.

Impossible to resurrect something that never was alive...

Both SDD and FreeBE/AF support it. So it's not completely stillborn.

And maybe "repurpose" would be a better word than "resurrect" here, then.

Anyway, there is a feature request for it now. Let's see if the developer (or perhaps some other contributor) is interested in implementing it.

Is there any chip with VBE/AF support in SDD or FreeBE/AF, but without native Windows 3.1 drivers?

Grzyb wrote on 2025-01-10, 15:58:

Is there any chip with VBE/AF support in SDD or FreeBE/AF, but without native Windows 3.1 drivers?

Likely not, but my main reasoning here is that if the vbesvga driver gains support for VBE/AF, it might be worth adding support for newer GPUs to the FreeBE/AF project.

Think if it this way:

If you have multiple older operating systems on the one hand (Windows 3.x through XP) and all these newer GPUs on the other hand (AMD, NVIDIA, Intel, heck, even 3dfx), then by standardizing on something like VBE/AF, you'd only have to write a single VBE/AF driver for each of these OSes, and then you'd only have to write a single VBE/AF driver for each GPU you'd like to use with those older OSes. Otherwise, you'd have to write a separate native driver for each combination of vintage/legacy OS and modern GPU.

But also, exploring "what could have been" is a fun and legitimate niche within the retro computing hobby scene. At least I'd like to think so. 🙂

Also the FreeBE/AF drivers are open source, whereas the native Windows 3.1 drivers of those various old GPUs are not. Open source drivers are more maintainable and if support for more GPUs is added to FreeBE/AF, existing code could at least be partially reused. That seems easier than having to start writing an OS-specific driver from scratch.

digger wrote on 2025-01-10, 16:06:

If you have multiple older operating systems on the one hand (Windows 3.x through XP)

I think it would only be fully useful for Windows 3.x.
For 9x, limited - probably useful for the 2D part of DirectX, but no 3D.
But no way to use for anything NT-based, nor other non-DOS systems.

digger wrote on 2025-01-10, 15:28:

Of course, it could be argued that modern systems are so fast these days, that even with a dumb framebuffer without any form of (2D) hardware acceleration, performance would be more than fast enough.

I like the idea. Though I also wonder if the new VBE driver does support dirty-rectangle already (only redrawing bitmaps in parts of screen memory that have changed).
The Windows 3.1 VGA driver does do it, I think, but I'm not sure about the Windows 3.0 VGA driver or the sample drivers from SDK/DDK.
Updating only parts in video memory that contain changed bitmap data would reduce the bus load, maybe.
Things like a moving mouse cursor wouldn't cause so much load, for example.
(Accelerated graphics drivers have hardware mouse cursor, I think.)
That being said, this thinking isn't new and quite obvious maybe.

I have a motherboard with integrated graphics that can do 1080p using VBE. I totally need to try this driver!

I tested the latest VBE driver from the project site, and its really impressive work. I think it still has some bugs, but overall, I think the project is heading in the right direction.

On my Intel Q67/i7-2600k setup with internal graphics, I can get a 1080p video output from Windows for Workgroups 3.11 for the first time. The image gets corrupted when I move windows around (like remnants of the window frame) and some icons don't display properly such as the buttons in File Manager.

I also noticed that screen capture via the Print Screen key doesn't work at all (it captures all white pixels at the full screen resolution).

I still think this driver has a ton of potential, though.

Wait a minute...
In the topic title, there's "Windows 3.x", in other places it's "Windows 3.1"...
So, is it supposed to work in Windows 3.0 ?

Hi, my bet is on Windows 3.1, since it's made with help of Win 3.1 DDK.
So it likely won't work on stock Windows 3.0/3.0a, which had a less flexible/advanced graphics driver model.

Other versions, like Windows 3.0 MME or Windows 3.1 betas might work, not sure.
I haven't tested things this way round yet, but rather just old drivers -> new Windows.

In general, Windows 3.0 drivers can still be used on Windows 3.1x, though.
There a certain limitations, though, since big parts of GDI are in the graphics drivers.

So using Windows 3.0 drivers on Windows 3.1x would lead to a more limited functioning of GDI and a slightly different dithering/palette.
That being said, Windows 3.1 does officially ship with a Windows 3.0 VGA driver (in addition to Windows 3.1 VGA driver). Probably for trouble-shooting.

I guess Windows 3.x often is used as an umbrella term for refering to anything Windows 3.1 related (to include all versions).
Renaming it to Windows 3.1x would be more accurate, though.

Jo22 wrote on 2025-01-12, 02:32:

I guess Windows 3.x often is used as an umbrella term for refering to anything Windows 3.1 related (to include all versions).
Renaming it to Windows 3.1x would be more accurate, though.

Correct, and I for one want generic VESA Windows 3.0 Real Mode in SVGA; someone already hacked together a high-res driver for 1.x and 2.x, but 3.0 is being left out in the cold (not enthusiast enough?).

BaronSFel001 wrote on 2025-01-16, 22:11:

Jo22 wrote on 2025-01-12, 02:32:

I guess Windows 3.x often is used as an umbrella term for refering to anything Windows 3.1 related (to include all versions).
Renaming it to Windows 3.1x would be more accurate, though.

Correct, and I for one want generic VESA Windows 3.0 Real Mode in SVGA; someone already hacked together a high-res driver for 1.x and 2.x, but 3.0 is being left out in the cold (not enthusiast enough?).

I see. There's a set of SVGA drivers as part of Windows 3.1 Beta build 034f.
They're separate versions of the 800x600 16c SVGA driver in final Windows 3.10.
One of them is a generic VBE version, I think.
The intersting thing is that these SVGA drivers do run in Windows 3.1 Real-Mode.
Maybe they're still Windows 3.0 compatible, as well, not sure.

Edit: I've just checked. The supervga.drv from Windows 3.1 Beta seems to work in Windows 3.0, too.
It's maybe necessary to manually add
[display]
svgamode=106
to win.ini, however, in order to get the VBE mode for 800x600 resolution.