I’ve been trading emails with various people from the project after I had made my post, and helping them integrate more of Visual Studio 2003 into the project and working through a few issues to bring far better compatibility to VS 2003.
And the best part is being able to build projects in parallel!
I haven’t ordered new processors, so the 2.1Ghz parts are… lacking. However being able to use all available cores makes building DOSBox pretty fast.
Restricting the build to a single process takes 1:13 while the full parallel build on this machine takes a mere 10 seconds!
I uh, also saw this on archive.org, which may help people looking for this stuff from the future as old tools get harder and harder to find. Especially bigger editions like the Enterprise Architect version.
I saw this the other day, VC6 Ultimate. It’s an interesting ‘update’ on the old Visual C++ 6.0 product with an improved UI, along with updated compiler toolchain taken from later versions of Visual C++. Naturally something like this is 1000000% unofficial.
Portable and compatible with Win7 / Win10
bye bye regedit, hello .hjson setting file !
also meaning it should not mess with your current install
More compatible compiler
multicore version of VC7.1 compiler (It’s fast)
you can compile with other compilers (64bit), but not debug yet
Real-time highlighting and diagnostics
based on libclang 6.0 and compatible with VisualAssistX
Real multicursor editing
search, sort, number, evaluate, etc. while in multicursor mode
Improved UX and UI
32bit icons, dark skin, lot of visual hints
revamped dialogs (project settings, threads, breakpoints, …)
searchable command palette
It’s free (as in free beer)
ever had to pay for a birthday present ? 😉
Every change has a toggle
only take what you like, but we can not check each combination
It’s an internal spare time project
don’t expect everything to work in every setup, but feel free to reach out
Included in the bundle is the following compilers:
clang version 3.8.0 (branches/release_38)
Microsoft (R) 32-bit C/C++ Optimizing Compiler Version 13.10.6030 for 80×86
Copyright (C) Microsoft Corporation 1984-2002. All rights reserved.
Microsoft (R) C/C++ Optimizing Compiler Version 14.00.40310.41 for AMD64
Copyright (C) Microsoft Corporation. All rights reserved.
It’s an interesting project, although I tried to re-build some Visual C++ 2003 projects and it bombed out. Maybe it’s just more geared towards VC 6 as indicated.
So I’m back out, and on my limited machine (I did order something new, but on a group buying thing so it won’t be here for another SIX weeks… but then I’ll be on the road again so if I’m lucky 11 weeks……..) I’m using Visual C++ 2005 Express Edition, which by default includes just enough to compile simple stdio CLI based stuff. To do anything more complicated you need what is known as the ‘Platform SDK’. And to match up for the time period I’m using the Windows® Server 2003 SP1 Platform SDK Full Download. And of course various Direct X SDK’s too.
Instructions to integrate the Platform SDK are here, although I did set this to match the expected paths that were in my setup after installing service pack 1. However I still had to manually do step 4:
Update the default.js file (found in %VSINSTALLDIR%\VC\VCWizards\AppWiz\Generic\Application\scripts\1033) and change the two lines that read:
To make life easier (for me) this is headers & libs for the platform SDK + Direct X 6 & 7, and only 18 megabytes, instead of hundreds to download platform_directx6_7.7z This has the directories and whatnot where they were expected, although you’ll have to manually add in the Direct X include & library directories, if you want to do anything with Direct X.
From the Tools menu in Visual Studio, select Options. The Options dialog box appears.
From the Options dialog box, expand the Projects and Solutions node and select VC++ Directories. In that section, add the following paths to the appropriate subsection:
LNK2019 unresolved external symbol __imp____iob_func referenced in function _ShowError
LNK2019 unresolved external symbol __imp__fprintf referenced in function _ShowError
So it turns out that some of the fundamental streams have changed, and when the SDL library is compiled it attaches LIBC into it, which then creates this fun mis-match. The fix is easy, of course, just download the source to SDL 1.25, and re-build it with Visual Studio 2015. But then you’ll get another error that /ZI and /Gy- are incompatible with eachother. I just changed /ZI to the older /Z7 setting, and I could quickly compile SDL, copy the libs to my project and happily link & run.
For anyone who wants to run this under newer versions of Windows as I know I can’t install it on Windows 8 or 10, I installed it on my Windows XP x64 machine, and uploaded it here as vc2003toolkit.7z
By the time this came out, Microsoft had started to admit that they had lost serious ground to GCC, as for years they had neglected the low end $99 market that they had dominated during their fights with Borland in the QuickC vs TurboC days. Once Borland had withdrawn from the market, Microsoft felt no need to compete and this left plenty of time for GNU tools to take hold in the marketplace. This was a stopgap reaction as a prelude to the Visual Studio Express that would happen in 2005 onward.
Elsewhere I’ve been able to find an old Windows 2003 SP1 Platform SDK image, it should certainly let this compiler build far more interesting things. Although unless you really need 2003, you really ought to look at newer stuff. Unless you like really old stuff, then as a reminder the Win32s 1.1 SDK includes the version 8.00 compiler from 1993 as well. You can download it from here: win32s-1.1-build-88-msvc32sdev.7z
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:
First run the ‘setup.exe’ from the prerequisite CD-ROM.
Set the supported application type to “Microsoft Office 2003”, and place it in a new bottle.
This will be counter intuitive.
Answer no, and the needed components will install.
Don’t worry the .net 1.1 runtime & the j# .net redistributable package will both fail. It is nothing to worry about as we need to install them manually.
CrossOver will then notice that something went wrong. We just tell it to ignore the step, and pretend everything is OK.
Just ‘Skip This Step’ and all is well.
Now that the bottle is ‘setup’ we manually install the .net 1.1 framework. First tell the installer that we are going to install the runtime component .NET Framework 1.1.
I just point the installer to the CD’s ‘dotNetFramework’ directory to the dotnetfx.exe.
And let it install.
Next I install the J# Runtime. First select the ‘other’ application type, then I select the JSharpRedistCore directory and the vjredist.exe
This should install just fine.
Next it’s time to install the MDAC 2.7 sp1 components. I select MDAC 2.71 Serivce Pack 1, then point the installer to the MDAC27SP1 directory, and select the mdac_typ.exe installer
And the MDAC components should install without issue.
Now for some reason I’ve had issues swapping CD’s so I ‘cheat’ and do the following:
Programs -> Run Command, then open up the ‘Debug Options’ and choose Open Shell.
From here I simply do this:
$ cd ‘/Users/neozeed/Library/Application Support/CrossOver/Bottles/Microsoft Visual Studio 2003/drive_c’
drive_c neozeed$ mkdir temp
drive_c neozeed$ mkdir vs2003
drive_c neozeed$ cd vs2003
vs2003 neozeed$ cp -R /Volumes/VSPROD2/* .
vs2003 neozeed$ cp -R /Volumes/VSPROD1/* .
Now we can go ahead and install Visual Studio.
I find it easier to ‘Open the C: Drive’ which will take us to the 2003 folder, then we can choose the vs2003\setup\setup.exe executable. The vs2003\setup.exe will take note that the pre-requisites are installed, then just exit.
Use the ‘other application’ template, and make sure it is installing to the bottle you’ve been installing to so far!
Assuming you’ve done this right, it’ll take a while
And with any luck you’ll finally see this!
Now you can select what to install
And again this will take a few minutes.
Then it bombs out with a Failed LookupAccountNameW: … which I think a few installers bomb on stuff like this. So close.
Anyways it’ll install but not work. 🙁
Sorry to get your hopes up, I know I’m kinda disappointed.
So I figured it’d be as good time as any to see how various compilers (mostly Microsoft) stack up on the Itanium. So I built SIMH, and loaded up 4.2 BSD & the old dhrystone benchmark.
And before we get to the numbers, I’m using a 900Mhz Itanium 2, clearly the bottom of the barrel. I ended up loading Windows 2003 server, as XP for the Itanium can’t even install Internet Explorer 7. If you thought a world of Internet Explorer 6 was fun, it’s hell when it is your only browser.
In addition, Visual C++ 2005 was never released on the Itanium, they made it as far as Beta 2, before discontinuing native support. However I like it’s debugger so I’m using the Beta 2 version.
Microsoft (R) C/C++ Optimizing Compiler Version 13.10.2240.8 for IA-64 (from the Feb 2003 platform SDK)
Dhrystone(1.1) time for 500000 passes = 77 This machine benchmarks at 6493 dhrystones/second
Dhrystone(1.1) time for 500000 passes = 76 This machine benchmarks at 6578 dhrystones/second
Microsoft (R) C/C++ Optimizing Compiler Version 14.00.50215.44 for Itanium (Visual Studio 2005 beta)
Dhrystone(1.1) time for 500000 passes = 64 This machine benchmarks at 7812 dhrystones/second
Dhrystone(1.1) time for 500000 passes = 65 This machine benchmarks at 7692 dhrystones/second
Intel(R) C++ IA-64 Compiler for applications running on IA-64, Version 10.1 Build 20080112 Package ID: w_cc_p_10.1.014
Dhrystone(1.1) time for 500000 passes = 53 This machine benchmarks at 9433 dhrystones/second
Dhrystone(1.1) time for 500000 passes = 53 This machine benchmarks at 9433 dhrystones/second
And for some sense of what the emulation is like…
Microsoft (R) 32-bit C/C++ Optimizing Compiler Version 10.20.6166 for 80×86 (visual C++ 4.2)
Dhrystone(1.1) time for 500000 passes = 92 This machine benchmarks at 5434 dhrystones/second
Dhrystone(1.1) time for 500000 passes = 91 This machine benchmarks at 5494 dhrystones/second
Not to bad, the Intel compiler is 2x the speed of an i386 executable, while it’s easily 18% + faster then the Microsoft Compiler. I built everything with /Ox flags (Which the Intel compiler honers!).. Executable sizes varied as much as the performance.
1,672,704 Intel C vax780.exe 986,624 Vax780feb2003.exe 495,616 Vax780visualc4.exe 1,232,896 vax780visualstudio2005b2.exe
And of course the larger the executable the faster it ran. No wonder EPIC was driving people insane!