Slashdot Mirror

Even on OSes that still support the NT POSIX subsystem (NT-based pre-Win8.1 / pre-Server2012R2), it would take a *lot* of work to get Ubuntu binaries running unmodified. One attempt (since discontinued): http://cowlark.com/lbw/

Part of the problem is that the POSIX subsystem is kind of minimal. It doesn't implement a lot of the stuff the Linux has done on top of POSIX, like new system calls, IOCTLs, etc. Another part is that a fair amount of userspace translation is needed to make things like Windows UIDs comprehensible to Linux programs, which tend to assume things like "root is uid 0" (not true on Windows).

With that said, I'd really like to see the POSIX subsystem come back. When it worked, it was faster and better-integrated than Cygwin, and also supported stuff that Cygwin couldn't do (like setuid). It wasn't binary-compatible with Linux binaries (without something like LBW), but it was source-compatible with many of them (if they didn't assume Linux-specific extensions were present) and had a working build toolchain. I was running OpenSSH server natively on Windows for years before this project started. I was using bash as my default shell, even for running Win32 programs. When I needed to run a *nix program I'd pull a package, or build from source if the package didn't exist, rather than switching OSes or even using a VM.

Yep. There was actually a reverse-Wine project called Linux Binaries on Windows that basically strapped an ELF program loader to the POSIX subsystem. It never really got anywhere - partially because it was one person's hobby project, not a major long-running effort like Wine, and partially because a lot fewer people cared - but it was a cool idea. In theory, the same thing could be done with Cygwin, but it would be (even) less performant.

You misspelled Go.

You mean Brand X?

The Videocore IV on the Raspberry Pi (which totally kicks arse, BTW, it's a beautiful, beautiful processor. Did you know it's dual core?) currently doesn't have an open source compiler that's any good[*] which I'm aware of. I have tried porting gcc, and got a reasonable way into it, but ground to a halt because gcc. I know another guy who's similarly about half-way through an LLVM port. And Volker Barthelmann's excellent vbcc compiler has a VC4 prototype which makes superb code, but that's not open source at all.

Without a compiler, obviously the source isn't much good, although the VC4-specific code is really interesting to look through.

In addition, having done a really brief scan of the docs they've released, this isn't what the article's implying: what we've got here looks like the architecture manual for the QPU and the 3D engine. The QPU is the shader engine. Don't get me wrong, this is awesome, and will allow people to do stuff like compile their own shaders and do an OpenCL port, but I haven't seen any documentation relating to the VideoCore IV processor. The binary blob everyone complains about runs on that.

It does looks like the source dump contains a huge pile of stuff for the VC4, so maybe they're going to release more later. But even incomplete, this is a great step forward, and much kudos to Broadcom for doing this.

[*] I have done a really crap port of the Amsterdam Compiler Kit compiler for the VC4. It generates terrible, terrible code, but I have got stuff running on the Raspberry Pi bare metal. It's all rather ground to a halt because there's still a lot of stuff to figure out in the boot process, but interested parties may wish to visit http://cowlark.com/piface.

There is one already. It's called RISCOS. Sure, it needs some work (like pre-emptive multitasking and SMP, okay a *lot* of work), but it's small (the OS uses 6Mb of RAM) and it's very fast. And there's already a reasonable amount of software available for it, plus a working GCC implementation, so more can be ported.

RISC OS needs throwing away. I'm sorry, but it does. It was good at the time but these days we know so much more about writing operating systems that you simply cannot get to a real OS from there.

Examples? Memory is protected except when it's not, giving you the worst of both worlds. No threads. No preemption. User code runs in supervisor mode (and supervisor mode code on ARM isn't guaranteed to be portable). The GUI is great --- if you have a mouse; it can't be driven from the keyboard, at all. There is a single byte of public workspace at 0x00000108 which means that the bottom page of memory has to be mapped. Yes, this means that null pointer dereferences don't trap! There are about fifteen different APIs for doing anything, with slightly different semantics, some of which pass flags in the top eight bits of addresses. There are roughly five different system heaps, none of which overlap, all of which suffer from fragmentation.

The real jewel of the crown, though, the point at which I went from being a fan to wanting to kill it with fire, was when I discovered the code in the system memory allocator which looks up through the caller's stack trying to figure out whether it's being called reentrantly. If it is, it allocates the memory from a special small heap. Why? So that it could do memory allocations from inside interrupt handlers.

(Just to show my credentials: I discovered all this while working on a RISC OS kernel reimplementation.)

That said, if you want a 1980s grade utterly non-Posix OS, RISC OS is a good one, and if you have a Raspberry Pi do check out the bootable RISC OS image. It's interesting and works well.

But Haiku is a real, modern operating system, and RISC OS isn't.

Google announced their initiative to save Algol 68 a couple years ago: they revised it a little and called it Go, in hopes that it would thereby become the Next Big Thing in software development.

I wrote some code for it: see here (including a Linux86 execution environment, that would allow you to directly run Linux86 binaries from GEOS, that I was really rather proud of).

I can sum up the coding experience with the phrase: THE HORROR, THE HORROR.

In order to write code for GEOS you needed a monster, badly written and badly documented SDK and a copy of Borland C. The actual code you wrote was in a C superset called GOC, which was compiled via a buggy preprocessor into incredibly cryptic C, which was then compiled with Borland and linked with a custom linker. Alternatively, if C wasn't your thing, there was an object-oriented dialect of 8086 assembler available. The OO system was bizarre, and allowed for classes to have unspecified superclasses, where the superclass was determined at run time: the system used this to great effect in the UI, where the app author's generic UI was turned into a specific UI implementation for the device. The C bindings were full of bugs, too, including function calls which didn't save all the registers properly...

The actual architecture exploited the hell out of the 8086 segmentation architecture. Memory was organised as a set of relocatable blocks which were referred to by handles (which, under the hood, were usually segment descriptors). To dereference the memory, you had to lock the block, do your manipulation, then mark the block as dirty if you had changed it, and unlock it. The lock/unlock procedure allowed the system to ensure that the block was in memory, by paging it in if necessary, either from EMS RAM or disk. It was incredibly, utterly, un-Posix, and a complete pain to do anything in. The learning curve was insane.

Where GEOS really did well was the application stack, which was subtle and elegant. There was a mechanism to allow you to use a file as a heap backing store (using a very similar but annoyingly different API to the block API described above, but that's not really important). The system automagically loaded and saved data from the file as you locked and unlocked blocks. There were standard components for everything up to and including a complete bitmap paint package, a vector drawing package, and a word processor --- and these all used these file heaps as storage. And, of course, you could have multiple components in the same file. OLE! But done right.

By today's standards, of course, it's all a huge pile of incomprehensible, unmaintainable cruft, all inextricably linked to 16-bit 8086 code. It wasn't just utter mismarketing that killed GEOS: it was the inexorable march of time. It was simply unable to adapt to the 32-bit world. All the clever tricks they did to get decent performance out of an 8086 were liabilities on more modern hardware.

That said, towards the end, when Geoworks was in its death spiral, they did produce two different attempts to rewrite GEOS for 32-bit RISC processors: GEOS-SE and GEOS-SC. I know absolutely nothing about these other than on the wikipedia page, and if anyone has any info, I'd be fascinated to hear about it.

No, there wasn't much interest in putting lipstick on Algol-68.

A few years back I wrote an experimental RISC OS kernel workalike (obligatory link). In the process I found myself delving way too deeply into the core of how RISC OS worked and it's really not pretty. It's got such misfeatures as: a memory allocator that allows you to allocate small blocks of memory from inside interrupt handlers --- it does this by tracing the stack to try and figure out whether it's been called reentrantly; hardware-specific hacks built into what should be generic operating system modules (FileSwitch runs programs by fiddling with the supervisor-mode registers); no real device driver model; about half a microkernel to address the fact that there's no real driver model; global variables everywhere (pretty much everything expects to read a byte at 0x00000108 in order to test interrupt status); APIs which pass flag bits in the upper two bits of addresses; and hysterical raisins everywhere, such as having multiple concurrent system heaps. Plus of course, the whole thing is an unreadable mess of uncommented ARM machine code.

That said, it does all work, and some dedicated lunatics have RISC OS running on the BeagleBoard, so a Raspberry Pi port shouldn't be too hard. (Bear in mind that RISC OS is not open source, though; it's got a look-but-don't-touch shared source license.)

What most people think of when they talk about RISC OS is the GUI, which is a work of genius, although now very dated. (There's no keyboard accessibility, for example. Without a mouse you don't use it. This is something Microsoft got right from the very first, and the early versions of Windows were a joy to use with the keyboard.) I wish that modern systems were half as consistent and elegant as the RISC OS GUI. There have been a few attempts to recreate it with modern systems --- ROX Desktop, for example --- but they never got anywhere, alas...

Take a look at Go vs. Brand X.

Yes. As far as we currently know, human beings are complicated. (Look at it this way: you think the x86 is a crufty POS? It's a piker; we're a product of millions of years of backwards compatibility....) Doctors have to know a lot of stuff to fix us.... we're inherently complicated. However, I respectfully question how much of the complexity of C++ is actually needed. Now we look back at all the perverse "access methods" of OS/360 and its descendants and shake our heads in astonishment/disgust/etc., and I'm hoping that before long we can do the same with C++.

I can't say I agree with Pike about Go, though; I rather like the comparison of Brand X with Go, where Brand X turns out to be Algol 68. http://www.cowlark.com/2009-11-15-go/ for those interested.

At the time Acorn simply used ARM to compete with Intel chips, in 1995 when the StrongARM Risc PC came out it was 233MHz, where as the latest Intel Pentium was 200Mhz or so.

Actually...

The ARM largely predates the Intel hegemony. Acorn designed it in about 1984 as a successor to the 6502 for the simple reason that they couldn't find any other processor that was fast enough to compete with the 6502! State of the art for 16 or 32 bit processors then were chips like the 68000, which had lousy interrupt performance.

The first actual ARM computer was the Archimedes, which shipped in 1987. (Prior to that it had existed only as a second processor addon for the 6502-based BBC Micro.) It used a 16MHz ARM2. At the time the only Intel 32-bit processor was the iAPX; the 286 ruled the desktop market. The 386 would come out in 1988.

As you say, the RISC PC came out in the mid-90s with a StrongARM, but by then Intel was working on the early Pentiums, and had pretty much won the desktop market.

The fastest ARM processors today are only 806mhz...

I have a SheevaPlug running at 1.2GHz; actual speed for integer stuff appears to roughly equivalent to a 500MHz Pentium. (Benchmarks here.)

I'm just here hoping somebody ports Risc OS Open to x86, Apple managed it after all.

Impossible, alas. RISC OS is a huge pile of undocumented hand-written ARM machine code. You'd need to rewrite it from scratch, from the ground up, to change architecture. Even just cleaning up the worst bugs (friends don't let friends allocate memory inside interrupt handlers) looks to be infeasible.

OTOH if you want bug-for-bug compatibility, someone has it working on the BeagleBoard...

Last year I put together a basic kernel reimplementation in portable C (as much as possible); interested parties may want to check it out. It was a pretty unpleasant job. While RISC OS looks elegant on the surface, inside it's a nasty maze of inconsistent APIs, duplicated APIs, APIs that require certain (unfriendly) implementations, APIs that should have been deprecated and haven't been, APIs that don't exist and should to avoid having to read the kernel private workspace, and most terrible of all, APIs that expose kernel implementation details. And, just to add insult to injury, most of RISC OS is written in hard-to-maintain machine code. (And the APIs are very unfriendly to C.)

Not to mention the fact that RISC OS is missing certain bits of functionality that everyone nowadays takes for granted: threads, preemptive multitasking, memory protection between processes, a GUI that can be driven from the keyboard...

Given how much of an overhaul it would need to be meet modern standards of functionality, it'd probably be easier just to start again from scratch with a proper OS design. I find myself rather intrigued by Prex, for example, which is a minimalist embedded operating system with hypervisor-like functionality and a Unixish system call interface. And, unlike RISC OS, it's BSD licensed.

You could; but why would you?

Clustering is, except in wildly unusual cases, something you do out of necessity, because your problem is too large to run on a single computer and you don't have enough money for one of the Real Serious Supercomputers. Looking at some benchmarks suggests that, for integer operations, this thing comes in about as fast as a 1GHz Athlon(it has no FPU, so don't even bother with floats). That is not at all bad for 5-10 watts; but it isn't even close to "fast" by the standards of problems that would require cluster computers. A single or dual socket 1U, loaded with dual or quad core processors, would absolutely murder something like this in terms of power. It would use substantially more energy; but its performance per watt might actually be fairly competitive, particularly once you consider the extra switiching capacity that would be needed for running many smaller computers, instead of fewer larger ones.

Is that, some old assembly hackers ought to be able to whip up a fairly tiny basic interpreter. It should be fun in a way and still easier than in the old days of 6502.

A while back I wrote, more or less for a laugh, most of a Basic interpreter for the Infocom Z-Machine. It was seriously unfun, and I never finished it. And I was doing it in Inform, a relatively high-level language, too... the problem with Basic is that the syntax is friggin' bizarre, with all kinds of ghastly special cases and edge conditions. It's designed to be parsed as its interpreted, which means that all the various tokens change behaviour subtly depending on the statement they're embedded in. Consider ; vs , in INPUT and PRINT, for example, and once you've done that, think about ; vs , in INPUT# and PRINT#! And then you get on to the type rules... *shudder*

These days we're used to languages that are for more regular and easier to parse. Even C with its grammar from hell is at least regular. Even frigging Intercal has a more sensible grammar.

...now, there's an idea; an rommable Intercal interpreter for the C64. Finally, the right language for the machine!

Here's an excellent picture of some orbs I took in a cave in Greece. What it actually is? Falling drops of water from the cave ceiling lit up by the flash.

Somewhere --- unfortunately, I seem to have lost it --- I also have a photo with a ghost on it. What it actually is? A strand of my own hair straying in front of the camera lens and being illuminated by the flash. It forms a vague bright blur overlayed over the image that could quite possibly be interpreted as a human figure. I must try and duplicate it intentionally some time.

Oh, yes, and for good measure, here's a picture of a UFO I took once. (Actually a flaw in the film. But an impressive one, nevertheless.)

Here's an excellent picture of some orbs I took in a cave in Greece. What it actually is? Falling drops of water from the cave ceiling lit up by the flash.

Somewhere --- unfortunately, I seem to have lost it --- I also have a photo with a ghost on it. What it actually is? A strand of my own hair straying in front of the camera lens and being illuminated by the flash. It forms a vague bright blur overlayed over the image that could quite possibly be interpreted as a human figure. I must try and duplicate it intentionally some time.

Oh, yes, and for good measure, here's a picture of a UFO I took once. (Actually a flaw in the film. But an impressive one, nevertheless.)

I have an NC200; it's fabulous. Amazing keyboard, decent screen (80x16 characters), ten-hour battery life, instant on... the word processor is a bit poor, since it can only cope with 38kB files, but I can live with that. They would appear to have solved the stability issues; it's never crashed on me.

It's also a great hacking machine. It's pretty much all documented using standard components. The built-in BBC Basic has a built-in assembler... someone's done a CP/M port, which will let you run standard software such as Wordstar.

I keep meaning some day to do a proper review of this machine, from a modern perspective; we could learn a lot.

(BTW, I have some software that will let you read the files off an NC-formatted SRAM card.)

I didn't know about that; useful, although not quite what I'm looking for. Ta.

(The thing I object to here is that it requires the HTML content to have detailed knowledge of the mechanism of the markup, which is evil --- there's no need for the content to have to state that that particular div is a foo and a bar. It should just be able to state that it's a bar. The relationship to foo should be in the style sheet.)

Big enough to fit what string? A container can fit any string with a proper overflow property.

Big enough to fit a string without overflowing, of course.

Take that hoary old example, the columned layout. On my website I have a columned layout made up of tables. I want the left-hand column to be as small as possible without wrapping the 'cowlark.com' logo in the top-left corner, and the right-hand column to occupy everything else.

I cannot find a way of doing this with CVS. The problem is working out how wide to make the left-hand column. With tables, the logo does not contain any spaces, and so the table layout algorithm will try quite hard not to wrap it; try resizing the font and you see it all still works (pretty much). With CSS, I have to hard-code the logo's width, and I can't tell what that is, because it depends on the fonts being used.

I have only recently discovered display:table-row and friends, and I could probably use those instead, but it's still basically tables. There should be a better way.

CSS has lots of limitations (some of which will be addressed in V3, some of which aren't)

<plaintively> Can we have decent support for CSS2, please? Leaving aside the aberration that is IE's attempt at CSS implementation, Gecko doesn't even do counters yet...

It had it's own OO system that didn't match any programming language out there, so it had its own called GOC. This was implemented as a nasty preprocessor that spat out C, which you compiled with Borland C++ and linked using Geoworks' own buggy linker.

While the pure C API was pretty nice, in order to actually do anything you needed to use GOC objects, and the syntax was bizarre. I won't go into any details here, but all my old source code is available off the 'net.

Once you got past the weirdness, it was amazingly rich, however. Object oriented, fully multithreaded and preempted, bitmap and vector graphics including scaled, rotatable vector fonts, virtual memory (yes, even on the 8086!) But it was just too much effort to do.

My GEOS swan song was a Unix emulation system. It allowed you to use Minix-style split I/D executables in a Unix syscall interface environment inside a virtual terminal. It was amazingly powerful, worked well, and would have allowed you to actually develop for GEOS inside GEOS, once I'd actually finished it.

No-one was interested.

The only problem is that the monitor needs a special adaptor card that's ISA only. My IS department is having trouble finding me a new computer with an ISA slot... eventually I'm going to have to give it up, and I shall be extremely sad.

Not true. Grim and EMI are both written in LUA, not SCUMM.