Pushing Windows/386 out the door…

While one may think that Windows 2.x started with the ‘regular’ version, it does indeed turn out that rather the 386 specific version was rushed out the door to appease Compaq, and their new Desqpro 386 computer, namely the 20Mhz 386 model that was going to debut in late 1987.  Indeed, Compaq not only set the standard with the 386 CPU, but they were going to set the future standard of bundling not only MS-DOS but Microsoft Windows.  At this moment in 1987 you could really say that the ‘modern pc market’ was born.

Windows/386 2.01 from OS/2 Museum.

And it does make perfect sense, with 386 specific software being very rare/hard to come by, keeping in mind that Phar lap 386 was only announced in December of 1986!  But it was expensive, and 386 specific applications cost a fortune, and didn’t have wide market penetration (we were still years away from DOS4G/W or GCC).

Another thing to keep in mind is that OS/2 had not shipped either at this point, and apparently this version of Windows/386 would not even support the IBM PS/2 model 80, as there was some noise about IBM not wanting to bundle Windows on their computers.  Now when you think about it, it is kind of funny that Windows an inferior product came out with a GUI and multitasking MS-DOS via the 386’s v86 mode, while OS/2 was still in a beta stage.  Not to mention IBM’s reluctance to bundle Windows/386 shows just how the Windows rift was an issue even back in 1987!

Looking at this December 1987 InfoWorld issue we can see it in action:

From, InfoWorld Dec 1987, Windows/386 in action

And it’s no wonder why this was going to be a hit.  And the UI looks just like how Presentation Manager for OS/2 1.1 was going to look, almost a full year before OS/2 1.1 was delivered (Halloween 1988!)

Now trying to peg down exactly When these releases of Windows 2.x were, esp with Windows/386 2.01 being the first, in September of 1987.

From what I can work out, Windows 2.01 ‘regular’ was shipped around November of 1987, with the 2.1 update in July of 1988, and 2.11 in March of 1989.

While on the topic of Windows 2, there was one slightly interesting feature, of the ‘regular’ or ‘286’ version of this product.  It could multitask MS-DOS.  No really, but it was all out of the same conventional memory space.  So unless you were into COM programs it wasn’t terribly useful.

The later 286 versions included early himem.sys drivers that permitted some trickery with the A-20 gate allowing an additional 64kb of ram to be accessed from real mode.  It may be a good thing that nobody found out about unreal mode at the time..!

I don’t know if it is even possible to tell them apart, besides the 386 and 286 (regular) versions but here is a small gallery of Windows 2.0 running command.com

Windows 2.03

Windows/386 2.03

Windows/286 2.1

Windows/386 2.1

Windows/286 2.11

Windows/386 2.11

Included is something special for the 2 or 3 people that’ll figure it out. 🙂

Windows 3.0 …

Bill Gates with Windows 3.0 / credit:Carol Halebian

There is no denying it, when it comes to revolutionary products you simply cannot ignore the powerhouse that was, Windows 3.0 .  Simply put this is what made the Microsoft empire, broke the alliance with IBM, and changed the future of OS/2 3.0.

Not only that, but Windows 3.0 changed the way businesses operate world wide, and finally delivered on the ‘dream’ of what could be done with the 286/386 microprocessor where OS/2 had failed.

To really appreciate Windows 3.0 you have to see the world as it was before it was under development.  Back in 1989 the pc market was in turmoil.  While OS/2 had the promise of breaking all the old barriers of the real-mode only OS MS-DOS, it simply cost too much, and hardware compatibility was just too poor.  The other striking thing was that the only 386 specific feature that OS/2 1.2 (current version in 1989) could exploit was that the 386 could quickly move in & out of 286 protected mode.  The LAN server product also had a 386 specific HPFS driver, but that was it.  OS/2 1.2 was still limited to a SINGLE MS-DOS box.

OS/2 1.2’s DOS session

And there wasn’t a heck of a lot you could do memory wise.  Not to mention there was no ability for the DOS session to use EMS/XMS memory.  It’s no wonder it became to be known as the ‘penalty box’.

Meanwhile, Windows/386 circa 1987 could run multiple MS-DOS VDM’s on the 386 processor.  You were only limited by how much extended memory was in your system.  Windows/386 exploited the v86 mode of the 386 processor which allowed for hardware virtualization.  However Windows itself was a ‘real mode’ program, meaning that it had to fit in 640kb of ram, just as the VDM’s it spawned had to.

Windows/386 2.11

So unless your goal was to run a bunch of MS-DOS sessions all your extra memory was for nothing.  That also included Windows programs since they all ran in real mode.  For people with enough disk space you *could* actually install one copy of Windows/386 in say VGA, then another with a lower video resolution (CGA or EGA), then actually run Windows in Windows… in a Window.  But it really wasn’t that useful, it ran better full screen.  And all this had the effect of doing was partitioning your windows programs from each other, if you dedicated a VM per application.  Needless to say with OS/2 2.0’s seamless windows this was far more easier to setup, and frankly far more practical.

In 1989 building large applications meant that you either forced people to use Unix (SCO Xenix!) or OS/2.  For those that could afford it, Xenix would have been the way to go, as they not only ran in 386 protected mode, offered a far larger address space, but it was also multiuser!  But Xenix was expensive, needed specialized knowledge.  And as mentioned the cost of OS/2 development was HIGH, and it required your end users to have OS/2 (naturally).  And the users would have to fight that a lot of PC/AT compatible PC’s on the market were not compatible enough to run OS/2.  Despite this a lot of banks latched onto OS/2, and some still use it today (look at why parallax came into existence!).  Then out of nowhere, PharLap had developed a piece of software that changed everything, the DOS Extender.

Originally for 386 computers, the first DOS extenders required people to use special 386 compilers, runtimes, and of course linkers & extenders.  The tools were expensive, the right to redistribute wasn’t free, but end users could run your multi-megabyte (lol) applications on regular MS-DOS.  Which is what 99% of PC’s were running, and it didn’t require users to change their OS, abandon their applications, it would simply just work.

Links 386 pro

One of the earliest and most popular DOS Extended game/application was Access Software’s Links 386 pro.  That’s right this game ran in protected mode! .. And it would *NOT* run under, or near Windows/386.

It was out of this wildly great but incompatible world that the first DOS Extender vendors, tried to standardize their products with the original and short lived VCPI specification, from Phar Lap.  However in 1989 Microsoft was busy working on Windows 3.0 as the next great thing.  Using a protected mode debugger, they were converting Windows/386 from a real mode ‘hypervisor’ into a protected mode application.  And if Windows couldn’t run these new extended applications, then people would naturally have to exit Windows to run them.  And that was the major problem with Windows is that people may have an application for windows but they spent most of their time in DOS. So Microsoft’s Ralph Lipe came up with the DPMI specification, managed to get all of the major vendors to support and take over it, in exchange for leaving Windows as a 0.9 level client/server.  After all why would you need their products if Windows were to incorporate the entire 1.0 spec?  At the time it was a big deal, but the success of Windows would eventually kill the extender market save for video games until Windows 95.  There is a great article about the rise of DPMI here.

So with a firm dos extended foundation Windows 3.0 could do something the 2.x products could never do, which was to actually utilize all the memory in peoples computers.  And because it hinged on a dos extender (ever wonder what dosx.exe was?) it meant that there was no special disk, mouse, network driver/software needed as it could jump out of protected mode, and call real mode software like the BIOS, or even mouse drivers if need be.  However older protected mode programs would only error like this:

No Lotus 1-2-3 r3 for you!

Another popular application for MS-DOS just happened to be Lotus 1-2-3, and it was *NOT* DPMI compliant.  Oh sure they had DOS & OS/2 support, but would you believe that the OS/2 version wouldn’t run in a Window?  Oh sure the install program may have, but some how someone didn’t think there would be any value in being able to SEE more then one application at a time.  Not to mention the dark horse, Excel was starting to sell in 1987 like crazy, in 1988 Excel actually started to out sell 1-2-3, and by 1989 it was already over.

Lotus 1-2-3 r3 for OS/2

Microsoft Excel 2.2 for OS/2

There is no doubt about it, GUI applications were taking over.  The old ‘DOS’ interface was dead.  And Lotus had basically killed their product line by providing an identical interface and experience to their customers by providing an OS/2 application that looked and felt just like the MS-DOS application.  While you may hear that Lotus got distracted with OS/2 and missed releasing a Windows version of 1-2-3 to counter the rise of Excel, the truth is that they straight up missed windowing UI’s. Their hubris is that the users simply didn’t like the 1-2-3 interface, they wanted a windowed application.

What they did want was graphical Windows, and of course more memory!  And there is nothing more annoying than having say 16MB of VERY expensive memory in a computer like a 286, but being restricted to 640kb or less is just … insane.

So let’s see Excel in action.  Excel 2.1c shipped with a ‘runtime’ version of Windows 2.1.  Mostly because nobody was buying Windows in 1987 Microsoft had to do something to get people running the thing.  So the best way was to allow you to run an application with it.  By late 1989 and early 1990 application vendors were making updates to their products so that they could run under Windows 3.0.  And here is the first version of Excel to do so.

Excel 2.1c and the Windows 2.1 runtime

So here we have Excel running under Windows 2.1 ala the runtime environment.  All you have here is excel.  Also worth noting is that the setup program is 100% DOS text based.

Moving forward we can now upgrade to Windows 3.0.

Excel 2.1c running on Windows 3.0’s real mode

So as you can see Windows 3.0 takes up 30kb more memory then Windows 2.1!  For someone with an XT this could mean bad news!  Now it’s time to see what all the babling was about, running the same application in protected mode to access more memory!

Excel 2.1c running in Windows 3.0’s standard mode (286 and above)

Now we are running in 286 ‘standard’ mode.  Notice that Excel thinks it’s conventional memory, but we now have 14MB of the computers installed 16MB accessible to the application!  Now this is pretty amazing stuff! Now it’s no secret that the 286’s memory management left a lot to be desired, and Microsoft really didn’t want to write for it, as the 386 was where they wanted to be.  So unlike OS/2 the 286 cannot swap.  You are only limited to what extended memory you have in your computer.  But this is different for the 386..

Excel 2.1c running under 386 enhanced mode

And here we are, 386 enhanced mode! So finally  our Windows applications are clearly running in protected mode, with demand paging!  With 36MB of available memory in a computer with 16MB of ram.  The colors are distorted on Virtual PC under 386 enhanced mode… But as you can see the environment runs!  And even graphical programs that for example used CGA could happily run on an EGA system in a window.  Even better you could copy the screen, and paste it into any Windows application you want.  Yes you could buy games and use them for clipart!

Another feature of Windows 3.0 that people didn’t realize is that it could pre-preemptively multitask DOS based VDM’s

As you can see, there it is, the timeslice, and scheduling options..  Great ways to confuse users for decades… 🙂

Who could resist?

As always, there is a great InfoWorld article here.

So why was Windows 3.0 successful? A lot of it is timing, as there was no other environment that could offer people access to their whole machine without upgrading their operating system.  And of course there was the whole thing with bundling Windows, Word & Excel with new computers.  I mean who would resist something like a graphical application like Excel when compared to the klunky and significantly more expensive 1-2-3?  Sure the bundling practices were found to be illegal, but looking back, Lotus & Word perfect basically GAVE Microsoft the market.  And of course, talk about aggressive upgrades!  I’m not sure they even do such things anymore.  Although I’ve heard of big companies, and governments pushing for discounts for running things like Linux.

And there is the other things that Windows 3.0 supported that OS/2 simply did not.  For starters backgrounds (wallpapers), and of course the desk accessories.  Sure they sucked but in a panic at lest you *could* do something… where OS/2 basically left you in the lurch.  Not to mention how much more expensive OS/2 was when compared to Windows.

So with all that out of the way, what fun is a write up without a demo?

 

And thankfully I’ve found all the bits in prior posts, and I can put them together right here.

Windows 3.0 working demo, click to launch!

 

WinDoom, WinG, Win32s on Windows 3.1 (on Qemu)

So since I was looking at the Doom stuff, I thought I’d try to track down the WinG version of Doom, and luckily someone pack ratted away two versions! Needless to say the older one didn’t work for me, but the last one, the April 13th, 1995 build, worked just great!

WinDoom on Windows 7 x64

Even on Windows 7 x86_64, sp1!

So how much of a chore was this to run back in 1995, before Windows 95?

Well to start WinDoom requires a display capable of at least 256 colors. I thought I’d use Qemu for this, but this proved to be… exceptionally difficult to locate a satisfactory display driver. I know lots of people point to the SVGA.EXE update from Microsoft, that uses VESA extensions to drive the video. Oh sure it sounds great but this is what I got:

And.. corruption.

Ok, so you say, there is this great patch to enable better VESA support right?

Wrong.

Yeah. I also hunted down various cirrus drivers for the specifically emulated chip (I checked the source) and they were all consistently defective. So I tried using a lower chip driver from HP and amazingly the 640x480x16MM colors works! (well, works ‘enough’).

Installing the right driver.

It’s the GD5430 v1.25f, 640x480x16.8M

The next thing is that Doom in both MS-DOS and Windows are full 32bit executables. On the MS-DOS side, it relies on the DOS4G/W extender. For Windows, it relies on the then new Win32 standard, and Windoom was written to conform to the Win32s standard, meaning with an addon it can run on Windows 3.1, Windows 95, And Windows NT. I just fished around the internet and scored a copy of Win32s 1.25. I just remember this being a somewhat stable version.

Installing Win32s

Win32s installs pretty smooth, (as long as you remember the share.exe). Now we just need the WinG runtime to be installed. WinG was Microsoft’s first real attempt at high speed gaming video under Windows. From what I understand it kind of went down because it was ‘too difficult’, and buying DirectX seemed to be a better fit.

Setting the midi mapper.

Another thing I’ve found is that if you change the midi mapper from the default “Ad Lib” to “Ad Lib general”, you can at least get the midi working in Doom.

Once WinG is installed, then it’ll want to do some blit tests…

WinG calibrating.

And after that, we can even bump it up to glorious 640×400, something the initial MS-DOS version couldn’t do easily as VESA wasn’t a big standard with INSTALLED cards at the time, and it’d require lots of work from the iD team, where the move to Windows pushed all the peripheral development to the Vendors to work around Microsoft. Even to this day, it’s still a big deal with video and audio.

One thing that is cool about Qemu is that at compile time, you can put in adlib & soundblaster cards to give the ‘full’ Windows 3.1 multimedia experience. There is also GUS (Gravis Ultra Sound) support
in Qemu, but I’ve never played with it..

With all of that out of the way, WinDoom will launch.

WING dispdib.dll missing error that turned out to be Video for Windows.

Then it’ll throw an error, because Windows 3.1 doesn’t have the same video backend as Windows NT 3.5 (and higher), hit ok and then …

And it works! WinGDoom running on Windows 3.1 on Qemu!

Sadly on Windows 3.1 the sound effects do not seem to work, but overall it’s a GREAT little port, mostly because as it comes up on 16 years old, it still works, and with sound. I wish other OS’s could give this kind of support for legacy applications, even ones that had such a brief window of support.

Anyone crazy enough to even think of playing along can download the blob of software I used to get this going here (Updated on archive.org here: Windows-3.1-WING-doom)

I should also add if you want sound effects to work on WinDOOM you really should install the Video for Windows Runtime, and it’ll work… poorly on Qemu/SoundBlaster 16, but it does work!

Microsoft Giano

I stumbled across this the other day, Giano, a simulation framework.

Included is a bunch of stuff, like a basic x86 / cepc (with Windows CE 6.0 image), an Xbox 360 emulator, a SPOT emulator, some eval boards (AT91EB63?) with both MIPS and ARM cpus that even include a doom kernel like experience! A Macintosh G5 (I wonder if it’d boot with Apple ROMS..?) Oh and..

A VAX.

The VAX code is taken from SIMH but I guess to show how extensible the framework is, they mashed in enough microvax to get it going.

SIMH in a way you’ve never seen it…

At any rate, here is some other screen shots of Giano in action….

CEPC

xbox 360 alpha test

xbox360 console

And of course….

Giano MIPS doom

DOOM

Also buried in there is a new MIPS variant, the emips along with a donated NetBSD port!

Sadly I had no luck running NetBSD….

Default: 0/ace(0,0)/netbsd
boot: 0/ace(1,0)/netbsd
Loading: 0/ace(1,0)/netbsd
5085072+70448=0x4eae14
Starting at 0x80020000

memory segment 0 start 00000000 size 10000000
memory segment 1 start 10000000 size 00100000
Too much memory in cluster 0, trimming memory to range 00000000..08000000
Too much memory, ignoring memory range 10000000..10100000
pmap_steal_memory: seg 0: 0x50b 0x50b 0x7fff 0x7fff
pmap_steal_memory: seg 0: 0x54b 0x54b 0x7fff 0x7fff
pmap_steal_memory: seg 0: 0x54d 0x54d 0x7fff 0x7fff
Copyright (c) 1996, 1997, 1998, 1999, 2000, 2001, 2002, 2003, 2004, 2005,
2006, 2007, 2008, 2009, 2010, 2011
The NetBSD Foundation, Inc. All rights reserved.
Copyright (c) 1982, 1986, 1989, 1991, 1993
The Regents of the University of California. All rights reserved.

NetBSD 5.99.48 (RAMDISK) #0: Tue Mar 15 01:01:14 UTC 2011
[email protected]:/home/builds/ab/HEAD/emips/201103142200Z-obj/home/builds/ab/HEAD/src/sys/arch/emips/compile/RAMDISK
Xilinx ML50x (eMIPS)
total memory = 128 MB
avail memory = 120 MB
sysctl_createv: sysctl_create(no_sa_support) returned 22
mainbus0 (root)
cpu0 at mainbus0: Toshiba or Microsoft eMIPS CPU (0x70401) Rev. 1 with software emulated floating point
cpu0: 64 TLB entries
ebus0 at mainbus0
pid 0(system): trap: cpu0, TLB miss (load or instr. fetch) in kernel mode
status=0x2000000, cause=0x8, epc=0x8002d5c8, vaddr=0xd0000000
tf=0x8054cc78 ksp=0x8054cd18 ra=0x8002d5b8 ppl=0xd0000000
kernel: TLB miss (load or instr. fetch) trap
Stopped in pid 0.1 (system) at 0x8002d5c8: lw v0,0(s0)
db>

Maybe someone else will have better luck.

— edit, it seems Microsoft has a NetBSD 4.01 download, here. And it boots!

Internet Explorer 9 released..

Well today Internet Explorer 9 has been released… I guess they timed it for the pi day thing yesterday (3/14!).

You can find all the languages & versions here.

So how does it perform? Well the CP/M Javascript page doesn’t work at all in IE9 mode. In compatability mode, it can’t execute commands with an argument so booting or loading disks seems not to work. It’s such a shame.

The javascript NES emulator not only works, but seems to perform pretty well I get just under 60fps. Oddly performance is just slightly slower then Chrome, yet the sound in IE is far smoother. That was really unexpected, but still interesting.

Outside of that, I’ve only used it for 10 minutes now so I really can’t say. But we all know that for better or worse, IE always holds the largest ‘surface area’ so it will remain the most targeted. But for now it’l be fun to play with, but I’ll be lery of remaining on it.

Trumpet Winsock 2.0b

So while browsing around k7tty, I came across this file, internet.zip, that pretty much has everything you need for a windows 3.1 machine to get into the internet using Trumpet Winsock.

I used a packet driver, along with Qemu’s built in ne2000 and it works pretty well!

While I never used Trumpet back in the day, setting it up for LAN access was pretty easy, and while Trumpet 1.0 loads on Windows 3.0 I never could find any applications that actually work with it. Trumpet 2.0 seems more along the line of the finalized Winsock 1.1 stacks, with applications abound to run with it and Windows 3.1

A little more fun with the Windows 3.0 working model

FORTRAN Dungeon on Windows 3.0 Demo

So with a little pushing around I managed to create a stand alone version of dungeon (zork) for Windows 3.0 . Naturally this version doesn’t require windows, just some kind of MS-DOS system with a 80286 processor, and either EGA or VGA graphics card. I guess I could have tried some CGA/MDA love but I didn’t.

So for anyone wanting to have some fun with an ancient box, I’ve provided both floppy disk images, and an install directory source to install this. It’s kind of funny how 7zip can get another 50% on the Windows 3.0 compress utility.

Otherwise it’s like the other Windows Demo/Working model software..

Text based installer…

GUI Installer

And the desktop.

This is the old f2c version of dungeon/zork I ported ages ago. Oh and thanks to the magic that is jdosbox, you can testdrive it from a Java enabled pc just by simply clicking here.

Twinsock and early windows internet usage

A friend of mine let me know that there is a current drive by former users of trumpet winsock to actually send the author the $25 ($35 in adjusted money) that he had asked for the shareware program. While I’ve seen Trumpet, it required a SLIP or PPP connection which I just didn’t have back in 1993/1994 timeline. Sure there was SLiRP, but it was far more involved to compile on the Ultrix machine university gave us access to, or the pay internet connection (sefl.satelnet.org!) that ran IRIX. So I ran Troy Rollo’s Twinsock.

Besides being GPL’d twinsock proxied the socket access from your Windows 3.1 computer, and ran the requests on the Unix host you connected to. The best part is that they didn’t have to know that you even ran it. Twinsock transformed the internet from being a Unix shell account that kept many people away, into a graphical experience with windows applications executing on our desktop. Since it wasn’t a real TCP/IP stack, it effectively firewalled us, and seeing we were running Windows 3.1 that was a good thing.

So to make this experence more… realistic, I took the 386BSD 0.1 image from sourceforge, and made one tweak into how it runs. I added the following to the Qemu execution:

-serial tcp:127.0.0.1:4445,server,nowait

Then I installed MS-DOS, Windows 3.1, a terminal program, and some tcp/ip programs to test into another Qemu virtual machine. I then connected the two Qemu instances like a null modem like this:

-serial tcp:127.0.0.1:4445

This way COM1 on both machines now talk together. The only major downside I’ve seen is that if the client VM is killed re-starting it doesn’t get the serial connection working, both VM’s have to be restarted from the command line.

The cool thing was I was able to use a dos terminal program and zmodem to transfer the source to 386BSD to build. Surprisingly this part went pretty smooth on all the versions of Twinsock that I tested, but version 1.3 and higher was the version that actually worked.

So with the executable built on the Unix machine, you launch the windows program, which included a minimal terminal program. And from there you can dial up, login to your Unix account, then launch the twinsock Unix component and the window minimizes and now you are ‘connected’.

Launching Twinsock

WinVN

One of the most popular programs & protocols of the “early” internet was NNTP or Net News. Net News transitioned the world from BBS’s and Forum Software. The topics were incredibly diverse, and the system was distributed by nature. And news traversed the internet in a semiquick fashion. Especially the nodes that had T1 or faster access at the time. Unlike down stream UUCP BBS’s that may only take a small feed once a day, now with Twinsock you could get whatever groups and feeds you wanted, and as fast as your little modem could download it.

So for this fun experiment, I downloaded a suitably old version of WinVN, 0.92.1. The first thing I went looking around for was a public NNTP server. A great resource for locating various news servers that have certain groups is newzbot.

So with a suitable server in hand, I was able to connect up and check a news group. It was slow and clunky like it was in the old days, but it was neat in that client server feel to know that it was running on my desktop.

MS Telnet

Naturally it wouldn’t be the internet if you still telneted all over the world for MUD’s, and even access to compilers, different systems, and school work. I had a chore of a time finding a ‘good’ telnet client, so I ended up settling with the one that Microsoft had released their own stack, ‘Wolverine’ as part of a TCP/IP protocol update for Windows for Workgroups. This stack was also significant in that this was the first time a ‘full’ and ‘real’ TCP/IP stack had been released for free. As mentioned above with Trumpet winsock, and the rest, you had to buy the network stack. This free stack was only meant for LAN access, though I’ve heard of people trying to hack PPP/SLIP stuff at the dos level, but again it wouldn’t help me, since I couldn’t SLiRP. But this was the forshadowing of how the internet was going to finally take off, and the short thriving window of 3rd party TCP/IP stacks for Windows was about to slam shut in the next release of Windows.

Mosaic 0.7

And finally we come the program that basically changed the way we do everything – Mosaic. The first web browser only worked on the NeXTSTEP, and I don’t think that Mosaic was the first PC browser, but at the time it certainly was the best. I loaded up an old version to see if it could at least hit a site by IP address, and it worked. Sadly downloading files causes the browser to crash. Mosaic was rather touchy back in the day too. Because Mosaic came from the Unix world of browsers it was a 32bit program, and needed large amounts of memory. It also was a large exe too, around 2MB! Which is far larger then doom & the dos extender! So Mosaic was the first program I can recall that needed the magical Win32s add on. I’ve mentioned Win32s before so I won’t go on and on, but like the TCP/IP from Microsoft, this also basically killed the DOS Extender market.

The first time I saw Mosaic, I was blown away, we left the world of terminals and archie/gopher/veronica to something you could use a mouse with, and enter in your own URL! It was amazing, but at the same time I thought the internet was doomed to failure as you had to READ. Oh how wrong I was to be shown later. But in the time between Windows NT 3.1 and Windows 95, there was a lot of reading expected to be done. Much like everyone at the time would reply with RTFM in the news groups for stupid questions, why there even was the “Big Dummies Guide to the Internet“, thankfully made available online, put on various shovelware CD’s and saved thanks to cd.textfiles.com.

I couldn’t get MiRC to work.. I forget what other IRC programs would actually work with Twinsock. But I didn’t spend that much time on IRC.

Oh well, that is how the internet stood in that pre Windows 95, pre wide scale PPP world. It really was amazing how fast things changed.

Migrating Windows 2003 servers to Proxmox/VE

So I’ve had this Microsoft Virtual Server 2005 install that has been chugging along since.. Well 2005. On hardware we scrounged around at work from 2000. So as you can gather, it’s getting OLD. Real old.

So now after a panic, we are finally at the crossroads of what to do from here.

Now most people would expect us to just “migrate” the server to Hyper-V but there is some major shortfalls I’ve had with Hyper-V. First you can’t remotely manage it very easily. God help you if you are on the road, on a notebook, or even… On your parents computer. The idea that you must be on a domain, and install some 300MB+++ file is totally insane, and completely unacceptable.

The other catastrophic issue we’ve had is that running the x64 version of OpenBSD has been met with failure so that enterprise is virtually over.

So, let’s revisit Proxmox VE.

Now to start small, I’m going to migrate the 2003 domain controller. Luckily it’s configured for IDE disks (phew!) and basically doesn’t do anything else other then act as a DC. The steps to do this in a quick and easy manner is something like this:

1 Remove those blasted MS extensions! You can ONLY do this while you are under MS Virtual Server. Really. I expect this also holds true for Hyper-V.

2 Next run the mergeide.reg, file which will tell 2003 (probably 2000 and above…) to enable all the IDE controller types on boot, so you don’t get locked out…

3 Next download and install this GREAT program, selfimage (sorry for the lame download thing), and go ahead and run it.

Make sure you set the source to being a WHOLE DISK, not a partition… Start with the C drive. (I always try to get the OS going before going after data drives & whatnot….).

Next you can set the target to NBD and point it to your proxmox server, and set the port to 1024.

I didn’t know this, but NBD is a network block device! So instead of playing with intermediate disks, formats, and all this other painful crap, we can instead basically dd from one disk to another over the network, with little effort. I would imagine for the WindowsPE crowd this would be a massive win, to say image disks out of other servers, or even LIVE servers.. Although if it were SQL I sure would shut down the database server at this time.

On the proxmox server go ahead and create a ‘destination’ VM, that you will copy the VM into. It’s recommended you make the destination disk larger then the source disk, so there isn’t any nasty rounding errors.

Now putty into the proxmox machine, and then you have to launch the nbd server. The syntax is something like this:

qemu-nbd -t /var/lib/vz/images/xxx/vm-xxx-disk.qcow2

The filename may be slightly different, so don’t sweat it too much, but basically you are telling qemu-nbd to ‘serve’ this virtual disk.

With all of this in place, you can now hit the start button on the SelfImage application and it’ll start to block copy!

I have a slow network where I’m doing this so it took me about an hour to do 32GB.

Once it is done, you can terminate qemu-nbd with a Control+C, then try to start up the VM on Proxmox.

Two things I ran into:

Some error about processor.sys, and a 0x000000CE error code. For me the easy way out of this is to shut down the VM, and re-configure it to disable KVM. In this mode it will be SLOW. But once booted up, you can issue the following from a command prompt:

sc config processor start= disabled

Shut down the VM, turn on KVM, and start it up again. Also the start= isn’t a typo, it really is entered that way.

The other error I had was a INTERNAL_POWER_ERROR blue screen. I tried playing with the ACPI, and some other stuff to no avail. The only way to seemingly ‘fix’ it was booting up again with KVM disabled, and when I tried to login, windows immediately started to shutdown.. Re-enabling the KVM option then let me boot normally. I’m still a little lost as to what this was all about.

So with all the little stops here & there, my VM is now running on Proxmox VE.

MinGW-w64

Well after yesterdays x86_64 excitement, I figured I’d take a look in the windows area to see about the 32bit vs 64bit performance on Windows…

I know this isn’t the ‘best’ test as I’m using VMWare Fusion on OS X and running Windows XP x64 sp2 (the 2007 edition, not the 2003 one).

If anyone wants to know how to get a 64bit gcc on windows, this is the best formula I’ve come up with so far.

First download a build of mingw-w64-bin_x86_64 from sourceforge… Right now I’m using a ‘Personal Build’ from sezero_20101003, because… it’s recent, and I would imagine a personal build has some hope of actually working.

I downloaded that, and extracted to the root of the C drive. Then I renamed the mingw64 to mingw.

Next up, I downloaded and installed MSYS 1.0.11, and installed that. I selected the default options, and of course specified my mingw is installed in

C:/mingw

After that, I install the MSYS DTK 1.0, again with default options.

The final part is some kind of editor, I like VIM but it’s… involved to download as the default package ‘vim-7.2-1-msys-1.0.11-bin.tar.lzma’ is in a 7zip compatible archive that needs a bit of tweaking to get a tar file out of. I can provide it here in gzip format, that you can simply extract within the msys command prompt in the /usr directory.

Now with all that done, you should be in business!

$ gcc -v
Using built-in specs.
Target: x86_64-w64-mingw32
Configured with: ../gcc44-svn/configure –host=x86_64-w64-mingw32 –target=x86_6
4-w64-mingw32 –disable-multilib –enable-checking=release –prefix=/mingw64 –w
ith-sysroot=/mingw64 –enable-languages=c,c++,fortran,objc,obj-c++ –enable-libg
omp –with-gmp=/mingw64 –with-mpfr=/mingw64 –disable-nls –disable-win32-regis
try
Thread model: win32
gcc version 4.4.5 20101001 (release) [svn/rev.164871 – mingw-w64/oz] (GCC)

 

But will it run Dungeon?

What is also cool, is that this build of mingw includes gfortran, which is a Fortran 95 compiler with various 2003 & 2008 enhancements. So for the heck of it, I’ve rebuilt the makefile from dungeon-2.5.6 and tweaked the machdep.f to at least call the ITIME function to get the current time. The resulting archive runs pretty well!

Windows XP x64 - dungeon

Yes, it runs! And without a *32 meaning this is a 64bit binary!

 

Onward with SIMH

So going back to SIMH as my benchmark, here is the vax780 with -O0/-O0

Dhrystone(1.1) time for 500000 passes = 18
This machine benchmarks at 27777 dhrystones/second
Dhrystone(1.1) time for 500000 passes = 20
This machine benchmarks at 25000 dhrystones/second
Dhrystone(1.1) time for 500000 passes = 19
This machine benchmarks at 26315 dhrystones/second

Which comparing it to the native x86_64 build is pretty good considering I’m running this in a VM (VMware Fusion!). Now the same test with -O1/-O1

Dhrystone(1.1) time for 500000 passes = 12
This machine benchmarks at 41666 dhrystones/second
Dhrystone(1.1) time for 500000 passes = 12
This machine benchmarks at 41666 dhrystones/second
Dhrystone(1.1) time for 500000 passes = 12
This machine benchmarks at 41666 dhrystones/second

Which is pretty good! Now for the finally with -O2/-O1

Dhrystone(1.1) time for 500000 passes = 12
This machine benchmarks at 41666 dhrystones/second
Dhrystone(1.1) time for 500000 passes = 12
This machine benchmarks at 41666 dhrystones/second
Dhrystone(1.1) time for 500000 passes = 12
This machine benchmarks at 41666 dhrystones/second

Which is interesting in that there is no appreciable difference in the -O2/-O1 vs the -O1/-O1 build. Although I kind of expect different results on a native machine. If anyone else cares to test, I’m going to make available the whole project here. This includes the source and the pre-built binaries.

Unzip it on a win64/win32 machine and it should be somewhat straightforward to build / run. You can alter the makefile and change the primary CC flags from O0 to O1 or O2 if you so wish… just run make and it’ll generate a vax780.exe . Then in the test directory you can bench your exe like this:

$ make
gcc -O0 -c -o VAX/vax_cpu.o VAX/vax_cpu.c -I. -DVM_VAX -DVAX_780 -DUSE_INT64 -DU
SE_ADDR64 -I VAX -I PDP11
gcc -O0 -c -o VAX/vax_cpu1.o VAX/vax_cpu1.c -I. -DVM_VAX -DVAX_780 -DUSE_INT64 –
DUSE_ADDR64 -I VAX -I PDP11
gcc -O0 -c -o VAX/vax_fpa.o VAX/vax_fpa.c -I. -DVM_VAX -DVAX_780 -DUSE_INT64 -DU
SE_ADDR64 -I VAX -I PDP11
VAX/vax_fpa.c: In function ‘op_cmpfd’:
VAX/vax_fpa.c:210: warning: integer constant is too large for ‘long’ type
VAX/vax_fpa.c:210: warning: integer constant is too large for ‘long’ type
VAX/vax_fpa.c:211: warning: integer constant is too large for ‘long’ type
VAX/vax_fpa.c:211: warning: integer constant is too large for ‘long’ type
VAX/vax_fpa.c: In function ‘op_cmpg’:
VAX/vax_fpa.c:233: warning: integer constant is too large for ‘long’ type
VAX/vax_fpa.c:233: warning: integer constant is too large for ‘long’ type
VAX/vax_fpa.c:234: warning: integer constant is too large for ‘long’ type
VAX/vax_fpa.c:234: warning: integer constant is too large for ‘long’ type
VAX/vax_fpa.c: In function ‘vax_fadd’:
VAX/vax_fpa.c:371: warning: integer constant is too large for ‘long’ type
VAX/vax_fpa.c:373: warning: integer constant is too large for ‘long’ type
VAX/vax_fpa.c:386: warning: integer constant is too large for ‘long’ type
VAX/vax_fpa.c: In function ‘unpackd’:
VAX/vax_fpa.c:525: warning: integer constant is too large for ‘long’ type
VAX/vax_fpa.c:525: warning: integer constant is too large for ‘long’ type
VAX/vax_fpa.c: In function ‘unpackg’:
VAX/vax_fpa.c:540: warning: integer constant is too large for ‘long’ type
VAX/vax_fpa.c:540: warning: integer constant is too large for ‘long’ type
VAX/vax_fpa.c: In function ‘norm’:
VAX/vax_fpa.c:548: warning: integer constant is too large for ‘long’ type
VAX/vax_fpa.c:548: warning: integer constant is too large for ‘long’ type
VAX/vax_fpa.c:548: warning: integer constant is too large for ‘long’ type
VAX/vax_fpa.c:549: warning: integer constant is too large for ‘long’ type
VAX/vax_fpa.c:549: warning: integer constant is too large for ‘long’ type
VAX/vax_fpa.c:557: warning: integer constant is too large for ‘long’ type
VAX/vax_fpa.c: In function ‘rpackfd’:
VAX/vax_fpa.c:574: warning: integer constant is too large for ‘long’ type
VAX/vax_fpa.c:575: warning: integer constant is too large for ‘long’ type
VAX/vax_fpa.c: In function ‘rpackg’:
VAX/vax_fpa.c:597: warning: integer constant is too large for ‘long’ type
gcc -O0 -c -o VAX/vax_cis.o VAX/vax_cis.c -I. -DVM_VAX -DVAX_780 -DUSE_INT64 -DU
SE_ADDR64 -I VAX -I PDP11
gcc -O0 -c -o VAX/vax_octa.o VAX/vax_octa.c -I. -DVM_VAX -DVAX_780 -DUSE_INT64 –
DUSE_ADDR64 -I VAX -I PDP11
gcc -O0 -c -o VAX/vax_cmode.o VAX/vax_cmode.c -I. -DVM_VAX -DVAX_780 -DUSE_INT64
-DUSE_ADDR64 -I VAX -I PDP11
gcc -O0 -c -o VAX/vax_mmu.o VAX/vax_mmu.c -I. -DVM_VAX -DVAX_780 -DUSE_INT64 -DU
SE_ADDR64 -I VAX -I PDP11
gcc -O0 -c -o VAX/vax_sys.o VAX/vax_sys.c -I. -DVM_VAX -DVAX_780 -DUSE_INT64 -DU
SE_ADDR64 -I VAX -I PDP11
gcc -O0 -c -o VAX/vax_syscm.o VAX/vax_syscm.c -I. -DVM_VAX -DVAX_780 -DUSE_INT64
-DUSE_ADDR64 -I VAX -I PDP11
gcc -O0 -c -o VAX/vax780_stddev.o VAX/vax780_stddev.c -I. -DVM_VAX -DVAX_780 -DU
SE_INT64 -DUSE_ADDR64 -I VAX -I PDP11
gcc -O0 -c -o VAX/vax780_sbi.o VAX/vax780_sbi.c -I. -DVM_VAX -DVAX_780 -DUSE_INT
64 -DUSE_ADDR64 -I VAX -I PDP11
gcc -O0 -c -o VAX/vax780_mem.o VAX/vax780_mem.c -I. -DVM_VAX -DVAX_780 -DUSE_INT
64 -DUSE_ADDR64 -I VAX -I PDP11
gcc -O0 -c -o VAX/vax780_uba.o VAX/vax780_uba.c -I. -DVM_VAX -DVAX_780 -DUSE_INT
64 -DUSE_ADDR64 -I VAX -I PDP11
gcc -O0 -c -o VAX/vax780_mba.o VAX/vax780_mba.c -I. -DVM_VAX -DVAX_780 -DUSE_INT
64 -DUSE_ADDR64 -I VAX -I PDP11
gcc -O0 -c -o VAX/vax780_fload.o VAX/vax780_fload.c -I. -DVM_VAX -DVAX_780 -DUSE
_INT64 -DUSE_ADDR64 -I VAX -I PDP11
gcc -O0 -c -o VAX/vax780_syslist.o VAX/vax780_syslist.c -I. -DVM_VAX -DVAX_780 –
DUSE_INT64 -DUSE_ADDR64 -I VAX -I PDP11
gcc -O0 -c -o PDP11/pdp11_rl.o PDP11/pdp11_rl.c -I. -DVM_VAX -DVAX_780 -DUSE_INT
64 -DUSE_ADDR64 -I VAX -I PDP11
gcc -O0 -c -o PDP11/pdp11_rq.o PDP11/pdp11_rq.c -I. -DVM_VAX -DVAX_780 -DUSE_INT
64 -DUSE_ADDR64 -I VAX -I PDP11
gcc -O0 -c -o PDP11/pdp11_ts.o PDP11/pdp11_ts.c -I. -DVM_VAX -DVAX_780 -DUSE_INT
64 -DUSE_ADDR64 -I VAX -I PDP11
gcc -O0 -c -o PDP11/pdp11_dz.o PDP11/pdp11_dz.c -I. -DVM_VAX -DVAX_780 -DUSE_INT
64 -DUSE_ADDR64 -I VAX -I PDP11
gcc -O0 -c -o PDP11/pdp11_lp.o PDP11/pdp11_lp.c -I. -DVM_VAX -DVAX_780 -DUSE_INT
64 -DUSE_ADDR64 -I VAX -I PDP11
gcc -O0 -c -o PDP11/pdp11_tq.o PDP11/pdp11_tq.c -I. -DVM_VAX -DVAX_780 -DUSE_INT
64 -DUSE_ADDR64 -I VAX -I PDP11
gcc -O0 -c -o PDP11/pdp11_xu.o PDP11/pdp11_xu.c -I. -DVM_VAX -DVAX_780 -DUSE_INT
64 -DUSE_ADDR64 -I VAX -I PDP11
gcc -O0 -c -o PDP11/pdp11_ry.o PDP11/pdp11_ry.c -I. -DVM_VAX -DVAX_780 -DUSE_INT
64 -DUSE_ADDR64 -I VAX -I PDP11
gcc -O0 -c -o PDP11/pdp11_cr.o PDP11/pdp11_cr.c -I. -DVM_VAX -DVAX_780 -DUSE_INT
64 -DUSE_ADDR64 -I VAX -I PDP11
gcc -O0 -c -o PDP11/pdp11_rp.o PDP11/pdp11_rp.c -I. -DVM_VAX -DVAX_780 -DUSE_INT
64 -DUSE_ADDR64 -I VAX -I PDP11
gcc -O0 -c -o PDP11/pdp11_tu.o PDP11/pdp11_tu.c -I. -DVM_VAX -DVAX_780 -DUSE_INT
64 -DUSE_ADDR64 -I VAX -I PDP11
gcc -O0 -c -o PDP11/pdp11_hk.o PDP11/pdp11_hk.c -I. -DVM_VAX -DVAX_780 -DUSE_INT
64 -DUSE_ADDR64 -I VAX -I PDP11
gcc -O0 -c -o PDP11/pdp11_io_lib.o PDP11/pdp11_io_lib.c -I. -DVM_VAX -DVAX_780 –
DUSE_INT64 -DUSE_ADDR64 -I VAX -I PDP11
gcc -O0 -c -o scp.o scp.c -I. -DVM_VAX -DVAX_780 -DUSE_INT64 -DUSE_ADDR64 -I VAX
-I PDP11
scp.c:470: warning: integer constant is too large for ‘long’ type
scp.c:470: warning: integer constant is too large for ‘long’ type
scp.c:470: warning: integer constant is too large for ‘long’ type
scp.c:470: warning: integer constant is too large for ‘long’ type
scp.c:471: warning: integer constant is too large for ‘long’ type
scp.c:471: warning: integer constant is too large for ‘long’ type
scp.c:471: warning: integer constant is too large for ‘long’ type
scp.c:471: warning: integer constant is too large for ‘long’ type
scp.c:472: warning: integer constant is too large for ‘long’ type
scp.c:472: warning: integer constant is too large for ‘long’ type
scp.c:472: warning: integer constant is too large for ‘long’ type
scp.c:472: warning: integer constant is too large for ‘long’ type
scp.c:473: warning: integer constant is too large for ‘long’ type
scp.c:473: warning: integer constant is too large for ‘long’ type
scp.c:473: warning: integer constant is too large for ‘long’ type
scp.c:473: warning: integer constant is too large for ‘long’ type
scp.c:474: warning: integer constant is too large for ‘long’ type
scp.c:474: warning: integer constant is too large for ‘long’ type
scp.c:474: warning: integer constant is too large for ‘long’ type
scp.c:474: warning: integer constant is too large for ‘long’ type
scp.c:475: warning: integer constant is too large for ‘long’ type
scp.c:475: warning: integer constant is too large for ‘long’ type
scp.c:475: warning: integer constant is too large for ‘long’ type
scp.c:475: warning: integer constant is too large for ‘long’ type
scp.c:476: warning: integer constant is too large for ‘long’ type
scp.c:476: warning: integer constant is too large for ‘long’ type
scp.c:477: warning: integer constant is too large for ‘long’ type
scp.c:477: warning: integer constant is too large for ‘long’ type
scp.c:478: warning: integer constant is too large for ‘long’ type
scp.c:478: warning: integer constant is too large for ‘long’ type
scp.c:479: warning: integer constant is too large for ‘long’ type
scp.c:479: warning: integer constant is too large for ‘long’ type
gcc -O0 -c -o sim_console.o sim_console.c -I. -DVM_VAX -DVAX_780 -DUSE_INT64 -DU
SE_ADDR64 -I VAX -I PDP11
gcc -O0 -c -o sim_fio.o sim_fio.c -I. -DVM_VAX -DVAX_780 -DUSE_INT64 -DUSE_ADDR6
4 -I VAX -I PDP11
gcc -O0 -c -o sim_timer.o sim_timer.c -I. -DVM_VAX -DVAX_780 -DUSE_INT64 -DUSE_A
DDR64 -I VAX -I PDP11
gcc -O0 -c -o sim_sock.o sim_sock.c -I. -DVM_VAX -DVAX_780 -DUSE_INT64 -DUSE_ADD
R64 -I VAX -I PDP11
gcc -O0 -c -o sim_tmxr.o sim_tmxr.c -I. -DVM_VAX -DVAX_780 -DUSE_INT64 -DUSE_ADD
R64 -I VAX -I PDP11
gcc -O0 -c -o sim_ether.o sim_ether.c -I. -DVM_VAX -DVAX_780 -DUSE_INT64 -DUSE_A
DDR64 -I VAX -I PDP11
gcc -O0 -c -o sim_tape.o sim_tape.c -I. -DVM_VAX -DVAX_780 -DUSE_INT64 -DUSE_ADD
R64 -I VAX -I PDP11
gcc -O0 -c -o VAX/vax_cpu2.o VAX/vax_cpu2.c -I. -DVM_VAX -DVAX_780 -DUSE_INT64 –
DUSE_ADDR64 -I VAX -I PDP11
gcc -O1 -c -o VAX/vax_cpu2.o VAX/vax_cpu2.c -I. -DVM_VAX -DVAX_780 -DUSE_INT64
-DUSE_ADDR64 -I VAX -I PDP11
gcc -o vax780 VAX/vax_cpu.o VAX/vax_cpu1.o VAX/vax_fpa.o VAX/vax_cis.o VAX/vax_
octa.o VAX/vax_cmode.o VAX/vax_mmu.o VAX/vax_sys.o VAX/vax_syscm.o VAX/vax780_st
ddev.o VAX/vax780_sbi.o VAX/vax780_mem.o VAX/vax780_uba.o VAX/vax780_mba.o VAX/v
ax780_fload.o VAX/vax780_syslist.o PDP11/pdp11_rl.o PDP11/pdp11_rq.o PDP11/pdp11
_ts.o PDP11/pdp11_dz.o PDP11/pdp11_lp.o PDP11/pdp11_tq.o PDP11/pdp11_xu.o PDP11/
pdp11_ry.o PDP11/pdp11_cr.o PDP11/pdp11_rp.o PDP11/pdp11_tu.o PDP11/pdp11_hk.o P
DP11/pdp11_io_lib.o scp.o sim_console.o sim_fio.o sim_timer.o sim_sock.o sim_tmx
r.o sim_ether.o sim_tape.o VAX/vax_cpu2.o -I. -DVM_VAX -DVAX_780 -DUSE_INT64 -DU
SE_ADDR64 -I VAX -I PDP11 -lwinmm -lwsock32

Administrator@JASON-4AC1B1EA0 /usr/src/simh
$ cd test/

Administrator@JASON-4AC1B1EA0 /usr/src/simh/test
$ ../vax780.exe bsd42.ini

VAX780 simulator V3.8-1
loading ra(0,0)boot
Boot
: ra(0,0)vmunix
199488+56036+51360 start 0x11a0
4.2 BSD UNIX #9: Wed Nov 2 16:00:29 PST 1983
real mem = 8384512
avail mem = 7073792
using 102 buffers containing 835584 bytes of memory
mcr0 at tr1
mcr1 at tr2
uba0 at tr3
hk0 at uba0 csr 177440 vec 210, ipl 15
rk0 at hk0 slave 0
rk1 at hk0 slave 1
uda0 at uba0 csr 172150 vec 774, ipl 15
ra0 at uda0 slave 0
ra1 at uda0 slave 1
zs0 at uba0 csr 172520 vec 224, ipl 15
ts0 at zs0 slave 0
dz0 at uba0 csr 160100 vec 300, ipl 15
dz1 at uba0 csr 160110 vec 310, ipl 15
dz2 at uba0 csr 160120 vec 320, ipl 15
dz3 at uba0 csr 160130 vec 330, ipl 15
root on ra0
WARNING: should run interleaved swap with >= 2Mb
Automatic reboot in progress…
Tue Nov 8 03:44:30 PST 1983
Can’t open checklist file: /etc/fstab
Automatic reboot failed… help!
erase ^?, kill ^U, intr ^C
# ./d2;./d2;./d2
Dhrystone(1.1) time for 500000 passes = 19
This machine benchmarks at 26315 dhrystones/second
Dhrystone(1.1) time for 500000 passes = 19
This machine benchmarks at 26315 dhrystones/second
Dhrystone(1.1) time for 500000 passes = 18
This machine benchmarks at 27777 dhrystones/second
# sync
# sync
# sync
#
Simulation stopped, PC: 80001629 (BNEQ 80001630)
sim> q
Goodbye

Administrator@JASON-4AC1B1EA0 /usr/src/simh/test
$

The d0,d1,d2 are the dhyrstone benchmark compiled with -O0, -O1, and -O2 respectively. This gives you a chance to observe various optimizations in the GCC 2.7.2.2 for the VAX.