looks like InterWebPPC's javascript engine is too limited to log in to cohost. not too surprising, considering how even stuff like recent Miniflux versions' javascript fails to parse, but since twitter works I was hoping cohost might too

if y'all know any way I could log in on a G4 iMac running 10.4 (or 10.5 for that matter), please let me know

still cannot log in, so I injected the cookie from my modern browser, to get into a logged-in state. that allows viewing posts and entering the post composer, but while the body text can be entered, the "post now" button does nothing

Using my modifications to cohost.py, I can finally send a chost from my iMac G4

looks like InterWebPPC's javascript engine is too limited to log in to cohost. not too surprising, considering how even stuff like recent Miniflux versions' javascript fails to parse, but since twitter works I was hoping cohost might too

if y'all know any way I could log in on a G4 iMac running 10.4 (or 10.5 for that matter), please let me know

still cannot log in, so I injected the cookie from my modern browser, to get into a logged-in state. that allows viewing posts and entering the post composer, but while the body text can be entered, the "post now" button does nothing

yesterday someone asked me if I could resolve the "eternal question" of whether Windows (pre-NT) was "just a shell for DOS." my answer is an unequivocal no, since this assertion never existed in good faith; it's on par with "fix or repair daily :)))))))))", it's just a snarky thing that some jerkwad on usenet came up with solely to start fights. still, before I answered, I did give it a few minutes thought to decide why i was sure of this

"shell", definitionally, is an interface for an existing operating system. Microsoft's own DOS Shell, for instance, does nothing more than streamline access to existing DOS system calls, and launch native DOS applications. X-Tree Gold also did little more than provide interfaces to "move", "attrib", "rename" and so on. even /bin/bash, which has been used to write entire sophisticated applications, is little more than a program launcher with dipping mustards.

this never really applied to Windows, and with every year it existed, it applied less. the very first version of the OS, in 1985, provided an extremely rich set of APIs. some depended on underlying DOS system calls, sure, but that really doesn't mean anything.

"operating system", in 1981, meant a very different thing than it does now. DOS was nothing but a handful of system calls. it had no HAL; it didn't sit in between processes and hardware, unless they opted to do so. you could ask DOS to access a hard drive or a graphics card for you - or you could just blow past it and access the hardware yourself. DOS couldn't get in your way, because when your program was running, DOS wasn't.

literally, as soon as you launched an app, DOS stopped executing. it remained resident in memory, but it had no agency. your program owned the CPU in its entirety, and could keep it until you powered the machine off. the only things that would cede control back to the OS were system calls or hardware interrupts, almost all of which could be ignored.

the same is true for other contemporary platforms. the early PC was closer to an 8-bit home computer than what we think of now, and the OSes that came out for the Apple II and Atari 400 were similarly thin; applications did 95% of the work themselves, and relied on the OS only for tedium like "write text to the screen, i don't really care how long it takes"

unlike what we now think of as "an OS", DOS did not manage processes, or gate access to hardware. it had no HAL. it was, for the most part, simply a library that programs could rely on - and not a very big one. if microsoft had decided to make Windows totally independent of DOS, it would have taken them a couple weeks to rewrite the handful of relevant system calls. they didn't do this because one of the primary features of windows was the ability to run legacy DOS apps. so yeah, duh, of course DOS still needed to be resident.

the amount of sophistication in the very first release of Windows, ignored and unsuccessful as it was, made DOS look like Hello World. programs running under Windows 1 did not need to know that DOS existed. i think, at the point where something literally has its own executable format, you have to admit that it's an operating system.

It's fundamentally, like Gravis said, a question of What An Operating System Is. How do you define it?

The very oldest computers had no operating system. Not only that, they didn't even have anything we'd recognize as a bootloader. All they did was munch instructions that were physically wired in, via plugboard, switch panel or both. Stored program computers were the next innovation, because plugboards or just directly slam-dunking machine code into memory by switches doesn't really scale to programs that are very long at all. Instead, you wrote your machine code on punchcards, the punchcard reader - a frontend to the actual computer - slurped the machine code on the punchcards into memory and then the computer ran it. Still no OS or anything, it's all just running on bare metal.

People started to realize two things at this point:

1. Computer programs often do a lot of the same things as other programs. You don't have to reinvent the wheel every time.
2. If your computer has any mechanism to do this at all, keeping that shared functionality in memory and only bringing in new programs allows you to write smaller programs.

And so people started writing shared libraries of functionality, and then the operators started keeping those libraries resident. Eventually the libraries started developing their own functionality, for debugging or hardware management and soon the libraries evolved into what were called "monitors", which could manage software on their own. These were the first operating systems as we know them!

The thing to understand here is that these were mainframe programs but were still single-tasking, single-user. The mainframe operators still ran single programs (now loaded via the monitor!) in batch mode and then provided the results to the programmer.

The real big innovation next was timesharing, allowing multiple batches and multiple interactive programs to run at, from the user's perspective, the same time! This is where modern operating systems started; they supported memory management, and multiple process management. They had filesystem drivers and network subsystems. Some of these systems we use (their direct descendants) daily, most especially Unix.

So! By the late 60s/early 70s, this is what an OS really is, a full scale modern OS. You still had single-tasking systems like RT-11 that were mostly employed for realtime operations like industrial control; they didn't have process control for multitasking but they still had many of the other features including hardware abstraction, memory management, filesystem and network and other device support and the like.

Mid-70s, the first microcomputers appeared. The Altair 8800, the KIM-1 and others all emerged in the 74 to 76 period. These were full-fledged computers, not just calculators or such, but were vastly less powerful than even the smallest minicomputers that could run small OSes like RT-11, let alone the big CDC beasts or DEC's 36-bit monsters. They went through a similar evolution of operating systems, with the earliest being simple ROM-based or switch-loaded monitors, with relatively more powerful embedded BASIC environments or simple control systems built on the same architectural lines, but vastly simplified, as already simple single-tasking RTOSes like RT-11, coming along later.

The most popular of these control environments, which DOS was somewhat of a copy of, was CP/M. CP/M provided some of the functionality that would be expected of a minicomputer OS; it had filesystem drivers, and some minimal hardware abstraction, so that CP/M software (as long as the CPU was the same or compatible) written correctly could run on different computers without having to be rewritten.

DOS was different on that respect, in that it was never intended to be portable. The original 86-DOS written by Seattle Computer Products was just a quick and dirty system to run development on for an 8086 development system. When Microsoft acquired it to sell to IBM, they wrote some utilities to get a fully functional computer out of it, with some APIs to support, but that's it. The result is this:

Almost every DOS program of any complexity had to bypass it and talk to the hardware directly.

This was not a hard thing to do! DOS provided no (and so enforced no) memory management, hardware layer, process control, and so on. It had some facilities to allow well-behaved software to coexist and hooks to allow drivers to extend the OS functionality, but that was it. Quite a bit of software, especially games but also a fair number of commercial/business packages, interacted with DOS very little or not at all; some things we remember as DOS programs actually weren't but booted directly from floppies without DOS ever being started.

The upshot of this is that a lot of programs for DOS functioned, to some extent or another, as operating systems in their own right. Video card manufacturers famously provided their own graphics drivers, not for DOS, but for AutoCAD. In general, the only thing these programs used DOS for was the filesystem access, treating DOS itself as basically just a disk driver. 386 era programs that used DOS extenders (think Doom) had the DOS extender take over the system entirely, and the DOS extenders would supply basically everything a traditional OS would: Memory management, process control, sometimes a hardware abstraction layer with its own small set of drivers, only ever thunking back to DOS for (you guessed it) filesystem access. DOS itself just kind of sat and vegetated in a corner, not even running in any meaningful way unless the DOS extender invoked it.

So! Not only was Windows basically a full operating system from word go, so were a lot of other programs. Some of them were even OS-shaped and provided their own operating environment distinct from the DOS command line, like Desqview (a true multitasking, windowing system for DOS programs that was probably Windows' biggest competitor in the early days). Others were programs like AutoCAD or Doom that shoved DOS completely out of the way and took over the whole computer.

Even for the era, DOS was wimpy. "A shell on top of DOS" is verbal sleight-of-hand because DOS basically didn't do shit.

it's almost like "disk operating system" was primarily software for accessing disks

I have spent more time than is probably healthy in the guts of MS-DOS 1.25 in my (atm dormant) project to create a fully open-source MS-DOS 1.x for PC compatibles. you may be wondering why this project is necessary – Microsoft released the source code to MS-DOS 1.25; can't I just compile that? The answer is that I can, and I do¹, but there are two reasons the finished artifact using only Microsoft sources will not run on an IBM PC compatible: it has no bootloader, and its HAL is for the wrong platform

like CP/M before it, DOS is divided into three parts:

1. command interpreter (COMMAND.COM), runs on top of DOS as almost-normal user program
2. DOS kernel (MSDOS.SYS / IBMDOS.COM), requires an 8086 compatible CPU but is otherwise hardware independent²
3. hardware abstraction layer (IO.SYS / IBMBIO.COM), hardware-specific and meant to be written by the OEM

the DOS hardware abstraction layer provides 14 HAL calls that all hardware access in the DOS kernel goes through. on an IBM PC compatible system, these further invoke BIOS calls, but on the original Seattle Computer Products system it talks to the hardware directly. I am unsure why IBM decided to make their system two-layered like this

in theory, this should allows similar level of cross-computer portability for DOS software as for CP/M. however, in practice the CP/M-style HAL was too limited³ and DOS machines all ended up being more or less IBM-compatible in the west, so software took it upon themselves to call BIOS or drive the hardware directly

TL;DR: there is a HAL, but almost nothing outside of the DOS kernel itself relies on it 100%

¹ at the moment I have made no changes to the Microsoft sources in ordos other than to set it to build an IBM-style² DOS kernel

² there were at least two different places the HAL could be loaded at, and the DOS kernel must be built with the correct one for your platform. the ones I'm aware are Microsoft style (HAL call table is at 0x400) and IBM style (HAL call table is at 0x600). I use the IBM style, since PC BIOSes already reserve the locations 0x400–0x4FF for their internal use. other than that, you can use the same DOS kernel binary in different hardware-incompatible DOS systems

³ the DOS 1.25 HAL provides a linear-block addressing view of the disk, emulates a teletype i/o, allows talking to parallel and serial ports with one hardcoded configuration, and keeps track of time and date. there is no support for full-screen text UIs, changing the speed of the serial port, or graphics, and the HAL is not designed in a way that can be extended by loadable device drivers. even if it had been though, it would still have been too slow for most serious software due to just how weak the 8086 and 8088 were

I don't really have nostalgia for windows xp the way a lot of people do (I ran windows 2000 until late 00s, then went to linux) but I have recently acquired an old windows xp laptop (without the original HDD) so yesterday I decided to install xp to finally check it out

couple amusing/interesting things from during the install process:

• when I selected support for "complex scripts" (not enabled out of the box on the finnish install) it warned me that supporting arabic, armenian, georgian, hebrew, hindi, thai, and vietnamese would take at least 10 megabytes (second picture)
• in the time zone selector it first of all uses GMT instead of UTC, and secondly kyiv is rendered as "Kiev" instead of the normal finnish "Kiova" (third picture)

my home networking just uses normal ethernet, so getting an internet connection is not very hard. however, tls 1.2 with something better than aes-cbc is nowadays required for connecting even to wikipedia, so the built-in internet explorer 6 is not very useful in modern day internet (google still works tho!)

I first tried to see if I could bootstrap tls 1.2 capable browser using only windows xp. this is possible on os x 10.4 – macintosh garden allows non-https requests if you are on an old mac, and they host the most up to date browser for the system. you can even get all the way to latest openssl staying 100% on os x 10.4

as best as I can tell, it is not possible on windows. everything able to do tls 1.2 is behind tls 1.2 (and in several cases, behind github, which is completely unusable even on the tls 1.2 enabled browsers that do run on these old systems). so I just copied firefox 52.9esr (last version that supports windows xp) installer over on an USB stick, and ran that

except it turns out, that requires SSE2 (second picture). and my laptop has athlon xp-m, which only does up to the original SSE. and the latest version of firefox that did not requires SSE2 was 3.6, far too old to have tls 1.2. I then set out to look for a browser without an SSE2 requirement

my first lead was chrome, which added SSE2 requirement in version 35, and tls 1.2 support in 29 (with chapoly in 33). I quickly determined the version I wanted was 34.0.1847.137 so now it was only the matter of finding that. that turned out to be harder than expected

google does not host old builds due to security reasons (fair enough), so if you need an old build for development reasons you are supposed to find the matching chromium CI run and get that. however, using the linked tool for finding the base position (which is deprecated, because of course it is) does not find a base position for 34.0.1847.137. after some time a friend came to the conclusion that chromium no longer hosts CI builds that old

at this point another friend suggested k-meleon, the on-off updated windows-native gecko (now goanna, pale moon's engine, after mozilla killed off support for gecko in third party applications) browser. this did in fact work, as you can see in the latter two images, though goanna is clearly showing the lack of developers compared to gecko and it is not able to for example view individual toots' pages on mastodon

(said friend also suggested the mypal web browser, which is based on pale moon and targeted specifically for windows xp. it however died on an illegal instruction, which suggests to me that it too requires SSE2)