Microsoft Windows 3.00.33 Beta is found

[johnlemon647]

Today Term24 upload Microsoft Windows 3.00.33 Beta. Microsoft Windows 3.00.33 Beta was mentioned in an internal Microsoft anti-trust document from August 1989.
https://archive.org/details/ms-win30-beta-v133/

[JimOlive]

When trying to boot this build in a 386 VM on 86Box, when doing "win" or "win /2", I get stuck at the message saying you need to test apps in native mode, with no disk activity. When doing "win /3", it does try to load with disk activity, but eventually kicks me back to DOS 3.31. I copied all the files from the main 5 disks to" C:\Windows", like BetaWiki says to do.

UPDATE: After lots of trial and error, and various attempts, I got "win" (286r mode) to work. "win /2" (286p Mode) crashes, and "win /3" (386p Mode) fails to load the MS-DOS Executive.

UPDATE 2: After adding "files=40" to config.sys, I now have all 3 modes working.

[Fanta Shokata]

It's the last build with MS-DOS Executive as the default shell.

[Battler]

This is a very nice find! While 3.00.14 still mostly looked like Windows 2.x, Windows 3.0 looks like 3.0 in all aspects except for the shell. I guess the Program Manager wasn't yet ready at that time.

[JimOlive]

If anyone is having trouble getting this build working, here's my 86Box configuration, which seems to work well.

Machine:

• Machine Type: i386DX

• Machine: AMI 386DX clone

• CPU Type: Intel i386DX (Speed 16)

• FPU: None

• Wait states: Default

• Memory: 4 MB

Video: VGA
Mouse: Microsoft Serial Mouse
HD Controller: IBM Fixed Disk Adapter (MFM)
Hard Disk:

• Bus: MFM/RLL

• ID: 0:0

• Speed: RAM Disk

You should use MS-DOS 3.31. After "installing" the build (aka copying the contents of the main 5 disks to C:\WINDOWS), you should add

Code: Select all

device=C:\windows\himem.sys
files=40

to config.sys, and restart. Afterwards, you should hopefully be able to boot into the build by entering the WINDOWS folder, and typing "win" (286 real mode), "win /2" (286 protected mode) or "win /3" (386 protected mode). Hopefully this helps.

[vbdasc]

typing "win" (286 real mode)

What does "286 real mode" mean? This thing won't run on a 8088/8086 CPU?

[AlphaBeta]

Windows 3.0 looks like 3.0 in all aspects except for the shell.

I think it would be rather weird if it didn't

[happycube]

typing "win" (286 real mode)

What does "286 real mode" mean? This thing won't run on a 8088/8086 CPU?

Some drivers (like the VGA one IIRC) in retail 3.0 had 80186+ opcodes, but the core of Windows ran fine. However it's possible 3.00.33 accidently has some newer instructions, it would take running it on PCem/86Box as an 808x computer to see if it works fine there.

Also it's a shame the SDK header/debugging disk was unreadable, those files would be good for archaeology - but it's probably not structurally too different from retail 3.0 by then, at least.

[Fanta Shokata]

I've found out that when trying to launch MS-DOS prompt from MS-DOS Executive inside 386 mode generates the following error message:



While trying to launch it in 286 protected mode, it crashed the OS, while it worked properly in 286 real mode.

[johnlemon647]

I got Windows 3.00.33 Beta run on my Windows 7 32-Bit Computer using VirtualBox 5.4

[yksoft1]

It seems that 3.0.33 386 Enhanced mode requires less than 16MB RAM and DOS < 4.x.
I could run 286 Standard mode in DOSBox DOS, but have to boot from HDD image (with MS-DOS 3.31) for 386 Enhanced mode.

[roytam1]

It seems that 3.0.33 386 Enhanced mode requires less than 16MB RAM and DOS < 4.x.
I could run 286 Standard mode in DOSBox DOS, but have to boot from HDD image (with MS-DOS 3.31) for 386 Enhanced mode.

Offtopic Comment

glad to see that you're back

[Lucas Brooks]

Offtopic Comment

Ohh hi yksoft1, welcome back... Off-topic but I'm also coming back for a random visit cuz I have to download something from the FTP and I need to grab some info... so here is just a dump of whatever I have with me right now.

It can run very smoothly under MS-DOS 4.x in 386p mode.



Been playing with this thing for a while now...

This build does not have proper NE support - aka it makes assumptions about the location of the tables. The next available build, build 55 is one of the first builds with fastload area support, and the fastload info (which later reside near the end of the NE table) is stored after the segment table and before the resource table. Build 55 is the only available build with this unique yet valid NE format, which is why build 33 can run RC2-RTM apps (assuming no missing APIs) but not apps from build 55. It was a real pain getting apps like Program Manager and File Manager ported to this thing.

Some of you can probably see Program Manager in the above screenshot... Yup, that's build 55's Program Manager running on this build. I know you all want the ported apps - or maybe you don't, idk. Here they are anyway. Paintbrush does not work. File Manager will become weird when it's not in real mode, appears to be something related to DOS interrupt handing of this build - I could be wrong. jb881122 also found that the string functions seen in USER of later builds are not there yet, so if you want to port something to this build make sure you change them to use the KERNEL functions.

This build is one of the first to place system files in the WINDOWS\SYSTEM folder, of course without the new Setup it's pretty hard to get it installed that way. Here is a screenshot of the Windows directory of a correctly set up install - the rest of the files must go into WINDOWS\SYSTEM.

Ohh by the way I've seen some fast boot code in the real mode kernel - this build may be one of the last to support the Windows 1.x and 2.x installation method (aka chained NEs loaded by kernel), or maybe not. Further analysis required.

There is a built-in resource format called "Error Table" in this build. This is probably the only build we have with that resource type, it got taken out of the headers some time before RTM. RT_ERRTABLE's ID is 11.

While you can see .DLL being referenced everywhere, this build does not support dynamic-link libraries for apps with .DLL extension, so all libraries must use .EXE as their extension.

Managed to get the SDK working so enjoy some sample apps. Link. RAINBOW.DLL is a sample custom control library and SELECT.EXE is also a dynamic-link library so you won't be able to run those two. Have fun with them.





WinHelp is never going to run because they linked it to the DOS libraries so it's a DOS app that call WinAPI functions (which probably will point to nothing). I can see they have also embedded the symbols, which is not something that they do very often.

Finally, this is a debug build. Patching USER.EXE by zeroing the byte at 0xC4E4 makes it report as non-debug. It makes absolute no difference (as far as I can tell) but things like WINVER, Program Manager and File Manager will not say it's debug anymore.

Bye.

[vbdasc]

It seems that 3.0.33 386 Enhanced mode requires less than 16MB RAM and DOS < 4.x.
I could run 286 Standard mode in DOSBox DOS, but have to boot from HDD image (with MS-DOS 3.31) for 386 Enhanced mode.

Seems like an issue that could be solved with SETVER or "VER SET".

[yksoft1]

It seems that 3.0.33 386 Enhanced mode requires less than 16MB RAM and DOS < 4.x.
I could run 286 Standard mode in DOSBox DOS, but have to boot from HDD image (with MS-DOS 3.31) for 386 Enhanced mode.

Seems like an issue that could be solved with SETVER or "VER SET".

Not exactly a problem that can be solved by faking DOS version.
the WIN386 just causes a reboot if not really running from DOS < 5.0 even though I SETVERed win.com, dosx.exe and win386.exe as I tested that also in PCem V12.
It could be that the new FCB in DOS 5.x/6.x that prevented the 386 protected kernel file system to work.

[vbdasc]

FCBs changed in DOS 5? Why would MS make changes to an obsolete structure?

[Battler]

Windows 3.0 looks like 3.0 in all aspects except for the shell.

I think it would be rather weird if it didn't

Oops, I meant that Windows 3.00.33 looks like 3.0 in all aspects except for the shell.

- yksoft1: It could also be that the build hits some bug in PCem v12 that has since been fixed, so I would recommend trying in 86Box or a newer version of PCem.