2015 mid-year link clearance


The semi-annual link clearance is here!

Comments (11)
  1. anonymouscommenter says:

    Mrs. 12BitSlab and I have been on both the Oasis and the Allure several times.  Unbelievable ships.  One can't appreciate how big they are until you see it in person.  They are larger than a Nimitz class carrier.

  2. anonymouscommenter says:

    With all of your amazing stuff there's probably enough people how thought "because he's Raymond". So it's extra funny to read you being in awe by Woz.

    (And totally agreed, of course)

  3. anonymouscommenter says:

    Even though the 6502 wasn't a real RISC architecture, it certainly was when you compared it to something as baroque as the 8086. Initially, I had trouble understanding how my Commodore 64 would occasionally outstrip my friend's XT on some computational tasks, even though the XT's CPU was clocked higher. After I got a look at the instruction set of the 8086 and the timings, I didn't wonder as much. (Of course, the XT had an 8088 with an 8-bit bus that seriously handicapped it compared to an 8086, which I also didn't factor in.)

  4. anonymouscommenter says:

    My first job as a professional programmer was writing games for Apple IIs using 6502 assembly. I had to learn C at that job to write some utilities to compile game data sets. It stumped me for a day until I turned on the "create assembly output" in Turbo C and had the epiphany that C was just a super Macro Assembler.

  5. jonwil says:

    What makes this new compression stuff any better than either A.Various compression stuff Windows has already had for ages (lzexpand and others)? And what makes it better than using zlib?

    i.e. why does this new compression code (and the MS-specific algorithms it seems to support) actually exist?

    [lzexpand supports decompression, but not compression. zlib is a static library. In other words: What's new is that it's a DLL and that it can do compression at runtime. -Raymond]
  6. anonymouscommenter says:

    That new compression API is really well-designed (like much of Win32).  It's a little complicated to use, but it's extremely powerful and supports streaming compression, a method to compute the maximum possible compressed size of any possible data, and user-provided allocators to avoid the need to know a priori how much memory to allocate and without using a fixed system-provided allocator.

    As the "Worse is Better" philosphy goes, "simplicity of implementation is better than simplicity of interface."

  7. anonymouscommenter says:

    Wow (the 6502 code).  Clear, well-commented source code, with the comments explaining the circumstances and expectations around what the code is doing.  I STILL talk to people who say "The code is its own documentation".  No, it's not.

  8. anonymouscommenter says:

    I just wanted to say that LZMS compression is awesome. Thankyou, CABINET.DLL 8.x. :)

  9. cheong00 says:

    [lzexpand supports decompression, but not compression.]

    So the real question is: Any idea on why Windows does not ship with LZ compressor while it ships with decompressor since the time of Win2.X? (My Turbo Pascal for Windows reference point to Win2.0 as earliest only, so no idea whether it ships with Win1.X)

  10. anonymouscommenter says:

    @Raymond: zlib is a static library.

    No. It can easily be compiled as a dll.

    http://www.zlib.net/

    As usual MS in reinventing the wheel.

    [Allow me to prephrase. "Every app needs to include (and therefore service) its own copy of zlib." Also, what's wrong with developing new compression algorithms? Or are you saying, "LZ77 ought to be be enough for anybody." -Raymond]
  11. anonymouscommenter says:

    @640k: Did you know Windows also contains libraries for cryptography, HTTP/FTP/Gopher, Unicode handling, font rendering, common controls, and media decoding? Should they not have those?

    And almost every Linux distribution has tons of stuff that could be left to applications.

    While I agree that it's probably a bad idea to include these things in the operating system's API, because it creates additional compatibility constraints (they still have a Gopher library!), it's also a good service to applications (less external dependencies) and also it's not without precedent.

    I also suspect Microsoft want to eliminate as many external dependencies as possible. I would if I was in their position. Too many things to potentially be sued over.

Comments are closed.

Skip to main content