MIDI Mayhem on Windows 10

So I know it’s ‘probably’ the super cheap generic USB to MIDI dongal I got on the cheap, but it just doesn’t work on Windows 10.

Using DOSBox, I get the following output when cycling between devices on the console:

MIDI:Opened device:win32
MIDI:win32 selected Microsoft GS Wavetable Synth
MIDI:Opened device:win32
MIDI:win32 selected USB2.0-MIDI
MIDI:Opened device:none
MIDI:win32 selected MIDIOUT2 (USB2.0-MIDI)
MIDI:Opened device:none

As you can see it clearly can see the USB device, but when it opens the device it fails. And yes I’ve tried Administrator.  And for the hell of it, I fire up Windows XP on VMWare, connect the USB dongal, and amazingly:

MIDI:Opened device:win32
MIDI:win32 selected USB Audio Device
MIDI:Opened device:win32
MIDI:win32 selected USB Audio Device [2]
MIDI:Opened device:win32
MIDI:win32 selected Microsoft GS Wavetable SW Synth
MIDI:Opened device:win32

Yes, I can open the out port just fine.  So now I run a virtualizer to run my emulator to drive a physical peripheral… Ugh.  Has MIDI been this messed up all along and I never noticed?

Oh yeah, the GS Wavetable Synth works fine, as did MUNT before I uninstalled it, thinking it was somehow interfering with anything.

I know I’m using this fine device, the QinHeng USB MIDI adapter, which apparently is notorious crap, but my recently acquired Yamaha MU 80, works fine with it on Windows XP.

QinHeng USB MIDI adapter

QinHeng USB MIDI adapter

Ugh.

Ported UAE 0.7.6 to MinGW!

0.7.6

0.7.6

I can’t find any source of the 0.5 versions, and I had issues with 0.6.x  but with enough mashing of stuff around I did manage to get 0.7.6 to compile, then leaning more on the xwin.c source file I was able to get the SDL output working for 32bit depth (does anyone even have 8bit displays anymore?).  I suppose with this version working I can go back and take a stab at resurrecting 0.6.x

What is cool is that 0.7.6 (perhaps earlier versions of 0.7?) switched from a non commercial license to the GPL 2.0 license.

I managed to ‘fix’ the keyboard in this version so that not only does it not type too fast, but it’ll remember “sticky” keys like shift, control & meta.  So now you can actually use the CLI, and change disks.  Double clicking is an impossibility as it simply runs far too fast.  I compiled in audio support but didn’t bother with the SDL end, as it would sound like noise with it running so fast.

I also updated UAE 0.4, with the fixed keyboard code, and it’s usable now as well, with the same caveat that it simply is just too fast.  UAE is from an era where a 100Mhz computer was a luxury item.  Now some $5 computer, you could pack in breakfast cereal has a 1Ghz processor.

For the 2/3 people who care, I put the binary & source tree on sourceforge here. UAE 0.4 & UAE 0.1 are also available for download, plus all the source code I’ve been able to find.

GCC 1.40 on Windows

I know with all the talk of GCC 6.1.0 for MS-DOS, and other platforms, you must be thinking that all this talk of progress, and high versions numbers just isn’t right!  I’ve just started to migrate code to GCC 5.1, and now you are telling me there is a GCC 6!

Where can I turn away from all this so called progress!  I don’t like my C compilers to be C++ programs that require massive HOURS to compile.  Can’t we just go back to the good old days?

And the answer is YES, you can!

While looking for some libraries on another project, I came across this old defunct project called RSXNT. And it’s a port of EMX to Win32 platforms!  Well isn’t that fantastic!

So, considering I was able to build GCC 1.40 and cross compile to Linux 0.11 from Windows, can we do something with this?

Well ancient versions of EMX are very difficult to track down.  Somehow I did mange to find this hybrid of 0.8B & 0.8C.  The EMX runtime & binaries are from 0.8C, but the source code is from 0.8B.  And the best thing is that the 0.8B is based around GCC 1.40!  So with a little bit of tweaking the files, and messing around I got the assembler, linker, and C compiler to build with MinGW!  Sadly the source code to EMXBIND, wasn’t included in the zips that I have, but the aformentioned RSXNT packages included a version of EMXBIND that will run on Windows!  So I managed to mash them together, and for the fun of it, I’m using the old InfoTaskForce interpreter from 1987 to complete the vintage feel.

Compiling & Binding

Compiling & Binding

Now with my executable, I can run it on MS-DOS & OS/2!

MS-DOS via DOSBox

MS-DOS via DOSBox

and OS/2 2.0!

OS/2 (on Qemu)

OS/2 (on Qemu)

Well isn’t that fantastic!

However when running RSXNT’s bind, NTBIND I got this error:

D:\emx_w32\infocom>..\bin\ntbind info2
No relocations in file:
you have not linked the NT library

Great.  Some more digging around, and if you want to make Windows programs, you need to use the RSXNT includes & libraries.  So I shifted the libraries around, and patched gcc to call the linker the same way RSXNT’s gcc driver calls it, and first go this error:

io.o: Undefined symbol __streams referenced from text segment

And looking at the stdio.h there is this:

extern struct _stdio _streams[];

No doubt, the headers & libraries are tied together.  So now making both of the RSXNT versions, I can link the executable. (YES I did try declaring the structure anyways, and I get stdout, but stdin doesn’t work).

Running on Windows 10

Running on Windows 10

Just like EMX before it, RSXNT, requires you to have the RSXNT.DLL file in your path, or in the same directory.  I suppose it’s a fair trade off.  Not that I expect there to be a surge of people cross compiling from Windows to OS/2, or even MS-DOS these days.  GCC 1.40 is ancient, 1991 vintage, but even Linus Torvalds loved it!

For comparison, GCC 5.10 produces a 55,906 byte interpreter, while GCC 1.40 produces a 88,576 byte interpreter.

For an attempt at porting some code, I choose Nethack 1.3d, and used the MS-DOS based makefiles.  It didn’t work so well, but I was able to patch in enough of the unix based termios logic, and thanks to EMX/RSXNT’s built in termios capabilities I was able to get a working version!

Nethack 1.3d on Windows 10 x64

Nethack 1.3d on Windows 10 x64

I don’t know if there really was any advantage to compiling with GCC 1.40, but it was great to see that this 1991 compiler could handily compile the 1987 based code.

How about some speed comparisons?  I dug out the ancient dhrystone.c, and gave it a shot.  I had to define 500,000,000 passes, as my computer is fast.  GCC 1.40 only offers -O for optimization, while GCC 5.1 offers many more levels, but for this quick experiment they really aren’t needed.

D:\emx\demo\dhry>gcc140.exe
Dhrystone(1.1) time for 500000000 passes = 57
This machine benchmarks at 8771929 dhrystones/second

D:\emx\demo\dhry>gcc140_O.exe
Dhrystone(1.1) time for 500000000 passes = 40
This machine benchmarks at 12500000 dhrystones/second

D:\emx\demo\dhry>gcc510.exe
Dhrystone(1.1) time for 500000000 passes = 43
This machine benchmarks at 11627906 dhrystones/second

D:\emx\demo\dhry>gcc510_O.exe
Dhrystone(1.1) time for 500000000 passes = 16
This machine benchmarks at 31250000 dhrystones/second

D:\emx\demo\dhry>gcc510_O2.exe
Dhrystone(1.1) time for 500000000 passes = 14
This machine benchmarks at 35714285 dhrystones/second

D:\emx\demo\dhry>gcc510_Ofast.exe
Dhrystone(1.1) time for 500000000 passes = 11
This machine benchmarks at 45454545 dhrystones/second

As you can see, GCC 1.40 produces the slowest code.  While it’s optimized code did beat out GCC 5.10 with no optimizations, turning on optimizations did blow it away.  And again GCC 5.1 beat out the older 1.40 for executable sizes.

29,960 gcc510_O.exe
29,996 gcc510_O2.exe
30,472 gcc510.exe
70,656 gcc140_O.exe
74,752 gcc140.exe

And this time by over a 2x lead!  It is fair to say that the new versions of GCC, despite being significantly larger do indeed produce smaller and faster code.

For anyone who’s read this far, I guess you want to take it out for a test drive?  Remember it is still EMX based, which means is wants to live on the ROOT of your hard disk.  I’m using the ‘D’ drive for myself, so if you are using C or whatever you’ll need to alter the environment vars.

You can download the exe’s and combined source here: gcc-1.40_EMX-OS2_RSXNT.7z

Stack corruption in MSYS with Windows 10

I’m sure it’s happened in other versions of Windows too.  Everything will be fine, then out of the blue you start getting errors like this:

0 [main] us 0 init_cheap: VirtualAlloc pointer is null, Win32 error 487
AllocationBase 0x0, BaseAddress 0x71110000, RegionSize 0x3B0000, State 0x10000
d:\mingw\bin\sh.exe: *** Couldn’t reserve space for cygwin’s heap, Win32 error 0
make: *** [all] Error 1

Well MSYS like Cygwin uses persistent shared memory locations, and if they become corrupt, it’s game over.

So yeah, reboot.

DR-DOS 5.0 and Windows 3.0

So I’ve always heard about the incompatibility, and I thought I’d give it a try in PCem.  I know I used to run DR-DOS 5.00 and Windows 3.0 (because of the CGA driver) and it worked fine.

So just to prove it works, here I am installing Windows 3.0 on DR-DOS 5

Installing Windows 3.0

Installing Windows 3.0

And even better, running Word 2.0! Although I did install a whopping 4MB of ram on this virtual 286.

MS Word 2.0

MS Word 2.0

And to make it all the better, I changed to a 386, and re-installed Windows 3.0 and yes it runs in enhanced mode.  And I can run DR-DOS in a windows.

386 enhanced mode

386 enhanced mode

Of course there was the AARD code, in the Windows 3.1 betas, but as far as I know that didn’t make it to release.  I was able to upgrade to a virtual VGA adapter, and update to Windows 3.1 in standard mode on a 286, just fine

Windows 3.1 standard mode on a 286

Windows 3.1 standard mode on a 286

And DR-DOS worked through the standard mode task swapper

DR-DOS in standard mode

DR-DOS in standard mode

But Windows 3.1 in enhanced mode always locked up during setup.  Maybe a PCem bug?  I’m not sure.  But Windows 3.0 works great.

Snoopy – a basic packet sniffer for Windows

(this is a guest post by Tenox)

A few days ago I wrote a basic packet sniffer / analyzer for Windows for fun. I was working with raw sockets for another application and out of curiosity winged a small packet sniffer in just 200 lines of code. I actually used it already several times to resolve some firewall port blocking issues, instead of spinning up Wireshark, so I decided to release it to public.

The good:

  • Portable, a single, tiny exe
  • Easy to use
  • Doesn’t install any driver like libpcap
  • Extensible, just 200 lines of simple code

The bad:

  • It’s very basic and doesn’t allow anything outside of simple unicast TCP, UDP and ICMP, most importantly layer 2, broadcasts, multicasts, etc are out of question
  • Currently it doesn’t directly support filtering, however you can just pipe it to findstr to filter for anything you want

Raw socket limitations are possibly the biggest issue, but if you just want to find out simple stuff like traffic going to a given port or ip address it’s a perfect little handy dandy tool to carry around.

To use snoopy you specific IP address of the interface on which you want to listen:

snoopy1There also is a verbose mode which shows some more detailed protocol information:

snoopy2Today I decode ICMP message types, TCP flags, sequence, ack and window numbers and DSCP, ECN, TTL and Dont Fragment flags for IP. I’m thinking of embedding /etc/protocols and /etc/services in a .h file to resolve them on the fly.

Bug reports and suggestions most welcome!

Available here: http://www.tenox.net/out#snoopy

 

OpenNT – Windows NT 4.5

(This is a guest post from Tenox)

Just stumbled across this: someone has forked Windows NT 4.0 and created an open source version of it. But wait, forked what? Windows source code doesn’t live on Github. Is it ReactOS? No! Upon some digging, it was apparently born from the leaked source code of NT4.0, some W2K bits and 2003 WRK.

Enter NT version 4.5:

NT45Test-2015-04-27-18-20-37More screenshots here: http://www.opennt.net/projects/opennt/wiki/Screenshots

The main project site: http://www.opennt.net/

Looking at activity the project seems to be alive and well. There is some background information and discussion going on BetaArchive for those interested.

I wonder what Microsoft has to say about this 🙂

“warning: Invalid parameter passed to C runtime function.”

So while debugging Dynamips I got this fun message under GDB.  Of course it doesn’t tell you WHAT function did it, or HOW it was trying to do it.  Fantastic.

Thankfully Dennis Yurichev’s blog gave me the hint to put a breakpoint on ‘OutputDebugStringA’ and sure enough I could see Dynamips trying to treat a socket like a stdio file handle.  Something you can’t do in Win32 world.

On the plus side, I just had to do a small re-write of some functions and I can talk to the Dynamips hypervisor!  Idle and JIT are working too!  Along with WinPcap and UDP transports.

Failure to upgrade to Windows 10

It’s been a bad hardware day for me, my MacBook Air that I bought in 2012 stopped working.  And it’ll cost at least half the price of a new one to fix it.  So instead of that I don’t want to spend that much right now so I picked up a cheap used Fujitsu laptop.  It had Windows 7 on it, which qualifies for Windows 10, so I figured I’d just use that free upgrade!

Wow that was a whole day shot by.  Although now that I’m posting this from Windows 10, it is much more faster and responsive than Windows 7.

The first big problem I had was that this laptop didn’t have *ANY* updates installed.  Service pack 1 for Windows 7 is required for the upgrade, and that is a 1GB download on it’s own!  Then after that, it demanded KB2952664 which wanted forever to install, so I said screw it and run the Windows update, which was 199 updates to go. So after all those hours, I’m finally ready to install Windows 10!

Au

I wanted an upgrade!

So during the install, about 25% of the way in, 83% copying files it suddenly reboots, and then starts to restore my prior copy of Windows.  Great, something failed.  Once back in Windows 7 I get this wonderful message:

I love these cryptic errors!

I love these cryptic errors!

0xc1900101 – 0x20004 The installation failed in the SAFE_OS phase with an error during the INSTALL_RECOVERY_ENVIRONMENT operation.

After trying more updates, defraging, it failed to upgrade another two times.  So I googled some more, and it turns out that a lot of people had laptops like this Fujitsu that were partitioned 50/50 and people would convert their disk from a basic MBR to a dynamic disk, so they could destroy the un-needed and wasteful D drive, and merge it into a nice C drive.  So what is the fix? UGH you have to convert the disk back to a basic disk with a normal MBR.  Except You can’t easily revert as you can convert.  So a bunch of more time wasted with a Windows Vista DVD that can read the disk, and an external drive let me copy windows off, redo the disk as MBR and restore Windows.

After all that drama the Windows 10 upgrade went without a hitch!

Bottom line, is that it’s probably easier to just buy a copy of Windows 10.  There is a utility to convert a dynamic disk to a basic disk, Partition Wizard Pro which costs $39.  Which is better towards a copy of 10.

Oh well it’s finally done.

Update review

Update review

Probably a bad time to ask.

20 years of Windows 95

Windows 95

Windows 95

It’s hard to believe that it has been 20 years since the release of Windows 95.  But here we are.

Windows 95 started it’s life as a 32bit upgrade from Windows 3.1 code named ‘Chicago’ to compete with the 32bit version of OS/2 for the desktop.  Chicago is more famous for it’s incredible delays as the project suffered from feature creep, along with a complete UI redesign.  It’s also worth noting that even back as far as October of 1992, just after the release of Windows 3.1 Microsoft was already hard at work on Win32s, the Win32 subset and compatibility layer for Windows 3.1 to run Windows NT Win32 applications.

Windows 1.x didn’t make much splash on the market.  Windows 2.x added much needed features like overlapping windows, and of course the 386 version included a 386 v86 mode hypervisor.

In my opinion, Windows 3.0 was the most significant piece of software that Microsoft has ever shipped.  This was the point where they broke away from IBM, and went their own way.  And it showed that they were capable of launching a major environment without the support of their biggest partner.  Although sadly, OS/2 paid the price.

95 launch

95 launch

Windows 95 would be a close second as to what would be Microsoft’s most significant software, as it brought 32bit computing to the masses, along with a completely different user interface, one that remains popular to this day with the start button.  Even the marketing used to Rolling Stones song ‘Start me up’.  Windows 95 is also the first time (and last) that I can ever recall there being a Microsoft release party where actual users showed up, but were enthused.  Back when OS X shipped on physical media, you would see Apple fans camping out for the latest release, but for Microsoft this was the one time where the next release was going to be so significant with a whole new generation of applications like Office 95, and a much more easier to use interface people really were excited about it.  As much as Windows 10 is a great improvement on Windows 8, I don’t see anywhere near this kind of enthusiasm compared to Windows 95.

Program Manager

Program Manager

Before Windows 95 people had to fight the Program Manager, which was a MDI application which means it has windows inside of windows.  And it’s easy to obscure and lose place of programs.  I’ve seen users re-install applications because ‘they lost them’ not realizing the program group was hiding behind another window.  To many average users Program Manager was a nightmare to work with on a daily basis.

File Manager

File Manager

And to say that it’s complimentary program, File manager was also a MDI nightmare to work with was an understatement.  Again windows get hidden behind windows, it is all inside of another window so it can be confusing moving things around, and trying to get a good view.  To an average user, it’s tedious to work with and to get two full screen views of files, requires two copies of the application to run, which in the days of 4MB of ram or less was a luxury when you figure they were running an application as well.  Not to mention since there is no task bar, it was also common for people to launch multiple copies of an application since it would be hiding behind a window they didn’t know about.

Windows 95 Desktop

Windows 95 Desktop

The Windows 95 UI solved all of these problems by showing us what is running, and by unifying Program Manager, and File Manager into one.  Now we can see what is running, we have a desktop to move things around, and we can open up multiple file windows and move them around at will.  Even in this simple screen shot with multiple applications running, it’s trivial to see what is going on, and how to navigate it.  We take it for granted today, but compared to the old Program Manager, File Manager paradigm this was simply an upgrade to get enthusiastic about!

Windows 95 launch

Mikol Furneaux proudly shows off his Windows 95

And just look at this picture, isn’t this the look of excitement?  Over a piece of software?  From Microsoft?  The transition from 16bit to 32bit was so great, I really wonder if they ever again will have this kind of appeal.  Going from 32bit to 64bit has been so seamless I suspect many 64bit users don’t even know they are.

32bit applications promised (and delivered) on greater stability, and of course being able to actually use RAM that people had bought.  It was the end of segmented 64kb segments, and the use of 32bit flat memory models, that even in the game industry everyone had been flocking to 32bit MS-DOS extenders.  Now 32bit was going mainstream on the desktop.  Even though Borland had captured so much of the developer mindshare on MS-DOS, they just couldn’t achieve the same success level on Windows, and especially with Windows 95, it started the rise of Visual C++ and Visual Basic everywhere.

Networking was another strong point of Windows 95, as it included not only LAN support for TCP/IP, IPX and NetBEUI out of the box, but it also included dialup PPP support for all three protocols.  This is basically where other consumer OS really blew it, and why Microsoft not only ended up owning the desktop, but also the server space in corporations.  It was a common practise to sell the networking stack, and applications separately making a networked machine quite expensive.  SCO Xenix charged for the OS, Streams, and TCP/IP.  IBM charged separately for their TCP/IP as well.  By 1994 IBM started to see this as a mistake, and included DIALUP ONLY networking for Warp.  This stop gap measure was barely acceptable for 1994, but as the PC world got more and more connected this meant LAN connections along with wide area which IBM dropped the ball by charging yet even more for Warp Connect.  Where Windows for workgroups, Windows 95, and Windows NT included all of this, and multi-protocol support.

Microsoft also was busy creating their own online service, MSN, a competitor to AOL, CompuServe, Prodigy et al.  There is a better writeup on winsupersite than I could do, since I never did use it.  But the upshoot is that Microsoft was late to the internet party, and did not include any browser with the first retail version of Windows 95.  Later versions of course did include Internet Explorer.

The most significant early version of Internet Explorer has to be version 3, which is when Microsoft finally started to take it serious, and included things like SMTP/POP3 and USENET clients.  Back then, USENET was actually big.  This is before the rise of every website being a forum, instead we had a global distributed database that everyone could post onto.  It wasn’t instant though, so it could take days for a reply.  The kind of thing we take for granted now with many AJAX enabled websites able to alert you right away, or you can check the status with a simple refresh.

A worker packs the shelves of PC World, Croydon, with copies of the Microsoft Windows 95 upgrade computer package. The package will go on sale at midnight across the country.

A worker packs the shelves of PC World, Croydon, with copies of the Microsoft Windows 95 upgrade computer package. The package will go on sale at midnight across the country.

I may have to touch on the rise and fall of Internet explorer at a later date, but check out the exciting back of the Windows 95 box that included Internet Explorer:

Windows 95 box SE, back

Windows 95 box SE, back

For those who want to remember, the Windows 95 start sound!

And speaking of which next year will be 20 years of Windows NT 4.0, and how it utterly changed the server market forever.