There is a patch out there that makes the SVGA driver that ships with Windows 3.x compatible with VESA VBE, enabling it so support higher resolutions with pretty much every graphics card that supports VBE. From what I have read, the Voodoo 3 has good VBE support in its BIOS.

The patch should be fairly easy to find through Google, or by doing a search for it here on Vogons.

I'm not sure if it will get you to 1600x1200, but you'll definitely be able to do better than 640x480.

red-ray wrote on 2020-11-29, 14:42:

I just installed Windows for Workgroups 3.11 and thus far I have only managed to get my Voodoo3 2000 to run at 640 x 480, but on Windows 2003 Server it happily runs at 1600 x 1200. Has anyone managed to get a Voodoo 3 running at higher resolutions or know of a VGA card that will please?

Hi, It's hard to believe that only 640x480 drivers can be installed for your card. Have you checked the available drivers under Windows setup? BTW S3 Trio/Virge cards definitely have drivers that depending on video memory size enable you to use even 1280x1024:

As a compromise you can also use patched generic MS SVGA/VESA driver that can use 1024x758 256 color:
The original MS driver:
http://www.win3x.org/win3board/viewtopic.php?t=18031
The patch that is required for unsupported cards that are VESA 1.x compatible nonetheless:
http://www.win3x.org/win3board/viewtopic.php?t=5408

Thank you guys, I used the patched SVGA driver and now get 1024 x 768 @ 256 colours which is good enough for me.

Next I need to find a version of the MSVC 6 MSVCMON.exe that contains the relocation information, the only one I have is linked /FIXED (.reloc missing) and I need one that's linked /FIXED:NO otherwise WIN32s won't run it. I just built a SIV32O.exe with /FIXED:NO (.reloc present) which now seems to start running, but it does not get very far at all so I need to get the debugger going.

Looking at https://www.infania.net/misc/kbarchive/kb/131 … 1058/index.html it looks like it should be possible to run MSVCMON on WIN32s.

Found this:

https://bearwindows.zcm.com.au/myproj.htm

Not sure if it is helpful to you, though.

Anyway, good luck! 😀

Jo22 wrote on 2020-11-30, 10:32:

Not sure if it is helpful to you, though.

Thank you, it says Do not use Microsoft Visual Studio 6.0. WHY? See BELOW! so basically it looks like I would need to use MSVC 5.0 which I don't think I wish to do.

According to Wikipedia, "Microsoft ceased support for Win32s in Visual C++ version 4.2 released in late 1996."

Source: https://en.m.wikipedia.org/wiki/Win32s

digger wrote on 2020-11-30, 23:22:

According to Wikipedia, "Microsoft ceased support for Win32s in Visual C++ version 4.2 released in late 1996."

Source: https://en.m.wikipedia.org/wiki/Win32s

That's right, I believe. Official support ended with later versions of 4.x.
However, some older programming books of mine mention that Visual Basic 5 could produce Win32s compatible programs.
Unfortunately, they don't go much into detail, it's rather mentioned on a side note.
In a "you know, you could even do that.." manner, so to say.

Anyway, Delphi 2.0 also can do produce Win32s programs "by accident", probably because it was made with Win NT/Win32 programming guidelines in mind.

Thank you guys. I did some checking and MSVCMON 5.0 does not have the .reloc section so won't run, but MSVCMON 4.1 (4.2 comes with this) does so should.

To check if I could use MSVCMON 4.1 with MSVC 6.0 I ran it on 2003 server, checked what happened and it did not work so suspect for remote debugging to work with WIN32s I would need to use MSVC 4.2 on the host system 🙁.

Finally I tried MSVCMON 4.1 on WIN32s and when it ran it failed to offer TCP/IP when on 2003 it did 🙁.

Given this I am even less inclined to try using MSVC 4.2 🙁, but wonder if any of you get TCP/IP offered on WIN32s so attached the MSVCMON 4.1 from the MSVC 4.2 CD.

Update: Looking at https://www.infania.net/misc/kbarchive/kb/131 … 1058/index.html it says as below so it looks like TCP/IP is not possible on WIN32s 🙁

Well, it does add a bit to the retro nostalgia to be having to debug over a serial link as opposed to a TCP/IP connection, wouldn't you agree? 😉

Is the target environment a physical machine or a VM? In the latter case, it shouldn't be hard to set up an emulated serial connection. In the former case, it actually sounds like fun to set up. 😀

digger wrote on 2020-12-02, 11:02:

Is the target environment a physical machine or a VM?

red-ray wrote on 2020-11-29, 14:42:

I have only managed to get my Voodoo3 2000 to run at 640 x 480

How many VMs have a Voodoo3 2000 ?

A physical system setup with multi-boot of 2003 Enterprise Server + 98SE + WFW 3.11. In general running SIV on a VM is at best pointless as it's the VM that get's reported rather than the actual hardware.

I guess I could setup serial debugging and must have done this back in around 1994, but as MSVC6 does not support serial debugging I would choose to install MSVC 4.22 on this Windows 10 x64 system and then build SIV with MSVC 4.22 which I suspect will be none trivial. I suspect installing MSVC 4.22 may well break the MSVC 6 installation and it may not be possible to install MSVC 4.22 at all. l I currently don't wish to risk doing this.

Having used WFW 3.11 for a few minutes reminded my how temperamental it was and is. All in all I feel going to the dentist is preferable to using WFW 3.11 !

For MSVC6 there is https://www.codeproject.com/Articles/1191047/ … udio-on-Windows + http://blog.danbrust.net/2015/09/14/installin … 0/#.X8eCKc5xfYc, but I can't find similar for MSVC 4.22.

red-ray wrote on 2020-12-02, 11:57:

digger wrote on 2020-12-02, 11:02:

Is the target environment a physical machine or a VM?

red-ray wrote on 2020-11-29, 14:42:

I have only managed to get my Voodoo3 2000 to run at 640 x 480

How many VMs have a Voodoo3 2000 ?

Well, it would theoretically work with modern hypervisors supporting PCI VGA passthrough, providing you have a host system that supports hardware-assisted virtualization with an IOMMU. 😉

But yeah, I should have remembered your initial question in this thread before I clicked "send" on that response. 😅

I guess I could setup serial debugging and must have done this back in around 1994, but as MSVC6 does not support serial debugging I would choose to install MSVC 4.22 on this Windows 10 x64 system and then build SIV with MSVC 4.22 which I suspect will be none trivial. I suspect installing MSVC 4.22 may well break the MSVC 6 installation and it may not be possible to install MSVC 4.22 at all. l I currently don't wish to risk doing this.

According to this document on Microsoft's website, serial debugging should still be possible in later versions of MSVC: https://docs.microsoft.com/en-us/windows-hard … n-visual-studio

Having used WFW 3.11 for a few minutes reminded my how temperamental it was and is. All in all I feel going to the dentist is preferable to using WFW 3.11 !

I wouldn't know. I'm a Linux and JetBrains guy myself. 😁 (Although I have played with Visual Studio Code a bit, but that's of course a completely different beast.) Have you looked into using an alternative toolchain for developing and debugging software for WFW 3.11? The Open Watcom compiler apparently can still build for Win32s. And you can use it as a cross-compiler in both Linux and in more modern Windows versions. And it includes debugging tools as well, which might also support remote debugging. See this thread on GitHub, for instance: https://github.com/open-watcom/open-watcom-v2/issues/183

digger wrote on 2020-12-02, 23:32:

According to this document on Microsoft's website, serial debugging should still be possible in later versions of MSVC: https://docs.microsoft.com/en-us/windows-hard … n-visual-studio

Your link pertains to Kernel Mode Debugging which is totally different to the User Mode Debugging that MSVC 4.22/5.0/6.0 support.

Checking https://www.infania.net/misc/kbarchive/kb/131 … 1058/index.html it specifies as below and is confirmed as MSVC 6 does not offer serial, only Local + TCP/IP.

Because Visual C++ version 5.0 supports only TCP/IP connection, check for correct machine name and proper network connection with TCP/IP protocol available. The following troubleshooting does not apply to version 5.0 or 6.0.