I cannot understand why you want this, or why I’m even going to do it. At this point in GCC history the winnt-3.5 target had been dumped in favour of going all in with Cygwin. So yeah, this does not either clearly configure, or compile. But a little bit of mashing files, and I have it at least compiling some assembly that can be translated into an object file that a later version of MinGW can actually compile.
All I’ve built is the gcc driver, the cpp pre-processor, and the cc1 aka C backend.
D:\proj\gcc-3.0.4\gcc>xgcc -c -v hi.c
Using builtin specs.
Thread model: single
gcc version 3.0.4
cc1 -lang-c -v -iprefix ../lib/gcc-lib/i386-winnt35/3.0.4/ -D__GNUC__=3 -D__GNUC_MINOR__=0 -D__GNUC_PATCHLEVEL__=4 -Dunix -DWIN32 -D_WIN32 -DWINNT -D_M_IX86=300 -D_X86_=1 -D__STDC__=0 -DALMOST_STDC -D_MSC_VER=800 -D__stdcall=__attribute__((__stdcall__)) -D__cdecl=__attribute__((__cdecl__)) -D_cdecl=__attribute__((__cdecl__)) -D__unix__ -D__WIN32__ -D_WIN32 -D__WINNT__ -D_M_IX86=300 -D_X86_=1 -D__STDC__=0 -D__ALMOST_STDC__ -D_MSC_VER=800 -D__stdcall=__attribute__((__stdcall__)) -D__cdecl=__attribute__((__cdecl__)) -D__cdecl__=__attribute__((__cdecl__)) -D__unix -D__WIN32 -D__WINNT -D__ALMOST_STDC -D__cdecl=__attribute__((__cdecl__)) -Asystem=unix -Asystem=winnt -D__NO_INLINE__ -D__STDC_HOSTED__=1 -Acpu=i386 -Amachine=i386 -Di386 -D__i386 -D__i386__ -D__tune_i386__ hi.c -quiet -dumpbase hi.c -version -o C:\Users\jason\AppData\Local\Temp\ccpflisr.s
GNU CPP version 3.0.4 (cpplib) (80386, BSD syntax)
GNU C version 3.0.4 (i386-winnt35)
compiled by GNU C version 5.1.0.
ignoring nonexistent directory "../lib/gcc-lib/i386-winnt35/3.0.4/include"
ignoring nonexistent directory "../lib/gcc-lib/i386-winnt35/3.0.4/../../../../i386-winnt35/include"
ignoring nonexistent directory "D:/pcem/building/MinGW/msys/1.0/local/include"
ignoring nonexistent directory "NONE/include"
ignoring nonexistent directory "D:/pcem/building/MinGW/msys/1.0/local/lib/gcc-lib/i386-winnt35/3.0.4/include"
ignoring nonexistent directory "D:/pcem/building/MinGW/msys/1.0/local/lib/gcc-lib/i386-winnt35/3.0.4/../../../../i386-winnt35/include"
ignoring nonexistent directory "/usr/include"
#include "..." search starts here:
End of search list.
<command line>: warning: "__STDC__" redefined
<builtin>: warning: this is the location of the previous definition
<command line>: warning: "__STDC__" redefined
<command line>: warning: this is the location of the previous definition
hi.c: In function `main':
hi.c:3: warning: return type of `main' is not `int'
as --traditional-format -o hi.o C:\Users\jason\AppData\Local\Temp\ccpflisr.s
D:\proj\gcc-3.0.4\gcc>gcc hi.o -o hi
Hello from GCC 3.0.4
So there you go, mysterious internet user! Download my source dump with binaries in the tree because I’m lazy.
With all the talk of a possible ‘rocky’ earth like planet making the news, I thought it would be fun to seek out a really ancient (ha!) OpenGL program that did a basic simulation of our solar system. I am of course talking about ssytem.
Back in the late 90’s I have to admit that this was pretty incredible to look at! Although it was using OpenGL in software only, and to be honest the best and more stable way to use ssystem was on Windows of all things.
Microsoft had a deal with SGI around the 1993 timeline, and after the release of Windows NT 3.1 they were able to work out a deal to bring Windows NT to the SGI MIPS computers platform in exchange from OpenGL being made available on Windows NT. SGI couldn’t see a way to monetize NT on their hardware and the port never actually shipped, evidence of it however is present in the leaked Windows NT 4.0 source code. However OpenGL would prove very import for Microsoft as workstation style graphics could now run on ‘prosumer’ grade OS Windows NT 3.5, and eventually there was even a runtime for Windows 95!
All the old websites, and archives of ssystem have been wiped out, however I did find a copy of the source code for version 1.6 on a HPUX site of all places.
So I thought I could start there. Ssystem needs the GLUT toolkit and I found a ‘pre-configured’ version 3.7 that Microsoft Visual C++ 6.0 can build on the command line here. Naturally with all the textures, it does rely on the IJG JPEG library (libjpeg) and I used version 6b as ssystem itself dates from 1999.
There was a bit of work to be done with the source code, as I had to massage it to compile with Visual C++, lots of missing headers, and there were some collisions in the lex for parsing the config file, but they were trivial to clean up. After a bit of going back and forth with a seemingly defective pre-built version of GLUT, re-building it myself got it to link a working executable:
Of course in this day & age, any machine these days has hardware OpenGL acceleration so it is pretty trivial to run this program.
The artifacts in the picture were common at the time, and it’s how I remember it all those years ago so I’m not to worried about it.
I tried to compile with Visual C++ 4.0 however when trying to link I got this error:
Microsoft (R) 32-Bit Incremental Linker Version 3.00.5270 Copyright (C) Microsoft Corp 1992-1995. All rights reserved.
I’m not sure why, as I re-compiled with Visual C++ 6.0 and I get a working executable. More bizarre if I try to link the objects that were compiled with Visual C++ 4.0 with Visual C++ 6.0 it also fails in the same way.
I’ve placed in everything I could find into this archive: ssystem-1.6.7z including a pre-compiled version, and the high resolution images. Along the way I also did find a backup of the site http://www.wam.umd.edu/~kamelkev/Ssystem which actually has a much smaller download of ssystem 1.6 as ssystem-1.6.zip You may need to play with ssystem.conf to get a more respectable display. I have also tweeked it to work find on my machine, using the highest values I could get away with, without running over the 2GB per process limit on 32bit processes.
Let’s also not forget the SETI crazy of the 1990’s.
I’m not talking about MingGW, Cygwin or anything else like that, but rather when support for Windows NT first appeared, it had to be compiled with Microsoft Visual C++ 1.0 of all things.
It was back in the 2.6 days of GCC, right before the stagnation that led to EGCS.
This version requires a GAS that has not yet been released. Until
it is, you can get a prebuilt binary version via anonymous ftp from
`cs.washington.edu:pub/gnat' or `cs.nyu.edu:pub/gnat'. You must
also use the Microsoft header files from the Windows NT 3.5 SDK.
Find these on the CDROM in the `/mstools/h' directory dated
9/4/94. You must use a fixed version of Microsoft linker made
especially for NT 3.5, which is also is available on the NT 3.5
SDK CDROM. If you do not have this linker, can you also use the
linker from Visual C/C++ 1.0 or 2.0.
Installing GNU CC for NT builds a wrapper linker, called `ld.exe',
which mimics the behaviour of Unix `ld' in the specification of
libraries (`-L' and `-l'). `ld.exe' looks for both Unix and
Microsoft named libraries. For example, if you specify `-lfoo',
`ld.exe' will look first for `libfoo.a' and then for `foo.lib'.
You may install GNU CC for Windows NT in one of two ways,
depending on whether or not you have a Unix-like shell and various
1. If you do not have a Unix-like shell and few Unix-like
utilities, you will use a DOS style batch script called
`configure.bat'. Invoke it as `configure winnt' from an
MSDOS console window or from the program manager dialog box.
`configure.bat' assumes you have already installed and have
in your path a Unix-like `sed' program which is used to
create a working `Makefile' from `Makefile.in'.
`Makefile' uses the Microsoft Nmake program maintenance
utility and the Visual C/C++ V8.00 compiler to build GNU CC.
You need only have the utilities `sed' and `touch' to use
this installation method, which only automatically builds the
compiler itself. You must then examine what `fixinc.winnt'
does, edit the header files by hand and build `libgcc.a'
2. The second type of installation assumes you are running a
Unix-like shell, have a complete suite of Unix-like utilities
in your path, and have a previous version of GNU CC already
installed, either through building it via the above
installation method or acquiring a pre-built binary. In this
case, use the `configure' script in the normal fashion.
Well that is quite the tall order! I can’t believe I somehow managed to build it back then, and out of curiosity I managed to build it again. And as you can see you need a ‘beta’ release of the GAS assembler, which is kind of impossible to find now, but it was part of the GNAT project, which used to distribute binary builds of the GCC core back in the day. Luckily I have a version stuffed away, although it’s from GCC 2.8.1, not as ancient as it would have when GCC 2.6 was a new thing. But it at lest assembles enough for my simple Hello World experiment.
To build GCC you need a working SED, which surprisingly CL 8.0 from the Win32s SDK, and it runs fine on Windows 7 x64 of all things. I had to mess with some of the files, and substitute the linker & headder files from Visual C++ 2.0 but much to my amazement not only can I build GCC along with libgcc.a, it also builds incredibly fast. On my machine I can compile GCC in about 5 seconds. I remember in 1995 building this on Windows 95 (I was crazy) and it taking HOURS and HOURS.
So one nice thing about these binaries is that you don’t need any external DLL’s Even the import section of a simple hello world exe is tiny:
With Windows NT 3.1 out the door there was a LOT of work to be done behind the scenes to bring Windows NT up to a more polished level, and this was most certainly achieved with Windows NT 3.5 . This version did something pretty much unheard of, which is that it dropped the hardware requirements from Windows NT 3.1 . It is almost all too easy to get lost in all the new features but I’ll try to keep a list.
OpenGL (software only)
New TCP/IP Stack
More complete Win32 support
Ability to run Win16 apps in separate WOW instances.
Added complete support for the Dec Alpha
IDE CD-ROM support
For me this was a major release, in that now Windows NT was actually usable, esp with the memory requirement dropped, and the overall speed increased NT 3.5 could actually be used. The dialup PPP support that was a SNAP to configure was the thing that won me over, I never could get the dialup scripts for CHAP/PAP/PPP on Linux to work right, but within a few minutes of installing NT 3.5, I was on the internet.
One of the cools things that came out of the Microsoft SGi collaborative was OpenGL on Windows NT. This was no doubt to bring NT into the real ‘workstation’ level of OS, and to give us great real-time 3d graphics. This was also the source of a lot of ‘server issues’ because people *LOVED* the OpenGL screen savers so much they enabled them everywhere, not realizing that they would easily take 100% of the CPU. The OpenGL was so good, that it even scaled on SMP systems, again killing them for 100% of the CPU across all CPUs. You wouldn’t be very popular loading them on the departmental SQL server.
Outside of internet applications all I pretty much ran at the time was old Win16 stuff like Turbo C++ for Windows, Watcom C++ and I’d try to run windows games, but NT just needed too much memory compared to MS-DOS/Windows 3.1 … it was a while before memory got cheap enough to tip the balance, but I did only have 8MB back then.
As for the applications I installed on NT 3.1, they all worked fine, MS-Word for DOS & OS/2, Excel 3, and Doom 1.1 ran great.
I should also mention that there was a 32bit version of Office for NT 3.5, Office 4.2 for NT. This added 32bit versions of Word & Excel for NT Alpha/i386. I don’t think there was ever native versions for the MIPS.
Windows NT 3.5 received three service packs before it was ultimately superceeded by Windows NT 3.51