Bill Nye, the Microsoft C 6 guy

So, a while back I had found this up on eBay. As much as I’m trying not to buy old stuff I just couldn’t resist. And the price was just too good, I’d just have to forego going out to dinner for a week.

While looking around for something on Microsoft C, I stumbled upon this promo video for Microsoft C 6. Naturally I had to share it!

I had been using it to mess around with a poorly ported Hack 1.03, although I haven’t done much with that in a while.

One thing is for sure, that the old MS-DOS memory limits were becoming more and more of an issue. Sadly, they didn’t include the QuickC for Windows product which had the benefit of building in protected mode for access to far more memory, nor did they include any DOS Extender to even allow larger runtime access. Obviously you were expected to run this under MSOS/2 1.2 in this era. Although targeting OS/2 protected mode allowed easier integration with PharLap’s 286 based DOS Extender.

Since this was the OS/2 era, the Windows 3.0 SDK was a separate product.

There was another release, the 6.00ax version which included a DOS Extender, allowing the compiler to access 16MB of ram, as reported in this leaflet in a combined Microsoft C & Windows 3.0 SDK package.

The followup Microsoft C/C++ 7.0 addressed many of these shortcomings, but of course famously removed targeting OS/2. There was a later update that at least provided OS/2 compiled version of the binaries allowing you to run it under OS/2. I never tried to see if it could be paired with the OS/2 SDK, and manually made to generate OS/2 executables. I suspect not.

The larger thing is that Microsoft C 386 remained a ‘hidden’ product on Xenix, and the 32bit OS/2 and NTOS/2 betas.

5 thoughts on “Bill Nye, the Microsoft C 6 guy

  1. > C/C++ 7.0…removed targeting OS/2…I never tried to see if it could be paired with the OS/2 SDK, and manually made to generate OS/2 executables. I suspect not.

    I don’t have an OS/2 SDK to try this on, but I suspect it’ll be straightforward. Visual C++ was bundled with a demo version of Phar Lap, and compiling for it means compiling an OS/2 binary. It’s actually hard to target Win16 and not 16 bit OS/2 since they have the same executable format. So it’s clear that the vast bulk of support must be there, and any restriction would be fairly contrived/artificial.

    Last time we spoke about this:

    • I recently bought a copy of MASM 6.0 on eBay and got a chance to try this out. It’s not quite as nice as C 6 (no OS/2 C runtime library) but is still designed to run on and target OS/2.

      One thing I tried was using MASM 6.0 to supply startup code, then calling main() provided by Visual C++ 1.5, which worked fine. Even the Visual C++ linker supported generating OS/2 NE binaries, it just defaults to Windows and needs to be explicitly told via “EXETYPE OS2”. The linker can link to OS/2 import libraries, it just needs header definitions. MASM doesn’t provide .h files, but does include .inc files which must be perfectly translatable (they’re just describing the calling convention.)

      Unrelated, but there’s a lot of interesting capabilities with MASM 6.0. There’s an important 6.0b update which added support for stdcall, where that capability was clearly done to support Win32. There’s a KB article about using it, although it tells people to use cvtomf which didn’t exist in the released SDK. KB articles show how to use 6.0b for 32 bit OS/2 via OS/2 2.0’s link386 and doscalls.lib too, and that part actually works. For some reason doscalls.lib was removed from Warp so doing this requires OS/2 2.x.

      • I have to try the older Microsoft C 386 compilers and their ability to output assembly. I had no real luck on other setups, but maybe this one will let me build stuff for OS/2

  2. The optimizer in C6 was badly broken. Debugging a program becomes a lot harder when the output of the compiler does not match what the source code should result in.

    • That pretty much matches what I recall where building things like hack needed you to use 5.1 for some parts as it would either crash the compiler or generate garbage.

      I thought Quick C for Windows was also based on MSC 6, but I am pretty sure I’ve had better luck with it. And of course, it running in protected mode was always a bonus!

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.