If this worked then CoHost supports JPEG2000 and this is my contribution (That you almost certainly can't see) to the file format discourse.

Thank you for your consideration of the wavelet future.

I thought it didn't, but upon further inspection, the image IS there, just no browser can show it!

Welcome to the only JPEG2000 image ever to be uploaded to a modern social media site.

This is a place of honour.

Great things are buried here in a div.

Why does Safari support JPEG2000? Why is it's implementation ENTIRELY BROKEN.

We may never know. But please view this chost in Safari kthx.

Behold for in this post lies my greatest Co-Host achievement. Within lies the grave of JPEG2000 as a format you could freely upload to social media. All others do not accept the format, nor does cohost anymore.

This is the last social media post to ever hold JPEG2000, so this is a gravesite, a memorial to a JPEG2000 future we never got to have.

Look upon this place and tremble, ye who try to replace an entrenched standard with only a slight improvement.

I noticed that haikuwebkit pulls in a jpeg2000 library, so wanted to see if it'd show me the red horrors too. It did not, but it does show a blank image of the correct dimensions, so some level of jpeg2000 interpretation must be happening.

If I try opening the image in a new tab, WebPositive downloads it like if it were an unknown file format, and attempts to open the downloaded file crash the Haiku image viewer.

EDIT: Apparently the file was cursed enough that opening Tracker to a folder containing it would crash. Had to rm relax.jp2 from Terminal to get my system fully exorcised.

I am someone who prefers to use simple rich text editors such as WordPad on Windows or TextEdit on OS X when taking notes on my computer. As such, Microsoft's deprecation and planned removal of already-installed copies of WordPad has left me somewhat uneasy, especially as there are no plans for a replacement¹. All hope is not lost for the future of familiar rich text editors on Windows 11, however:

1. Apple used to distribute the TextEdit.app sources with a FOSS license
2. A fork of the old FOSS version still exists as part of the GNUStep project
3. GNUStep has a Windows port

And that's the story of how I ended up running Apple's rich text editor on Windows 11

¹ You are expected to either lose the text formatting and use Notepad, or go all the way to Word.

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)