• Please review our updated Terms and Rules here

Looking for Windows 3.0 DDK

When I started at Qualitas (386MAX) in 1990, a couple days after I started, the boss/owner (who I already knew as a friend) and another guy, came in my office and dropped a big box on my desk. It was like 10" tall box of 8-1/2 x 11 sheets. The doc from that Windows 3 DDK beta.

And they said "Make this work" (meaning the 386MAX features under Windows). <sigh>
 
NeXT said:
Hay man, you gotta save that random beta build that feels completely the same as the countless other test builds because this one has a few unimportant DLL's tweaked. Could be someone's ticket to fame for discovering history! ;)
Click to expand...

betawiki: Oh yes, we're a private repository and only the leet may apply.

bitsavers: It's all there, deliberately rsync-able. Take everything, even give it to the Internet Archive so they can mangle the file names and directory heirarchy. I heard yesterday that Brewster had never heard of bitsavers, even though it's been around for almost 25 years now and they've been taking all the content for many, many years.
 
wrljet said:
When I started at Qualitas (386MAX) in 1990, a couple days after I started, the boss/owner (who I already knew as a friend) and another guy, came in my office and dropped a big box on my desk. It was like 10" tall box of 8-1/2 x 11 sheets. The doc from that Windows 3 DDK beta.

And they said "Make this work" (meaning the 386MAX features under Windows). <sigh>
Click to expand...
What did you think of 386Max? Everyone I knew either used the built in DOS memory manager or QEMM. I have a copy of 386Max only because it came with Microsoft C.
 
Unknown_K said:
What did you think of 386Max? Everyone I knew either used the built in DOS memory manager or QEMM. I have a copy of 386Max only because it came with Microsoft C.
Click to expand...
Well, since I was involved in building it, it was basically all I used (at that time). 386MAX did things EMM386 couldn't.

I've never used QEMM, although we had it kicking around for testing comparisons.
There was a continual race to try and squeeze the last byte out of everything, as that's what magazine reviewers often did.

My job was to get all those features to continue to work when Windows fired up. Which was, simply, a nightmare.

The part I built, primarily 386MAX.VXD, was shipped on the Windows 3.1 distribution disks. I spent many hours over several weeks on the phone with a manager at MSFT to talk them into that. I think it paid off for everyone involved by reducing the tech support nightmare when people upgraded from Windows 3.0 to 3.1.

386MAX was included with MSC 7. MSC7 was a DPMI application, and originally MSFT just assumed everyone would run it under Windows, in a DOS window. During the beta test period it became clear to them, this wouldn't be the case. So they shipped 386MAX with it as a DOS loadable DPMI host.

We used KRNL386.exe from Windows (without WIN386) to test our DPMI support.

I have many memories of that era. Not all good.

Bill
 

Attachments

  • IMG_1116.jpg
    IMG_1116.jpg
    2 MB · Views: 3
I have a copy of 386Max as well as other similar products. Used them.

Isn't it a bit odd that 16-bit MSC was promoting the Phar Lap extender at the same time?

When compiling MSC on MSDOS (not under Windows), I use the HX extender, although the need for that is gradually vanishing, as I port more and more of my code to Linux--and much of it to dedicated MCUs. But there are still applications with yards and yards of assembly.
 
Yes, I guess sometimes the right hand doesn't know what the left hand is doing.

Before Qualitas I used the Phar Lap DOS extender (and Metaware High C) at STSC for our PC APL product.

For a long time I used (at home) a 32-bit flat model code producing C compiler that was part of one of the early Windows DDKs.
That has Phar Lap TNT built into it. MSFT used this when they started producing VxDs in C rather than doing it all in assembler.

Code: 
E:\Packages\MSFT\MSC32-8.0\BIN>cl386 /?
E:\Packages\MSFT\MSC32-8.0\BIN\CL386.EXE: warning: invoking E:\Packages\MSFT\MSC32-8.0\BIN\CL.EXE
Microsoft (R) 32-bit C/C++ Optimizing Compiler Version 8.00
Copyright (c) Microsoft Corp 1984-1993. All rights reserved.

                            C COMPILER OPTIONS

                              -OPTIMIZATION-
/O1 minimize space                       /Op[-] improve floating-pt consistency
/O2 maximize speed                       /Os favor code space
/Oa assume no aliasing                   /Ot favor code speed
/Ob<n> inline expansion (default n=0)    /Ow assume cross-function aliasing
/Od disable optimizations (default)      /Ox maximum opts. (/Ogityb1 /Gs)
/Og enable global optimization           /Oy[-] enable frame pointer omission
/Oi enable intrinsic functions
                             -CODE GENERATION-
/G3 optimize for 80386                   /Ge enable stack checking calls
/G4 optimize for 80486 (default)         /Gs[num] disable stack checking calls
/G5 optimize for Pentium                 /Gf enable string pooling
/Gd __cdecl calling convention           /Gy separate functions for linker
/Gr __fastcall calling convention        /Gh enable hook function call
/Gz __stdcall calling convention
 
Gotta hand it to MSFT for backwards compatibility. Those binaries still work today on a 64-bit Windows 10 command prompt.
I guess the MZ header part which loads the Phar Lap, etc. is simply skipped because it sees a 32-bit PE section.
 
Reminds me a bit of the "bound" executables in OS/2 with both real-mode and PM code. NT used to be able to run the non-GUI 16-bit OS/2 stuff as well--can't recall when MS dropped the OS2 subsystem stuff from NT.

What a world...
 
wrljet said:
Of course a Win3.x/9x VxD has an MZ header and an LE header.
Click to expand...
Did any VxD do more with the MZ header than display the short message indicating what environment the driver ran under?

I hated working with Win 3 DDK. Nothing has ever presented me with more ways to provoke an unexpected crash.
 
Well, I know of at least one that did use the MZ portion.
I wrote a VxD called CAVEMAN for Rex Conn for use in 4DOS.

It created a WIN386 VM with no visible window, and ran programs there, moving the I/O between it and the GUI 4DOS app.
The MZ stub had actual code in it. Looking at the source now, it hooked all sort of things and communicated with the VxD portion.

Honestly, it's 30 years ago, and I don't remember what all it did.
I do remember it was a ball buster.

There's a mention of it Here

Bill
 
I wrote a combo VxD+real mode driver for Win3.1; the real-mode version was present as the VxD "stub". Long ago and far away. Before that was the Windows DLL; still have the files and the DLL registry number for that.
 
At Qualitas, our in-house debugger was 386SWAT. I added Windows features to SWAT that required a small helper VxD.
There was a DOS resident device driver in the MZ stub.
 
Remember when VxDs were referred to by registry number, not name?
Ours was 0x3218, obtained via the MS CompuServe account. Wonder if the registry still exists anywhere.
 
Yeah, I saw that. (I follow that blog)
386MAX and related products were very complicated.
 
One motherboard had some not-fully-decoded I/O ports and while scanning for something we managed to blow the Flash BIOS.
That caused a lot of cussing.
 
wrljet said:
It created a WIN386 VM with no visible window, and ran programs there, moving the I/O between it and the GUI 4DOS app.
The MZ stub had actual code in it. Looking at the source now, it hooked all sort of things and communicated with the VxD portion.

Honestly, it's 30 years ago, and I don't remember what all it did.
I do remember it was a ball buster.

There's a mention of it Here
Click to expand...
Wow, the ability to interact with a DOS application via a Windows 3.x application, that's living the dream right there! Microsoft's documentation said it couldn't be done, and if in the end it required writing a VxD, then it certainly couldn't have been done by me :LOL:
 
You must log in or register to reply here.
Back
Top