unresolved symbol imp__iob_func aka SDL 1.25 & Visual Studio 2015

Posted on August 30, 2017 by neozeed

While trying to build something with Visual C++ 2015 Community edition I got this fun error while trying to link:

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.

Visual C++ Toolkit 2003

Posted on September 17, 2016 by neozeed

For those 2-3 people still searching for this thing, it’s the old ‘free’ CLI C++ compiler from Visual Studio .NET 2003.

Although Visual C++ .NET 2003 SP1 gives you a later version of the compiler…

I’m not sure if you can service pack this toolkit.

You can download it from my site asÂ VCToolkitSetup.exe

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Â

Ssystem 1.6

Posted on August 25, 2016 by neozeed

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.

ssystem-1.6-src-11.00.tar.gz

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:

ssystem in orbit around Europa.

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:

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.

Did you know that GCC used to support Windows NT ?

Posted on September 26, 2014 by neozeed

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 least 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 is 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.

SDL 1.2.15 not working with Visual Studio 2003 (2002, 6, 97..)

Posted on June 24, 2014 by neozeed

Well yeah fun errors like this:

SDL “error LNK2001: unresolved external symbol __alloca_probe_16”

What gives? well the binary kit was built using 2005 (I guess) something higher.

Download and link againstÂ SDL-devel-1.2.13-VC6.zip and all will be happy. Â I suppose you could build the source yourself, but who’s got time for that?

And remember to set your project to use the Multi Threaded DLL libc, otherwise you’ll get errors like this:

LNK2005: __isctype already defined in LIBCMT.lib(isctype.obj)
LNK2005: _exit already defined in LIBCMT.lib(crt0dat.obj)

Ok?

Installing Visual Studio 2003 on CrossOver (OS X)

Posted on January 20, 2014 by neozeed

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.

Step 1

Components install

This will be counter intuitive.

Answer no, and the needed components will install.

Pre-requisites

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.

Everything is fine!

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.

Install .net 1.1

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

J# Runtime Install

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

MDAC Installation

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/* .
cd ..

Now we can go ahead and install Visual Studio.

Lets choose the right setup.exe

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!

Choosing Setup

Assuming you’ve done this right, it’ll take a while

And with any luck you’ll finally see this!

Visual Studio 2003 EULA

Now you can select what to install

Selecting components

And again this will take a few minutes.

Final Failure..

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.

SIMH on the Itanium…

Posted on May 1, 2011 by neozeed

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!

Itanium….

Posted on April 21, 2011 by neozeed

This isn’t virtual, but rather the real deal. I scored an HP zx2000.

My HP zx2000

Just got it out of the box, I had to remove the funky sides to get it under my desk… And I’ve just installed Windows XP onto it now. My first observation is that the included DVD drive from HP, the HL-DT-ST GDR8160B has got to be one of the slowest drives I’ve dealt with in a while. And kinda finicky as the first attempt at installing XP failed with all kinds of errors, while a swift kick and a power cycle got the thing running. And let’s see it in action..

This thing likes to tell you over and over that it’s the 64bit version. It may look like XP but it’s not the 32bit version. It is however much like the x86_64 version with no NTVDM, no WOW. But worse, no Virtual PC. It can run i386 win32 exe’s but at a performance penalty. I saw mention that the Itanium C compiler can be found in the November 2001 Platform SDK, so I downloaded that, and installed it.

It’s slow.

It’s annoyingly slow.

All that talk of EPIC, and moving the complexity to the compiler isn’t a joke. Did I mention, it is *SLOW*? I thought it was running an i386 version of the compiler but the taskman didn’t show any stars next to the processes so I’m assuming not, but I’m not sure. I also am assuming that the November 2001 SDK is timed with the “Windows 2000 Advanced Server Limited Edition” for the Itanium. So I figured for a quick test, I’d build some dungeon… Except the f2c interpreter broke in some strange manner. I’d first think it’s something to do with integer sizes, but it worked on x86_64.. So I cheated, used the i386 version of f2c, and built the library and dungeon. Also I found out about this flag, /As32 which builds exe’s in the 32bit address space. f2c will run once it’s built like that. And although compiling f2c takes forever, once built it is FAST.

It worked. The exe is over 900kb! Without at doubt when they called it EPIC they meant the compiler speed, and exe size. For the crazy, you too can play zork on your Itanium here.

And yes my attempt at building SDL bombed too. But I’ll have to spend more time with the box.

SIMH benchmark numbers…

Posted on November 14, 2010 by neozeed

I have to admit, I’m really surprised. In the past Visual C++ had been a clear winner every time I’d checked performance vs Gcc. And the tide seems to have really turned under Windows 7 x64. While not a massive lead, the winner after all these iterations of my simh benchmark was Gcc 4.5.2 for x86_64.

Just in the same fashion here, it seems that on some platforms -O1 is faster then -O2, and you really won’t find out until you run some comparisons.

gcc version 3.4.5 (mingw-vista special r3)

gcc O0
21.33333333333333
Dhrystone(1.1) time for 500000 passes = 23
This machine benchmarks at 21739 dhrystones/second
Dhrystone(1.1) time for 500000 passes = 20
This machine benchmarks at 25000 dhrystones/second
Dhrystone(1.1) time for 500000 passes = 21
This machine benchmarks at 23809 dhrystones/second

gcc O1
15.33333333333333
Dhrystone(1.1) time for 500000 passes = 16
This machine benchmarks at 31250 dhrystones/second
Dhrystone(1.1) time for 500000 passes = 15
This machine benchmarks at 33333 dhrystones/second
Dhrystone(1.1) time for 500000 passes = 15
This machine benchmarks at 33333 dhrystones/second

gcc 02
12.33333333333333
Dhrystone(1.1) time for 500000 passes = 12
This machine benchmarks at 41666 dhrystones/second
Dhrystone(1.1) time for 500000 passes = 13
This machine benchmarks at 38461 dhrystones/second
Dhrystone(1.1) time for 500000 passes = 12
This machine benchmarks at 41666 dhrystones/second

gcc version 4.5.2 20101002 (prerelease) [svn/rev.164902 – mingw-w64/oz] (GCC)

gcc O0
21.33333333333333
Dhrystone(1.1) time for 500000 passes = 21
This machine benchmarks at 23809 dhrystones/second
Dhrystone(1.1) time for 500000 passes = 22
This machine benchmarks at 22727 dhrystones/second
Dhrystone(1.1) time for 500000 passes = 21
This machine benchmarks at 23809 dhrystones/second

gcc O1
13.33333333333333
Dhrystone(1.1) time for 500000 passes = 13
This machine benchmarks at 38461 dhrystones/second
Dhrystone(1.1) time for 500000 passes = 14
This machine benchmarks at 35714 dhrystones/second
Dhrystone(1.1) time for 500000 passes = 13
This machine benchmarks at 38461 dhrystones/second

gcc O2
12
Dhrystone(1.1) time for 500000 passes = 11
This machine benchmarks at 45454 dhrystones/second
Dhrystone(1.1) time for 500000 passes = 13
This machine benchmarks at 38461 dhrystones/second
Dhrystone(1.1) time for 500000 passes = 12
This machine benchmarks at 41666 dhrystones/second

Microsoft (R) C/C++ Optimizing Compiler Version 16.00.30319.01 for x64

VC /Od /Bi0
21.33333333333333
Dhrystone(1.1) time for 500000 passes = 21
This machine benchmarks at 23809 dhrystones/second
Dhrystone(1.1) time for 500000 passes = 21
This machine benchmarks at 23809 dhrystones/second
Dhrystone(1.1) time for 500000 passes = 22
This machine benchmarks at 22727 dhrystones/second

VC /O2 /Ob2 /Oi
13
Dhrystone(1.1) time for 500000 passes = 13
This machine benchmarks at 38461 dhrystones/second
Dhrystone(1.1) time for 500000 passes = 13
This machine benchmarks at 38461 dhrystones/second
Dhrystone(1.1) time for 500000 passes = 13
This machine benchmarks at 38461 dhrystones/second

VC /O2
13.66666666666667
Dhrystone(1.1) time for 500000 passes = 14
This machine benchmarks at 35714 dhrystones/second
Dhrystone(1.1) time for 500000 passes = 13
This machine benchmarks at 38461 dhrystones/second
Dhrystone(1.1) time for 500000 passes = 14
This machine benchmarks at 35714 dhrystones/second

Vc /Og /Ox
13
Dhrystone(1.1) time for 500000 passes = 13
This machine benchmarks at 38461 dhrystones/second
Dhrystone(1.1) time for 500000 passes = 13
This machine benchmarks at 38461 dhrystones/second
Dhrystone(1.1) time for 500000 passes = 13
This machine benchmarks at 38461 dhrystones/second

Microsoft (R) 32-bit C/C++ Optimizing Compiler Version 16.00.30319.01 for 80×86
VC /Og /Ox
13.33333333333333
Dhrystone(1.1) time for 500000 passes = 14
This machine benchmarks at 35714 dhrystones/second
Dhrystone(1.1) time for 500000 passes = 13
This machine benchmarks at 38461 dhrystones/second
Dhrystone(1.1) time for 500000 passes = 13
This machine benchmarks at 38461 dhrystones/second

And this is on my laptop, an Intel Core i7 Q 720 running at 1.6Ghz with 4GB of ram & Windows 7 Home Premium.

Serweb 0.3

Posted on July 2, 2010 by neozeed

So a while back when I installed a copy of Windows NT 3.1, and put it on the internet, I looked high and low for a web server. Somehow I found this small web server, Serweb by Gus Estrella, which seemed to fit the bill. However one thing that I did notice after a while is that it had a tendency to crash, and it’d require manual intervention to hit an ‘ok’ dialog box. The other stumbling block, was that it was a Win16 application, and Windows NT 3.1 only supports a single WOW instance…. So running Serweb and Netscape always led to issues…

Then the other day, I actually found the source code to serweb! So the first thing I did was to remove the message box function that was preventing me from letting this thing ‘just run’. Well that was cool, but I wondered if this thing was from 1993, meaning it’s MFC dependencies shouldn’t be that involved it may even port to a Win32 application.

So with a few tweaks, mostly in the resource scripts, I was able to rebuild serweb as a win32 application! For the 2-3 people who care about this kind of thing, you can download it here.

I would suspect it’d run on the Dec Alpha or the MIPS, but I haven’t even tried to build it there, as I run NT 4.0 on both of those platforms, and I end up using the IIS that is available.

Serweb 0.3 on WindowsNT 3.1

I do have to admit, I’m kinda surprised that Visual C++ 1.0 for Win32 could handle this… I’ve had pretty mixed results with it, but oddly enough converting a MFC Win16 to a Win32 MFC app seemed somewhat straight forward. It’s probably more so to Gus Estrella’s work then anything I did…!

Virtually Fun

Fun with Virtualization

Category Archives: Visual C++