Check out all the details on mercurysquad.com!
It’s a long long way away but it did run the userland hello world!
Check out all the details on mercurysquad.com!
It’s a long long way away but it did run the userland hello world!
Here is the changelog.
I haven’t had that much time to review it myself, but I did manage to get some binaries built!
For 99% of the people out there this is the i386 & x86_64 emulators.
I’ve moved the default NE2000 to 0x320 IRQ 10 (as always), and included support for my quick control-alt-delete & reset via control-alt-d & control-alt-r. I’ve also included the adlib emulation to go along with the SoundBlaster support (why is this left off by default?).
And for those who need the other CPU types (ARM/PowerPC/MIPS/M68k/S390) you can download it here.
All of these were built with MinGW, and are all Win32 exe’s.
Once upon a time Novell had been an unstoppable force. Â Then something happened they stopped innovating, and laughed as a ‘desktop’ unix killer did just that and ate the mid range/server PC market.
With all that’s been happening to RIM and all the cash they are sitting on I wonder if they’ll end up like Novell.
Time will tell no doubt.
With a bit of poking around in the latest Qemu 0.15.0 rc2 beta, the S390x now builds by default. Â Finding something for it to run was a bit of a stretch but I should have figured that Debian would have something.
It does take a few seconds to boot up, and by default you’ll just be sitting at a blank screen until you toggle to the virtcon0 screen.
But it’s VERY snappy… I haven’t gotten it to install (unsupported NIC?!) but I’m pretty positive it’s 100% my fault.  I’m just happy I saw it boot.  And it runs the busybox stuff just fine so it’s tentatively working.
If anyone wants to give it a whirl, download my exe, and the kernel/init.rd I’ve found that at least boot up here.
I’m hoping this will spur someone to spell out how/what to install onto it, and maybe if things like MUSIC/SP and CMS will run on it… That’d be fantastic!
In the meantime I’d imagine this combined with KVM on people with accelerated configs will enjoy some SERIOUS competition to the IBM Mainframe monopoly!
But the people I rent this VM from have had troubles. Â I know it kind of feels like that week long blogger outage all over again…. 😐
But I do like these guys in that they are far more open & honest about what is going on.
For the two or three people that care, their report on the outage is here.
Since we are running on some kind of USB dongal it is a hint that more outages are about to be ahead… I guess the hint here is to BACK UP!… So let’s hope this Uncle Joe’s EZPC OCB is going to work.. !
(UPDATE Qemu 0.15.0 has been released)
I couldn’t even begin to mention what is new in this version of Qemu other then it is a *LOT* harder to build as it now depends on glib2, and it’s way pickier about finding and resolving dependencies.  I should also add that compiling is *FAR* more intense then it was in prior versions.  At some point gcc was eating 1.8GB of ram.  And I know it’s only constrained by me using the 32bit tool chain.  I have no idea if it’ll even build with the 64bit GCC on Windows.
So with a bit of prodding I’ve managed to build the i386 version although I didn’t do much testing. Â But it does seem to work. Â So here it is, my Win32 build:
qemu-0.15.0-rc2-i386-x86_64.7z
I’ve modified it so that the NE2000 is on 0x320 IRQ 10, and I’ve slipped back in my control+alt+d for a control alt delete (CAD) substitute, along with control+alt+r for a reset hotkey.
Enjoy!
In the off chance you want your asterisk phone switch to sound like a cisco…
Turns out it’s by Darrick A. Deel and Tim Carleton, and it’s called Opus Number 1.  It was recorded in Tim’s garage some time in the late 1980’s.  Darrick works for cisco so it found it’s way into cisco’s call manager.
Phew that was interesting, wasn’t it?
*UPDATE* For those of you interested, a stereo copy has been located! Â I have more information here!
This is taken from a post by Michael Sokolov (of Quasijarus fame), all about DPMI.
Mark H. Wood <address@hidden> wrote: > Which spec is that? cwsdpmi, as I recall, implements DPMI 1.0, while > Microsoft has never gone beyond 0.9. There are significant differences > *in the spec.s*. Well, I have turned this semester's last paper in today, so I can spend a few more hours enlightening the public... Warning: I am going to give a lecture on DPMI. Feel free to skip this message, but if you do please refrain from any further participation in the work on Lynx for DOS, since an understanding of the material I present in this lecture is absolutely essential to doing any work under DOS beyond 640 KB. DPMI has been born in the fall of 1989 in a bright flash of genius of Microsoft's Ralph Lipe. At that time there was a flourishing DOS extender industry led by Phar Lap, Rational Systems (later Tenberry Software), and Ergo (formerly Eclipse and A. I. Architects). A DOS extender is some kind of software solution (they come in all sorts of flavors) that allows an application to execute in protected mode and yet retain access to the file system and other services provided by DOS via an API that closely resembles that of real-mode DOS (INT 21h and such) but with pointers to buffers and such addressing memory outside the first MB via protected-mode selectors. DOS extenders from Phar Lap, Rational Systems, and Ergo are inherently flawed in that they are built into apps. This has been done against all rationale simply because the market demanded that a protected-mode apps must not have any prerequisites and must run even in a bare environment without any pre-existing protected-mode software. However, having a separate DOS extender for every app is not much different from having a separate power plant for every light bulb. Since they want to have no prerequisites, these DOS extenders need to take the total control of the CPU and build their own protected-mode environments. Of course, this creates a hell of a problem when a machine IS running some protected-mode software. In the days of Phar Lap and friends, there were two other kinds of the latter in addition to DOS extenders: LIMulators and multitaskers. The former are things like CEMM and EMM386 that provide LIM EMS services by setting up a protected-mode environment and mapping some extended memory into the UMB space. The latter provide multiple simultaneous DOS sessions and allow the user to switch between them instantly. They do so again by setting up a protected-mode environment and using to it manage several different VMs. The result was that by 1989 there were three kinds of protected-mode environments (LIMulators, multitaskers, and DOS extenders), and all three were, oh big surprise, for the most part mutually exclusive. There were some feeble attempts (VCPI being the primary example) to make them live together, but they worked by making one environment totally yield to the other, which is unacceptable for many reasons. Microsoft has entered the protected-mode-under-DOS field in the summer of 1988 when Murray Sargent and David Weise wrote a DOS extender for a big DOS app called Windows. Until then this app was running in pure real mode and was limited by the (in)famous 640 KB barrier. Jumping over this barrier was one of the primary goals for Windows v3.00. Murray Sargent's DOS extender did this. It was a quick-and-dirty single-app DOS extender just like the ones from Phar Lap and others. There was a problem, however. When all this was happening in the summer of 1988, there already was a baby called Windows/386 v2.xx. It was another protected-mode environment developed independently by Ralph Lipe in 1987. It was not a DOS extender, but a multitasker, and its purpose was to manage several independent VMs, one running Windows and all others being DOS boxes. Although there were several VMs, each was running in V86 (real-like) mode only, and no VM had any ability to jump over the 640 KB barrier, even though each VM had its own 640 KB of memory. Windows v3.00 was supposed to include both Windows/386 (so that it could have the familiar DOS boxes) and Murray Sargent's DOS extender. There was a problem, however. The two were mutually exclusive! It was exactly the same eternal conflict between LIMulators, multitaskers, and DOS extenders that the industry had been wrestling with for a couple of years by then, except that the conflicting parties were parts of the same product! Clearly a breath of fresh air was needed. And it came. From no one but Ralph Lipe, the author of Windows/386. In a bright flash of genius, he realized that building a separate DOS extender into every app, be it AutoCAD, Lotus 1-2-3, or Windows, is just as ridiculous as building a separate power plant for every light bulb. However, getting rid of this kludge required adopting a new industry standard. Just like in order to have the same power plant serve everyone you have to agree upon a common standard on voltage, waveform, and power factor, if you are going to have common protected-mode DOS services for all apps you have to agree on the protected-mode DOS API. A logical name for the generic API to the protected-mode DOS was DOS Protected Mode Interface (DPMI), and it is the name that has ended up being chosen. The specs published by the DPMI Committee and distributed by Intel only vaguely resemble Ralph Lipe's DPMI. The INT 31h API they describe is only the low-level building-block portion of Ralph Lipe's DPMI. Its high-level portion is nothing less than a functional specification for Protected Mode DOS (hence the name). It allows one to develop an add-on to DOS or even a new version of DOS that would have a protected-mode API directly usable by protected-mode DOS apps without the need for separate built-in DOS extenders. Understandably this troubled Phar Lap and others a lot, since Ralph Lipe's DPMI makes their products unnecessary. This is the setting in which the most unfortunate event in the history of DOS has happened. Being too used to Microsoft's evils, the industry had failed to think the problem through and sided against Ralph Lipe. Before I continue any further, let me make an analogy. Suppose a group of doctors were able to cure some dreadful disease against which there were no vaccine and to which everyone were prone. Suppose that they charged a lot of money for curing this disease and made a good living on it. Then suppose that some guy came up with a vaccine that once injected totally eliminated the possibility of getting this disease. The vaccine would solve a major health problem, but it would also push the doctors making great money on curing the disease out of business. What do you think is more important, sparing millions of people of a major health problem or keeping a group of lucky doctors in business? Unfortunately, the industry has chosen the latter. Ralph Lipe agreed not to publicize his version of the DPMI spec and to create the so-called DPMI Committee to write a "public" version of the spec that would please Phar Lap and the rest of the gang. This Committee was practically headed by Bob Moote, the vice-president and co-founder of Phar Lap and the author of their 386|DOS Extender. It has prepared a castrated (deprived of the most essential component) version of DPMI and released it under the name "DPMI Version 0.9". It essentially comprises the low-level building-block portion of True (Ralph Lipe's) DPMI. Fortunately, no committee in the world could prevent Ralph Lipe from doing the right thing, and the Win386 component in Windows v3.00+ implements the full True DPMI spec. As a result, DOS apps running under its supervision (e.g., Windows itself) have immediate access to Protected Mode DOS without built-in DOS extenders. Since this is the new proper and vastly improved way of writing protected-mode DOS apps (sure enough, Microsoft itself has used it in its C/C++ Compiler v7.00), Win386 rightfully does not support apps with built-in DOS extenders using kludges like VCPI. Thus Bob Moote and his gang have made their version of DPMI a subset of True DPMI rather than a completely different interface, so that their DOS extenders could run under Win386. It is a very unfortunate fact that since Ralph Lipe has agreed not to send out copies of his True DPMI spec most people associate the name DPMI with Bob Moote's "Committee". There were, however, a few copies of the True DPMI spec sent out to people like Borland. It is interesting to note that the latter company has chosen True DPMI over Bob Moote's creature for their protected-mode DOS tools. 16-bit Borland C and Pascal compilers are targeted for the DOS/protected-mode-DOS/Windows triple, and the protected- mode DOS versions of the tools use nothing but True DPMI. Also Borland includes a True DPMI implementation of its own with these compilers. Given that copies of the True DPMI spec are out there, I'm searching for them much like Agent Mulder is searching for the truth about extraterrestrial life and intelligence. Fortunately Bob Moote's "Committee" has never made DPMI a trademark and Ralph Lipe's spec has never got Microsoft's copyright stamped on it (it was just a rough dev draft quickly typed up in WinWord, after all), meaning that if/when I find a copy of it I can immediately put it up on my FTP site. Now you may ask "what is DPMI Version 1.0 then?" As I have said before, Ralph Lipe and Bob Moote had radically different visions of DPMI, the former seeking an interface between protected-mode DOS and its apps and the latter seeking an interface for use by Phar Lap's DOS extenders. "DPMI Version 0.9" has been produced perhaps in an hour by ripping out Ralph Lipe's high-level APIs, but there are still references to it dangling around, making it clear to anyone reading the spec that something is obviously missing. Being dissatisfied with the fact that his ugly "DPMI Version 0.9" still contained hints toward its original purpose and didn't completely subvert to his ideology, he set out to write a spec that would not contain a single word by Ralph Lipe and instead would be geared fully toward Phar Lap's DOS extenders. The result is commonly known as "DPMI Version 1.0". I still wonder why did Bob waste his time on writing it, as it was clear even to a porcupine that it would never be implemented, since its alleged purpose was light years apart from the real purpose of DPMI (which started being accepted by the industry, partly because Microsoft and Borland compilers used it). It is a grave mistake to treat "DPMI Version 1.0" as an improvement upon "DPMI Version 0.9", it is merely a further move away from True DPMI. A very unfortunate fact is that DJGPP and CWSDPMI have chosen to use Bob Moote's lopsided idea of DPMI instead of its true nature. Certainly this is due to DJ Delorie simply not knowing about the existence of True DPMI, which in turn is certainly due to the scarcity of the copies of the True DPMI spec. It is still a pity, though, that DJGPP uses only the low-level building-block APIs that are suitable to Bob Moote's selfish interests and builds a separate power plant for every light bulb (i.e., builds the DOS API translation engine into every app by making it a part of the statically-linked libc.a). The conclusion of this lecture is that I need to continue searching for the truth that is out there, so that I could finally bring it to light after all these years (True DPMI: 1989, "DPMI Version 0.9": 1990, "DPMI Version 1.0": 1991). This would mean finding a copy of the True DPMI spec, putting it up on my FTP site, and writing a software development suite that would produce apps for it, as well as writing a public-domain implementation of it (to my knowledge all existing ones are commercial, except possibly the DOS emulation under Linux). A billion thanks for reading! If you read up to here, please drop me a note :-). > Stuff compiled with DJGPP works just fine for me on Win95 [...] OK, so DJGPP is at least correct after all, although severely misguided because of the lack of knowledge. > [...] which is (among > other things) a DPMI provider and certainly written by Microsoft. The Protected Mode DOS component of Windows 95 is virtually identical to that of Windows v3.00 and v3.1x. In all of them it is written by Ralph Lipe and is the reference implementation of True DPMI. > The same stuff also seems just fine using cwsdpmi. OTOH, when I tried running a True DPMI client under CWSDPMI, it sent about 2 KB of binary garbage to stdout and exited. Note that this client does check for BobMootish DPMI hosts that implement only the low-level building-block API and prints an appropriate error message if one is found, so what I have seen indicates that CWSDPMI's implementation of the low- level building-block API is also screwed. Well, it should be no surprise for anyone that CWSDPMI is a specialized gadget for DJGPP and doesn't even resemble True DPMI. If you want the latter without running Windows, your current choices are (to my knowledge) 386Max and QEMM-386 with QDPMI. There also is the Borland DPMI host, but it's 16-bit only. Oh, and OS/2, Windows NT, and Novell DOS all implement True DPMI. Sincerely, Michael Sokolov Phone: 440-449-0299 ARPA Internet SMTP mail: address@hidden P.S. It is really swinish for me to be bashing Bob Moote, since he has once done me a significant personal favor, but I simply can't put my personal interests and obligations above my duty to the industry. P.P.S. A lot of my knowledge of this subject has been derived from direct phone conversations with the key players in this field, including Murray Sargent, Ralph Lipe, Bob Moote, and Dan Spear (author of QEMM-386 and QDPMI).
I found this on Microsoft… Gordon Bell‘s page.
Sad to think the PDP-1 really shifted us away from the mainframe, but DEC couldn’t just wrap it’s head around the micros. Â Oh and remember the computer is behind the people, yes *ALL* those cabinets.
Looking at hup.hu, it’s a pretty popular subject (hit wise)…
I’d imagine it ought to be as simple as slapping in some diskettes and away you go. Â But personally I find the video speed of OS/2 on virtualbox to be horrific. Â But at the same time it runs all the 386 friendly versions so…. It’s the ‘best’ and only solution for OS/2 1.0 onward….
I would imagine you guys could post issues…?
I’ve run it on Virtual PC 2007 ‘ok’ although the combination of SIO & Hyperterm uploading or downloading from a ‘shared drive’ always leads to Hyperterm crashing like crazy.
I’m not sure if that is even anything to really write home about.
But don’t write off using Qemu to run OS/2.