Want to read Slashdot from your mobile device? Point it at m.slashdot.org and keep reading!

 


Forgot your password?
Close
typodupeerror
×
Operating Systems Software

Behind Menuet, an OS Written Entirely In Assembly 419

Posted by Soulskill from the keep-it-simple dept.
angry tapir writes "MenuetOS is an operating system written entirely in assembly language. As a result it's extremely quick and compact (it can even fit on a floppy disk, despite having a GUI). It can run Quake. Two of the developers behind MenuetOS took time out to talk about what inspired them to undertake the daunting task of writing the operating system, the current state of Menuet and future plans for it."
This discussion has been archived. No new comments can be posted.

Behind Menuet, an OS Written Entirely In Assembly More

Behind Menuet, an OS Written Entirely In Assembly

Comments Filter:

  • From the license... (Score:5, Funny)

    by damburger ( 981828 ) on Wednesday August 19, 2009 @08:37AM (#29117927)

    3) Redistribution, reverse engineering, disassembly or decompilation prohibited without permission from the copyright holders.

    Are you sure they wrote the entire thing in assembly language?

    • Re:From the license... (Score:4, Insightful)

      by buddhaunderthetree ( 318870 ) on Wednesday August 19, 2009 @08:44AM (#29118003)

      Yeah I wonder about why they chose that particular license. I mean it's not a commericially viable product, and if it's meant to spur research and development then why not chose some sort of free software license.

      • Re: (Score:3, Insightful)

        by damburger ( 981828 )
        What puzzles me (apart from the amusing bit about decompiling something that was never compiled) is the prohibition on disassembly. Given the pretty much trivial mapping between assembly mnemonics and the actual binary files they distribute, it seems a silly thing to prohibit.

        • Re: (Score:3, Insightful)

          by pentalive ( 449155 )
          Why do you think "Task is easy to do" has anything to do with "The author and rights holder does not wish it done" ?

          Just because a thing is easy to do does not mean one automatically has some right to do it.

          • Re:From the license... (Score:4, Interesting)

            by damburger ( 981828 ) on Wednesday August 19, 2009 @08:59AM (#29118219)
            Because it would be like banning you from remembering (not even speaking) dialogue you remember from a movie. Its inane.

        • Re: (Score:3, Informative)

          by tlhIngan ( 30335 )

          What puzzles me (apart from the amusing bit about decompiling something that was never compiled) is the prohibition on disassembly. Given the pretty much trivial mapping between assembly mnemonics and the actual binary files they distribute, it seems a silly thing to prohibit.

          You lose a lot on a disassembly though.

          Comments for one, and non-public symbols for another (including stuff like variable names, structure names and composition, etc), plus any oddball globals referenced through a base pointer. You lo

  • But (Score:4, Funny)

    by rodrigoandrade ( 713371 ) on Wednesday August 19, 2009 @08:37AM (#29117933)
    Does it run Linux?

    Oh wait...

  • What! (Score:2, Funny)

    by jozmala ( 101511 )

    It seems their webserver isn't written in assembler.

  • It's not FOSS? (Score:4, Insightful)

    by Nursie ( 632944 ) on Wednesday August 19, 2009 @08:40AM (#29117963)

    It's free as in beer, AFAICT, but not open. That seems strange to me.

  • Stupid license. No thanks. (Score:5, Insightful)

    by Desler ( 1608317 ) on Wednesday August 19, 2009 @08:40AM (#29117965)

    Menuet64 Copyright (c) 2005-2009 Ville Turjanmaa

    1) Free for personal and educational use.
    2) Contact menuetos.net for commercial use.
    3) Redistribution, reverse engineering, disassembly or decompilation prohibited without permission from the copyright holders.

    Probably won't gain much steam with a license like that. Enjoy your obscurity and 3 users.

    • Re:Stupid license. No thanks. (Score:5, Insightful)

      by damburger ( 981828 ) on Wednesday August 19, 2009 @08:49AM (#29118085)
      More to the point, the prohibition on disassembly makes it impossible to independently verify their claim it was written in assembly language without violating their license, and that claim is central to the idea of this being an interesting research project.

    • Re:Stupid license. No thanks. (Score:4, Insightful)

      by geckipede ( 1261408 ) on Wednesday August 19, 2009 @09:35AM (#29118629)
      A far more serious issue in gaining popularity for this project is going to be hardware support. I've actually tried this OS, and discovered that if you cram everything into one floppy disc, there isn't much room left for a range of drivers. I'm fairly sure that this thing was designed and written to work on the developer's own computer, and practically nothing else.

    • Re:Stupid license. No thanks. (Score:5, Insightful)

      by ae1294 ( 1547521 ) on Wednesday August 19, 2009 @10:44AM (#29119555) Journal

      Probably won't gain much steam with a license like that. Enjoy your obscurity and 3 users.

      SO what?

      At least the they are doing something interesting... Maybe they will find someone who needs a really small and quick OS that is hacker-unfriendly. I'd personally love to see ATM machines running something like this instead of Win2k and XP....

      If by some oddball chance they can make some money off their hobby more power to them... Anyone who can code a OS in ASM is ok in my book and you got no room to judge them just because they are covering all their bases. I mean do you really not think some company wouldn't come and grab up all their work and laugh after spitting in these guys faces?

      • Re: (Score:3, Insightful)

        by Desler ( 1608317 )

        At least the they are doing something interesting...

        What is interesting or novel about this? There have been numerous OSes written in assembly language. That was pretty much what you did before C came along and even for quite some time after wards. Secondly, writing an OS kernel in assembly was a project that many people did while in school making this pretty mundane to be honest.

        I mean do you really not think some company wouldn't come and grab up all their work and laugh after spitting in these guys faces

        Since no company stole the work during the years while it was under the GPL, I see no reason why they would have had to worry about it enough to change the license for that reaso

  • Not the best choice of languages (Score:5, Insightful)

    by Anonymous Coward on Wednesday August 19, 2009 @08:40AM (#29117973)

    In today's multi-level cache, highly pipelined CPU environment, hand optimized assembly is not usually the best choice when compared to a good compiler. It's easier for bugs to hide, and small mistakes can cost way more than any possible optimization is going to buy you.

    • Re:Not the best choice of languages (Score:5, Funny)

      by damburger ( 981828 ) on Wednesday August 19, 2009 @08:54AM (#29118137)

      You are right of course. What they need is some kind of software tool that can automatically and quickly generate code optimized for any new hardware that comes out. Rather than code in the particular assembly language of the processor of the day they could write out their algorithms in some kind of abstract, human readable script, which the aforementioned tool would then convert to assembly language.

      Why has nobody thought to create such a useful tool for these poor chaps??

    • Re:Not the best choice of languages (Score:5, Insightful)

      by jnaujok ( 804613 ) on Wednesday August 19, 2009 @09:05AM (#29118291) Homepage Journal
      Spoken like someone who's never coded in Assembly. While I almost never touch assembly any more, there's very little fact in your statement. In assembler, everything is in front of you. There's no need to worry about what the libraries are doing, or whether the call to some function is going to cause side effects or something you didn't intend, or whether some compiler quirk is going to make your code take ten times longer to run.

      Having written in assembly on 8048, 8051, 8086 and DEC Vax boxes, I can tell you right now that debugging most of that code was a lot easier than chasing down the side effect from some array overwrite on leaked memory from a third-party library that you didn't even know was being linked into your code.

      Writing in a compiled language is easier, faster, and usually has a better set of pre-written functionality, but never, ever claim that it's going to be more optimized. Even with pipelining updates from the compilers that help the look-ahead caches on the CPU, there's very few times that hand-coded assembler isn't going to be faster.

      Go look at the assembler that some of these compilers produce. It's frightening to see the amount of overhead they cost on even simple assignment operations. I saw one compiler (Microsoft's Visual C++) that took a simple x=10; in C++ and turned it into 15 assembly language operations that, had it been coded by hand, would have been one MOV statement. The compiler turned it into conditional conversions for type, did some byte order and range checking on it (for a hard assign to a constant -- rolls eyes) and then finally did the same MOV AX, 0x0a that you would have coded by hand.

      • Re:Not the best choice of languages (Score:5, Insightful)

        by Desler ( 1608317 ) on Wednesday August 19, 2009 @09:16AM (#29118397)
        Actually his points are quite valid. It is not a good choice to write everything in assembly when the speedups you gain in most places is not worth the amount of time and effort you spend in hand-optimizing the code. And considering how many bugs I've seen in people's asm code that they didn't spot till later his second point is also true.

        Even with pipelining updates from the compilers that help the look-ahead caches on the CPU, there's very few times that hand-coded assembler isn't going to be faster.

        The GP never made that claim.

        • Re:Not the best choice of languages (Score:4, Interesting)

          by Hurricane78 ( 562437 ) <deleted&slashdot,org> on Wednesday August 19, 2009 @09:59AM (#29118923)

          Also, since when do you have to write your program/os in only one language?

          Game developers mix their code all the time. C++ for the main part/glue, assembly for the tight loops and things that need speed-ups, and a (maybe compilable) scripting language like Python or Lua for, well, scripting (bots, map events, rules, etc).

          I'd write an OS in Haskell for the main part, and assembly or C++ for the really low level or very speed-dependent stuff.

      • Assembly language doesn't scale (Score:4, Interesting)

        by Joce640k ( 829181 ) on Wednesday August 19, 2009 @09:50AM (#29118793) Homepage

        Writing large programs in assembly language is almost impossible, you have to get it perfect first time because refactoring assembler code is next-to-impossible.

        eg. Small changes in the base data structures (eg. change a data type) mean you have to go through and change every instruction which references that data, and since there's no type-checking in assembler you can easily miss some and the assembler won't tell you about it.

        With a compiled language you can change the data type and you're done.

        This argument also explains why C++ is better than C. C++ and OO methodology makes writing large programs MUCH easier than using C and procedural code. With C code you have to keep an awful lot more knowledge in your head at any give time and it's easy to forget things in C that can be done automagically in C++.

      • Re:Not the best choice of languages (Score:5, Informative)

        by adisakp ( 705706 ) on Wednesday August 19, 2009 @11:10AM (#29120007) Journal

        Writing in a compiled language is easier, faster, and usually has a better set of pre-written functionality, but never, ever claim that it's going to be more optimized. Even with pipelining updates from the compilers that help the look-ahead caches on the CPU, there's very few times that hand-coded assembler isn't going to be faster.

        As CPU's become more complex, this is less and less true. For example, even on the PS2, they created a tool called VCL [playstation2-linux.com]that preprocessed assembler for you for maximum usage of registers, unrolling, and pipelining. It generated better optimized code than 99% of of coders out there could do on their own and at a fraction of the effort to seriously fully optimize pipelined assembler -- not to mention the asm code was much more maintainable since with handrolled manually pipelined code you may have to re-optimize everything if you change a single register or just a few instructions. Also, things like the auto-unroll and auto-register-assignment a were huge time saver (it could unroll a loop NX and allocate NX registers to interleave SIMD operations to hide latencies).

        That's not to say that a really great ASM programmer wouldn't do better than VCL, but he would have to work much much harder. You'd have to track all the registers yourself, remember the pipelining rules and latencies for every single instruction, be willing to experiment with unrolling every loop and counting cycles between unrolled (with prologs/epilogs) and normal versions, know all the possible instruction swaps, synchronize the integer and vector pipelines manually, try nearly all possible instruction orders, etc. Certainly an average assembler programmer wouldn't do as well.

        • Re: (Score:3, Insightful)

          by Just Some Guy ( 3352 )

          That's not to say that a really great ASM programmer wouldn't do better than VCL, but he would have to work much much harder. You'd have to [...]

          ...start from scratch when someone rolls out a different chip design that obsoletes all your assumptions or when you learn a new optimization technique. I'd much rather write at a higher level and let new versions of the compiler handle updated architectures, and automatically adjust all my old code whenever their optimizers improve.

      • Re: (Score:3, Insightful)

        by microbee ( 682094 )

        Well I guess the compilers/CPU architecture have advanced enough that some of your old experience doesn't apply anymore.

    • Re: (Score:3, Informative)

      by Rockoon ( 1252108 )
      ..and thats why the fastest encryption libraries are written in high level languages, right?

      oh, erm.. encryption algorithms need the exact things you claim compilers are great at, yet the fastest encryption libraries are in hand-written assembler.

      The fact is that this "compilers are better than humans" meme is complete bullshit and has always been bullshit. This fact can clearly be demonstrated by looking at the change logs of those compilers. For well over a decade this meme has been out there and for

      • Re: (Score:3, Insightful)

        by Cereal Box ( 4286 )

        Assembly is best for optimizing limited sections of code where your specific domain knowledge can allow you to make optimizations the compiler wouldn't know about. It makes sense in those situations, and that's it. Writing an entire, non-trivial application (or OS in this case) is a waste of time since

        • you're going to spend far more time coding than you would in a high-level language
        • your chance of introducing bugs is far greater
        • your code loses portability

        And most importantly, for everything except the most

      • Re:Not the best choice of languages (Score:5, Insightful)

        by TheRaven64 ( 641858 ) on Wednesday August 19, 2009 @10:39AM (#29119489) Journal
        Which encryption routines are these and what architecture are they written for? The fastest encryption routines I'm aware of are written in GLSL which is not just compiled, it's compiled to bytecode then JIT-compiled by the driver when the program is loaded! The second fastest use dedicated crypto hardware, via (C) ioctl() functions calling a driver, which is written in C. Oh and:

        For well over a decade this meme has been out there and for well over a decade there has been continual performance improvements to those compilers.

        Just because version n+1 of a compiler is better than version n of a compiler doesn't mean that version n isn't better than a human. Maybe you can do cross-module function specialisation in your head, but the rest of us aren't so lucky.

  • That's just dumb. And kinda cool. (Score:5, Interesting)

    by localman57 ( 1340533 ) on Wednesday August 19, 2009 @08:41AM (#29117977)
    The article is slashdotted, so I'll post a thought without RTFA. I do embedded firmware for a living; assembly programming is part of my job. But unless you have to fit all of your software into a $.42 micro, there's no reason to write all your software in assembly. Typically, you get most of your performance gains by rewriting 5% or less of the software in assembly [Citation needed... :-)]. As for the rest, go with C or higher for maintainability and portability.

    6 months from now, a new processor revision will provide enough marginal performance to make up for not coding the other 95% in assembly.

    That said, this is a monumentally cool achievement, if academic.

    • Re:That's just dumb. And kinda cool. (Score:4, Informative)

      by cabjf ( 710106 ) on Wednesday August 19, 2009 @08:49AM (#29118081)
      I agree, the major advantages of assembly for that other 95 percent would be negated by a good C or higher compiler that will probably write more efficient and faster binaries than most programmers could using assembly.

    • The point was to write an OS in assembly, so all of your analysis is irrelevant.

      It's monumentally cool, and academic. The point wasn't to have a portable OS, and assembly can be very maintainable if structured correctly.

      If they wanted a lightweight, portable OS they would have chosen a different language.

    • Re:That's just dumb. And kinda cool. (Score:5, Interesting)

      by timeOday ( 582209 ) on Wednesday August 19, 2009 @09:02AM (#29118261)
      Interestingly, their homepage does not tout execution speed as a motivation: "Menuet has no roots within UNIX or the POSIX standards, nor is it based on any operating system. The design goal has been to remove the extra layers between different parts of an OS, which normally complicate programming and create bugs." It sounds to me more like they are fed up with all the clutter and layers of abstraction in a modern OS and want to see what happens if you start with a clean slate. Then again, without open source, the aesthetic appeal of this "clean" approach is limited.

      • Ehhh..... (Score:5, Insightful)

        by OwnedByTwoCats ( 124103 ) on Wednesday August 19, 2009 @09:17AM (#29118417)

        Ehhh. The whole effort doesn't impress me. There are/were Linux distros that fit onto a floppy. OSs were written in Assembly for years.

        If they can demonstrate that "remov[ing] the extra layers between different parts of an OS" simplifies programming and eliminates bugs, then they'll have something interesting. And they can have a flame war with the microkernel folks, who assert that separating the OS into separate parts that are independent and can be thoroughly tested simplifies programming and eliminates bugs.

        Abstractions have a purpose; they make it easier to think about things. There are no "Files" or "Folders" (or "Directories", for those of a Unix persuasion) on your hard drive; there are only a sequence of blocks. The Operating System provides the abstraction of files. Various protocols and their implementations then provide an abstraction that "Files" and "Folders" on remote machines are just like "Files" and "Folders" on the local drive.

        If abstractions make life complicated for the OS developer, but easier for the user, is it a win? It depends on whether the OS has more developers or users.

      • Interestingly, their homepage does not tout execution speed as a motivation: "Menuet has no roots within UNIX or the POSIX standards, nor is it based on any operating system. The design goal has been to remove the extra layers between different parts of an OS, which normally complicate programming and create bugs."

        Layers complicate programming and create bugs? Really? As in, "the whole modular programming thing is just a fad"? If these guys can actually honestly claim that they program better in the big ball of mud paradigm, they must be super-geniuses, and trying to collaborate would be impossible for the normal geek anyway.

        • Re: (Score:3, Insightful)

          by timeOday ( 582209 )
          Well, they said "extra layers," not all layers. Obviously, what is "extra" becomes a matter of taste. But it is true that most OS's carry a huge burden of legacy compatibility. Another problem is "feature bloat" with lots of code to support features that weren't that useful after all. (For example, the POSIX apis for networking seem awfully obtuse, mainly because they treat TCP/IP as just one of many network protocols, even though nobody uses the others any more).

          All of this is just the normal softwar

    • Re:That's just dumb. And kinda cool. (Score:5, Informative)

      by hey! ( 33014 ) on Wednesday August 19, 2009 @09:13AM (#29118353) Homepage Journal

      I agree. Every time I've ever profiled code, I've been amazed at how much time is spent in such tiny portions of the code.

      It's an interesting exercise though. I've only done a little assembler, but my thoughts were that if I did more of this I could get pretty good at it. The trick in any kind of programming is to learn to express *ideas*. I learned several different programming paradigms over the course of my career, and while I'm doing OO like everyone else these days, having tried functional programming makes me a better programmer.

      I could imagine doing non-trivial systems in assembler, but mainly if the problem domain and its solutions are very well understood. When you see that 1% of your code is taking 99% of your execution time, you *could* tighten that code and get an immediate payback, or you could try understand the problem better in order to find a more efficient algorithm. If you can improve your algorithms, that's almost always going to be a bigger win.

      We've been making essentially modern operating systems (virtual memory, process scheduling etc.) for a long time. If you just wanted to implement the textbook approaches for everything, and didn't care about architecture portability, it seems pretty feasible for a couple of guys to make a reasonably credible OS in assembler, provided they knew their OS stuff and were very good assembly programmers. Obviously the C with assembly for tight loops approach is a quicker path to a usable system, but the fact that they're assembly enthusiasts probably means they'll get more benefit out assembler where it is most useful and less benefit out of C where assembler is least useful than a sane programmer would. And it's always worthwhile to demonstrate the limits of conventional wisdom.

      SInce you work in embedded systems, I don't have to tell you that upgrading your processor in six months isn't always an option.

    • Re: (Score:3, Interesting)

      by FlyByPC ( 841016 )

      Typically, you get most of your performance gains by rewriting 5% or less of the software in assembly [Citation needed... :-)].

      I think you mean Amdahl's Law [wikipedia.org] (that speeding up or parallelizing one task will only produce a speedup limited by the relative time consumed by that task compared to the rest of the code.)

      I do think that writing good, efficient C code (for instance) will get you most of the way there -- and in that case, your argument is right. There's still something to be said for developing something like this just for art's sake, though. Why do people admire handcrafted Swiss watches, when they can get a perfectly good

    • Re: (Score:3)

      by orzetto ( 545509 )

      Typically, you get most of your performance gains by rewriting 5% or less of the software in assembly [Citation needed... :-)]

      <ref>Donald Knuth, in "Structured Programming with Goto Statements". Computing Surveys 6:4 (December 1974), p. 267: "Experience has shown [...] that most of the running time in non-IO-bound programs is concentrated in about 3% of the source text".</ref>

  • They should... (Score:5, Funny)

    by oldhack ( 1037484 ) on Wednesday August 19, 2009 @08:42AM (#29117987)
    Man, they should, like, totally port that to ARM. ;-)

  • "it can even fit on a floppy disk"... (Score:5, Funny)

    by martas ( 1439879 ) on Wednesday August 19, 2009 @08:43AM (#29117997)
    *blink*

    is that some kind of new super-awesome flexible organic flash memory?

  • Not that amazing (Score:5, Interesting)

    by jdunn14 ( 455930 ) <jdunn@iguanawork s . net> on Wednesday August 19, 2009 @08:46AM (#29118029) Homepage

    For a more impressive feat, check out the Synthesis kernel written back in 1988. Also written entirely in assembly, and as stated in the linked wikipedia entry, that OS kernel was the "mother of all self-modifying code." It actually handled things like thread scheduling by generating a custom assembly snippet to jump to the correct point in the next thread to execute.

    http://en.wikipedia.org/wiki/Self-modifying_code#Alexia_Massalin.27s_Synthesis_kernel [wikipedia.org]

    • Re:Not that amazing (Score:4, Interesting)

      by Massacrifice ( 249974 ) on Wednesday August 19, 2009 @09:02AM (#29118257)

      thread scheduling by generating a custom assembly snippet to jump to the correct point

      Wow, this thing must have been fun to debug and maintain. And also, must be a challenge to optimize current generation CPUs for, with separate data and instruction caches... No wonder it never gained traction.

      • Re:Not that amazing (Score:4, Insightful)

        by Lemming Mark ( 849014 ) on Wednesday August 19, 2009 @09:09AM (#29118331) Homepage

        Wow, this thing must have been fun to debug and maintain. And also, must be a challenge to optimize current generation CPUs for, with separate data and instruction caches... No wonder it never gained traction.

        Yeah, I read somewhere that that was the reason everybody's given up on the Synthesis techniques today. A shame, in a way, as it was a really cool system.

    • Re: (Score:3, Informative)

      by noidentity ( 188756 )
      Yes, Synthesis is very cool. Apparently file buffers were handled with on-the-fly code with the buffer pointer embedded within it, and without explicit checks, instead relying on an unmapped page just past the end and a page fault handler to refill the buffer (at least that's how I remember the author explaining it to me). I believe the author is also the one who original wrote the Superoptimizer.

  • Followup to Menuet (Score:5, Funny)

    by halfdan the black ( 638018 ) on Wednesday August 19, 2009 @08:48AM (#29118075)
    I think I might work on a sequel...
    Build a 747 with nothing but stone knives and bear skins...

    • Re: (Score:3, Funny)

      by mikael ( 484 )

      Or how about Building a 747 while in the sky [youtube.com].

  • Thanks for your great accomplishments! (Score:3, Funny)

    by Shin-LaC ( 1333529 ) on Wednesday August 19, 2009 @08:49AM (#29118079)
    Hard drive makers, you have my eternal gratitude.

  • Kolibri: a Menuet offshoot (Score:4, Informative)

    by dargndorp ( 939841 ) on Wednesday August 19, 2009 @08:57AM (#29118183)

    Since all links in the article submission seem to be slashdotted, an offshoot of Menuet OS named KolibriOS is located at http://www.kolibrios.org/?&lang=en [kolibrios.org].

  • Fast due to assembly or fast because it's minimal? (Score:5, Insightful)

    by Walter White ( 1573805 ) on Wednesday August 19, 2009 @09:00AM (#29118235)

    I have to wonder if it is small and fast because when writing in assembly it is easier to resist the urge to add features. Todays compilers are pretty good and can produce pretty tight binaries. However, you can write (and debug) a lot more code in a given time using a high level language.

  • obsolete technology (Score:5, Funny)

    by gsslay ( 807818 ) on Wednesday August 19, 2009 @09:01AM (#29118245)

    (it can even fit on a floppy disk, despite having a GUI)

    Excellent, but if we're going to measure these things in obsolete technology;

    - How many parchments would I need to copy it?
    - Could my team of monks transcribe it in its entirety before the Feast of All Hallows Eve?
    - If the Germans intercepted a morse transmissions of it, how long would it take them to crack the code and scupper our plans to retake mainland Europe?

  • networking (Score:5, Interesting)

    by james_shoemaker ( 12459 ) on Wednesday August 19, 2009 @09:15AM (#29118377)

    Too bad it doesn't have wireless networking support, it looked to be the perfect thing to make older notebook computers useful.

  • My Javascript OS (Score:4, Funny)

    by Maltheus ( 248271 ) on Wednesday August 19, 2009 @09:56AM (#29118883)

    I guess now is not the right time to announce my OS written entirely in Javascript. It can already play the Bill Gates Pie in the Face game.

  • Cool GUI. (Score:3, Funny)

    by Pedrito ( 94783 ) on Wednesday August 19, 2009 @10:44AM (#29119561)
    Wow, it's been since Windows 1.x that I've seen a GUI that looked like it was written in assembly. How retro.

  • Mac OS 6 (Score:3, Interesting)

    by 4D6963 ( 933028 ) on Wednesday August 19, 2009 @02:24PM (#29123531)

    So it's written in assembly, has a GUI and boots from a floppy? Yup, Apple did it (Mac OS was written in 68k assembly up to System 6)

    And no offense but Mac OS 6 looks like it had a more sophisticated GUI than that, colour depth aside.

Slashdot Top Deals

I cannot conceive that anybody will require multiplications at the rate of 40,000 or even 4,000 per hour ... -- F. H. Wales (1936)

Close