| ▲ | mikewarot 4 days ago |
| The cool thing about OS/2 2.1 was that you could easily boot off of a single 1.44 Mb floppy disk, and run multitasking operations, without the need for the GUI. I had (and likely have lost forever) a Boot disk with OS/2, and my Forth/2 system on it that could do directory listings while playing Toccata and Fugue in D minor in a different thread. I wrote Forth/2 out of pure spite, because somehow I heard that it just wasn't possible to write OS/2 applications in assembler. Thanks to a copy of the OS/2 development kit from Ward Christensen (who worked at IBM), and a few months of spare time, Forth/2 was born, written in pure assembler, compiling to directly threaded native code. Brian Matthewson from Case Western wrote the manual for it. Those were fun times. |
|
| ▲ | JdeBP 3 days ago | parent | next [-] |
| There was an awful lot of nonsense put about during the Operating System Wars, a lot of it by people who had not the first bloody clue about operating systems at all. Sometimes it was a very clueless manifestation of the telephone game effect, where the fact that OS/2 API was designed to be easily callable from high-languages, without all of the fiddling about with inline assembly language, compiler intrinsics, or C library calls that one did to call the DOS API, could morph into a patently ridiculous claim that one could not write OS/2 applications in assembly language. Sometimes, though, it was (as we all later found out) deliberate distortion by marketing people. Patently ridiculous? Yes, to anyone who actually programmed. The book that everyone who wanted to learn how to program OS/2 would have bought in the early years was Ed Iaccobucci's OS/2 Programmers Guide, the one that starts off with the famous "most important operating system, and possibly program, of all time" quotation by Bill Gates. Not only are examples dotted throughout the book in (macro) assembly language, there are some 170 pages of assembly language program listings in appendix E. |
|
| ▲ | cmiller1 3 days ago | parent | prev | next [-] |
| > I wrote Forth/2 out of pure spite, because somehow I heard that it just wasn't possible to write OS/2 applications in assembler I was thinking about this recently and considering writing a blog post about it, nothing feels more motivational than being told "that's impossible." I implemented a pure CSS draggable a while back when I was told it's impossible. |
| |
| ▲ | JdeBP 3 days ago | parent [-] | | We've all done it. (-: For some while I read people saying that, despite the existence of Paul Jarc showing how svscan as process 1 would actually work and Gerrit Pape leading the way with runit-init and demonstrating the basic idea, one could not do full system management with daemontools and wholly eliminate van Smoorenberg init and rc. * https://code.dogmap.org/svscan-1/ * https://smarden.org/runit/ It was one of the motivating factors in the creation of nosh, to show that what one does is exercise a bit of imagination, take the daemontools (or daemontools-encore) service management, and fairly cleanly layer separate system management on top of that. Gerrit Pape pioneered the just-3-shell-scripts approach, and I extended that idea with some notions from AIX, SunOS/Solaris, AT&T System 5, and others. The service manager and the system manager did not have to be tightly coupled into a single program, either. That was another utter bunkum claim. * https://jdebp.uk/Softwares/nosh/#SystemMangement * https://jdebp.uk/Softwares/nosh/guide/new-interfaces.html Laurent Bercot demonstrated the same thing with s6 and s6-rc. (For clarity: Where M. Bercot talks of "supervision" I talk of "service management" and where M. Bercot talks of "service management" as the layer above supervision I talk of "system management".) * https://skarnet.org/software/s6-rc/overview.html The fallacy was still going strong in 2016, some years afterwards, here on Hacker News even. * https://news.ycombinator.com/item?id=13055123 |
|
|
| ▲ | jeberle 4 days ago | parent | prev | next [-] |
| That is very cool. I had a similar boot disk w/ DOS 3.x and TurboPascal. It made any PC I could walk up to a complete developer box. Just to be clear, when you say "without the need for the GUI", more accurately that's "without a GUI" (w/o Presentation Manager). So you're using OS/2 in an 80x25 console screen, what would appear to be a very good DOS box. |
| |
| ▲ | kev009 3 days ago | parent | next [-] | | OS/2 had an evolving marketing claim of "better DOS than DOS" and "better Windows than Windows" and they both were believable for a time. The Windows one collapsed quickly with Win95 and sprawling APIs (DirectX, IE, etc). It exists in that interesting but obsolete interstitial space alongside BeOS of very well done single user OS. | |
| ▲ | mikewarot 3 days ago | parent | prev | next [-] | | Circa 1987, DOS boot disk had a "Backpack" hard disk driver on it, so I could plug it in the parallel printer port and boot up with 300 Megabytes of my stuff instantly available as D: on on any customer machine. It made service calls a lot easier to manage, no more stacks of floppy disks. 300 Megabytes!!! I had all my source code on it, archives, utilities, compilers, the whole shebang! | | |
| ▲ | glhaynes 3 days ago | parent [-] | | Surely 30 MB in 1987, not 300, right? | | |
| ▲ | mikewarot 2 days ago | parent [-] | | Here's the PDF of the product line[1] with the price list from 1987.... 300 Megabytes was $789. I was the entire tech staff for Management Support Systems, and had written an inspection reporting system for fossil fuel generating systems in Turbo Pascal under MS-DOS that talked to Norand corporation portable computers with Symbol Technologies barcode scanners. The portables were rated for a 3 foot drop to concrete, and you could use them outdoors in winter, with gloves on... amazing stuff. [1] http://www.bitsavers.org/pdf/microSolutions/MicroSolutions_P... | | |
| ▲ | glhaynes 2 days ago | parent [-] | | I stand corrected! Awesome, thanks for the link and the story. |
|
|
| |
| ▲ | tengwar2 3 days ago | parent | prev | next [-] | | You could write your own GUI rather than using a text screen. I had to do that as I was working under OS/2 1.0, which didn't have the Presentation Manager. it did mean providing your own character set (ripped from VGA on DOS in my case) and mouse handing. Btw, I'd love to know where this idea about no assembler programs on OS/2 came from. There was no problem at all with using MASM, with CodeView to debug on a second screen. | | |
| ▲ | rbanffy 2 days ago | parent | next [-] | | > Btw, I'd love to know where this idea about no assembler programs on OS/2 came from. It’s certainly a misunderstanding - nothing prevents someone from writing assembly. Could also be a lack of official documentation on how to make the API calls from assembly. Another possible source is that you can’t access the hardware directly in OS/2, which was more closely associated with low-level programming. | | |
| ▲ | tengwar2 2 days ago | parent [-] | | But you could access the hardware directly. I don't remember the details, but I build a hardware clock running at 10ms cycle time and was able to poll it. Also my build relied fundamentally on reading from a couple of external DAC converters which presented 2 x 10-12 bits for x and y coordinates to some sort of PIO arrangement which I don't now recall. I didn't write a device driver, which I remember as being significantly more difficult (mainly because you couldn't use CodeView). Just as a brief explanation: this was in the late 80's. I was using a device called an imaging photon detector to detect individual photo events. This was the back end of an early electronic camera running at about ISO 1G. Not a digital camera - the photo events were recorded as analogue xy coordinates, with a resolution of about 400x400 and a photon rate of about 100k/s (not an exact figure - as the rate increased, you lost an increasing number of events due to clash. I had a load of wire-wrap to rearrange the bits before they were presented to the computer (bit-bashing on the 80386/33 wasn't fast enough), then the xy coordinated were presented to some sort of PIO. In some cases I wanted to take video, hence the hardware clock, since the nearest thing available on the PC only ran at something like 13.3Hz and was used for polling the mouse. There was no GUI available at the time, so I built my own. I don't remember a huge amount of detail, and the source is on 5¼" floppy, but as I remember it none of this was difficult for a very amateur self-taught C/asm programmer. The only significant problem was working out that the OS/2 1.0 documentation of the mouse system lied (it didn't have the display capability claimed, and attempting to use it shut down mouse polling), and third party manuals just copied the lies without testing. That was easy enough to work out, and building a couple of threads to display the mouse cursor was easy. | | |
| ▲ | rbanffy 17 hours ago | parent [-] | | This sounds amazing. How did you read data from the DACs? | | |
| ▲ | tengwar2 15 hours ago | parent [-] | | Unfortunately I don't remember. This was back in the late 80's, so getting on for 40 years back, and while I do have the source code, it's on 5¼" floppy. I just checked eBay, but the only USB floppy drives seem to be in the new-fangled 3½" size. I do remember that the clock that I made was on an ISA card, and presumably so were the DACs. I don't remember any difficulty in reading from them. It may be significant that I was only reading. I think I'm going to see if I can find a service which will read the disk - it would be nice to have the code, though I remember there was a lot of stuff ♯defined out where I would have used SCCS once I had it available - hence it was a bit messy. One little vexation was that although I had a vast 64MB hard disk, and a 1GB (bites tip of little finger) optical WORM drive, I had to reboot in to MS/DOS to use the WORM drive (no OS/2 drivers) and because one of the operating systems couldn't handle more than 32MB disk size, I had to partition the hard disk. |
|
|
| |
| ▲ | ForOldHack 3 days ago | parent | prev [-] | | CodeView? You *must" have been there. | | |
| ▲ | tengwar2 3 days ago | parent [-] | | Coming from a background of programming bank-switched Z80 code for memory-mapped displays with an 8080 assembler, 80386 code with a full-screen debugger was a dream. |
|
| |
| ▲ | ForOldHack 3 days ago | parent | prev [-] | | Ahem the minute I got my 286 ( free ) home, I added Mode con lines=50 to my Dos 3.3/Tp 3.02+8087 disk, everything worked perfectly until you actually tried to do some text addressing, but I was able to pass physics 1 and 2 and Pascal and the program design and styles class with As the machine served me well. Now if I had the $400 for the extra 4mb of ram, it would have run os/2 2.1 in text mode... Or not. Oh the screen would go to snow often, and sidekick would bring it right back. How well did OS/2 handle the text modes for VGA? | | |
| ▲ | JdeBP 3 days ago | parent [-] | | Very well, because OS/2 1.x introduced, for the first time in Microsoft's MS-DOS lineage, a fully-fledged VIO subsystem that abstracted TUI applications programming wholly away from touching the hardware. (GUI applications programming with VIO still required some low-level stuff. But TUI applications programming was entirely in terms of high-level console I/O with streams of characters and low-level console I/O with a 2-dimensional output buffer. There was no mixture of directly poking hardware and calling into the machine firmware.) I regularly ran in 50-line VGA mode with zero problems. One could session-switch between full-screen OS/2 TUI programs (that were genuinely operating the hardware in VGA text mode, not simulating it with the hardware itself being used in graphics mode as became the norm with other operating systems much later and which OS/2 itself never got around to) and the Presentation Manager desktop. I even had a handy LINES 50 command that wrapped the VIO mode change function, that I gave to the world as one of many utilities accompanying my 32-bit CMD, and which in 32-bit form was layered on top of a debugged clean room reimplementation of IBM's never-properly-shipped-outwith-the-Developers'-Toolkit 32-bit version of the VIO API. You can still download it from Hobbes, today. * https://hobbesarchive.com/?detail=/pub/os2/util/shell/32-bit... |
|
|
|
| ▲ | userbinator 3 days ago | parent | prev | next [-] |
| Look at MenuetOS and KolibriOS for a newer multitasking OS, with a GUI, that also fits on a single floppy. |
| |
|
| ▲ | whobre 3 days ago | parent | prev | next [-] |
| > The cool thing about OS/2 2.1 was that you could easily boot off of a single 1.44 Mb floppy disk, and run multitasking operations, without the need for the GUI. It was cool, but don’t forget that you could do the same thing with MP/M on an 8-bit machine in late 1979. Even Microsoft developed a similar operating system a year later, but never released it. The code name was M-DOS, or MIDAS, depending who you ask. |
|
| ▲ | compsciphd 3 days ago | parent | prev [-] |
| i mean, you could boot linux and X off a single 1.44MB circa 2001 or so, with a number of drivers for common network adapter cards built in. |
