(This is a guest post by Antoni Sawicki aka Tenox)
Apps for Windows NT RISC… Alpha AXP, MIPS and PowerPC. Happy downloading.
(This is a guest post by Antoni Sawicki aka Tenox)
Apps for Windows NT RISC… Alpha AXP, MIPS and PowerPC. Happy downloading.
Somehow I never noticed this until making what seemed like a pointless GCC config.
You can apparently build a GCC like this:
sh configure –host=i386-winnt35 –target=alpha-winnt35
And you can get a cross compiler.
The real question is, does it work? I don’t know I don’t have a cross assembler, linker or a target machine.
D:\proj\gcc-3.0.4\gcc>xgcc -v
Using builtin specs.
Configured with: : (reconfigured) : (reconfigured) : (reconfigured)
Thread model: single
gcc version 3.0.4
D:\proj\gcc-3.0.4\gcc>xgcc -v -S hi.c
Using builtin specs.
Configured with: : (reconfigured) : (reconfigured) : (reconfigured)
Thread model: single
gcc version 3.0.4
cc1 -lang-c -v -iprefix ../lib/gcc-lib/alpha-winnt35/3.0.4/ -D__GNUC__=3 -D__GNUC_MINOR__=0 -D__GNUC_PATCHLEVEL__=4 -DWIN32 -D_WIN32 -DWINNT -D__STDC__=0 -DALMOST_STDC -D_M_ALPHA -D_ALPHA_ -D_LONGLONG -D__unaligned= -D__stdcall= -D__WIN32__ -D_WIN32 -D__WINNT__ -D__STDC__=0 -D__ALMOST_STDC__ -D_M_ALPHA -D_ALPHA_ -D_LONGLONG -D__unaligned= -D__stdcall= -D__WIN32 -D__WINNT -D__ALMOST_STDC -Asystem=winnt -D__NO_INLINE__ -D__STDC_HOSTED__=1 -D__LANGUAGE_C__ -D__LANGUAGE_C -DLANGUAGE_C -Acpu=alpha -Amachine=alpha -D__alpha -D__alpha__ -D__alpha_ev4__ -Acpu=ev4 hi.c -quiet -dumpbase hi.c -version -o hi.s
GNU CPP version 3.0.4 (cpplib)
GNU C version 3.0.4 (alpha-winnt35)
compiled by GNU C version 5.1.0.
ignoring nonexistent directory “../lib/gcc-lib/alpha-winnt35/3.0.4/include”
ignoring nonexistent directory “../lib/gcc-lib/alpha-winnt35/3.0.4/../../../../alpha-winnt35/sys-include”
ignoring nonexistent directory “../lib/gcc-lib/alpha-winnt35/3.0.4/../../../../alpha-winnt35/include”
ignoring nonexistent directory “NONE/include”
ignoring nonexistent directory “D:/pcem/building/MinGW/msys/1.0/local/lib/gcc-lib/alpha-winnt35/3.0.4/include”
ignoring nonexistent directory “D:/pcem/building/MinGW/msys/1.0/local/lib/gcc-lib/alpha-winnt35/3.0.4/../../../../alpha-winnt35/sys-include”
ignoring nonexistent directory “D:/pcem/building/MinGW/msys/1.0/local/lib/gcc-lib/alpha-winnt35/3.0.4/../../../../alpha-winnt35/include”
#include “…” search starts here:
End of search list.
This is what the output looks like, which looks nothing like targeting the i386 so I guess so?
.set noreorder
.set volatile
.set noat
.globl __fltused
.file 1 "hi.c"
.rdata
.quad 0
$LC0:
.ascii "Hello from GCC %s\12\0"
$LC1:
.ascii "3.0.4\0"
.text
.align 2
.globl main
.ent main
main:
.frame $15,0,$26,0
.mask 0x4008000,0
lda $30,-16($30)
stq $26,0($30)
stq $15,8($30)
mov $30,$15
.prologue 0
jsr $26,__main
lda $1,$LC0
addl $1,$31,$2
lda $1,$LC1
addl $1,$31,$1
mov $2,$16
mov $1,$17
jsr $26,printf
mov $15,$30
ldq $26,0($30)
ldq $15,8($30)
lda $30,16($30)
ret $31,($26),1
.end main
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.
Configured with:
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.
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
D:\proj\gcc-3.0.4\gcc>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.
With a filename tracked down, I was able to locate in archvie.org a partial backup of the main site here: http://www1.las.es/~amil/ssystem/english.html
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.
init.obj : error LNK2001: unresolved external symbol _glBindTexture
ssystem.obj : error LNK2001: unresolved external symbol _glBindTexture
stars.obj : error LNK2001: unresolved external symbol _glBindTexture
init.obj : error LNK2001: unresolved external symbol _glGenTextures
astrolib.exe : fatal error LNK1120: 2 unresolved externals
NMAKE : fatal error U1077: ‘link’ : return code ‘0x19’
Stop.
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.
`i[345]86-*-winnt3.5' 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 Unix-like utilities. 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' manually. 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:
GetVersion GetEnvironmentStrings GetCommandLineA ExitProcess RtlUnwind UnhandledExceptionFilter GetModuleFileNameA GetFileType GetStdHandle GetStartupInfoA VirtualFree VirtualAlloc WriteFile WideCharToMultiByte GetLastError FlushFileBuffers SetFilePointer SetStdHandle CloseHandle KERNEL32.dll
Which implies that it only needs KERNEL32 to function.
I don’t know if it’s of any use to anyone else, but HERE is my dump of all the source and tools I used to build GCC.
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.