Stories
Slash Boxes
Comments

SoylentNews is people

posted by janrinok on Saturday January 08 2022, @08:10PM   Printer-friendly [Skip to comment(s)]
from the PC-introns dept.

https://www.os2museum.com/wp/unidentified-pc-dos-1-1-boot-sector-junk-identified/

Anyone trying to disassemble the PC DOS 1.1 boot sector soon notices that at offsets 1A3h through 1BEh there is a byte sequence that just does not belong. It appears to be a fragment of code, but it has no purpose in the boot sector and is never executed. So why is the sequence of junk bytes there, and where did it come from?

The immediate answer is "it came from FORMAT.COM". The junk is copied verbatim from FORMAT.COM to the boot sector. But those junk bytes are not part of FORMAT.COM, either. So the question merely shifts to "why are the junk bytes in FORMAT.COM, and where did they come from?"

It is not known if anyone answered the question in the past, but the answer has been found now, almost 40 years later—twice independently.


Original Submission

This discussion has been archived. No new comments can be posted.
Display Options Threshold/Breakthrough Mark All as Read Mark All as Unread
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
(1)
  • (Score: 1, Touché) by Anonymous Coward on Saturday January 08 2022, @08:45PM

    by Anonymous Coward on Saturday January 08 2022, @08:45PM (#1211119)

    It's Microsoft's first attempt at telemetry.

  • (Score: 3, Interesting) by Snotnose on Saturday January 08 2022, @10:33PM (2 children)

    by Snotnose (1623) on Saturday January 08 2022, @10:33PM (#1211141)

    TRS-80, early model (type II? I forget). I disassembled the BASIC Z-80 assembly code. Lots of things like "jmp 0xsomewhere", except the code would jump to "some". In other words, the code would execute the first byte of a jump address.

    I never knew if I should bow down in front of Paul or Bill, but that code was A) magnificent; and B) unmaintainable.

    --
    Now I'm worried. I just spent several minutes using Where's My Droid and my phone's flashlight to, ... find my phone.
    • (Score: 2) by driverless on Sunday January 09 2022, @02:43AM (1 child)

      by driverless (4770) on Sunday January 09 2022, @02:43AM (#1211178)

      That was a standard programming technique back then, you could bypass branches and/or individual instructions by prepending a byte that made the instruction that followed the operand of some no-op equivalent. Depending on whether you jumped to location n or n+1 you'd get a different effect.

      • (Score: 4, Informative) by Mojibake Tengu on Sunday January 09 2022, @03:28AM

        by Mojibake Tengu (8598) Subscriber Badge on Sunday January 09 2022, @03:28AM (#1211184) Journal

        This technique was common in assembly as imitation of procedures and subprograms with multiple entrypoints in certain high languages.

        When naive functionalists defeated sanity, the whole concept of procedures as subprograms (together with multiple entrypoints idea) vanished from this reality.

        --
        The edge of 太玄 cannot be defined, for it is beyond every aspect of design
  • (Score: 1, Touché) by Anonymous Coward on Sunday January 09 2022, @12:12AM (1 child)

    by Anonymous Coward on Sunday January 09 2022, @12:12AM (#1211162)
    After all, given things like comments not updating again, the old farts would probably have ab easier time maintaining the site if it we're using DOS - more their comfort zone. And with the newer dos protected mode extenders that can use a 4gig address space …
    • (Score: 2) by DannyB on Monday January 10 2022, @06:26PM

      by DannyB (5839) Subscriber Badge on Monday January 10 2022, @06:26PM (#1211570) Journal

      Don't judge me for reading the article . . .

      Note that in the PC DOS 1.0 boot sector, the strange zero-termination is combined with high-bit-termination, and the strings ‘ibmbio com0’ and ‘ibmdos com0’ are each stored with the last byte as B0h, which is ASCII ‘0’ (30h) + 80h. In PC DOS 1.1, the high bit is no longer set.

      I think this practice of zero terminating strings using an ASCII zero character '0' (30h) with the high bit set (XOR 80h) should be a new standard way of encoding strings.

      --
      Calmly vote. Fill out your ballet and drop it in the ballet box. Don't dance around bothering the pole watchers.
  • (Score: 4, Informative) by acid andy on Sunday January 09 2022, @01:18AM (2 children)

    by acid andy (1683) on Sunday January 09 2022, @01:18AM (#1211171) Homepage Journal

    That's an incredibly nerdy article. The most interesting bit was about old software using 7-bit ASCII often setting the high bit of the last character in a string as the string terminator, to save a byte of memory.

    As for the rest of the article, I think they're perhaps getting a little over-excited over what sounds like one or two examples of sloppy programming or harmless glitches in the code that didn't change the functionality (but maybe saved programmer time or a few CPU cycles).

    On second thoughts we could probably do with more nerding out around here and hyper-focus on inconsequential little oddities buried in obsolete operating systems, so keep it up!

    --
    Master of the science of the art of the science of art.
    • (Score: 4, Interesting) by bzipitidoo on Sunday January 09 2022, @02:44AM (1 child)

      by bzipitidoo (4388) on Sunday January 09 2022, @02:44AM (#1211179) Journal

      Old nerdiness. I like it!

      I've been studying the history of computing, and if I had to pick just one word to describe it, it would be "haste". Everyone was in a tremendous hurry to push the kludge out the door once it was in a functional state, however fragile. Had to beat the competition to market. Or, academia was desperate to promulgate a standard, quick, before all the commercial vendors pushed out a dozen or more mutually incompatible methods for solving the problems of the moment. They often did rush things out too fast.

      But yes, in the 1970s memory was tight, really, really tight. People did sweat over every byte. So these junk bytes being overlooked is a little odd. The Apple II disk controller had only a tiny program capable of only a braindead pulling of the arm to the edge of the disk, and loading the first few bytes. SCSI it was not. It would move the arm the full width of the disk regardless of where it happened to be when the boot sequence was started, thus the thudding noise it often made on boot as the arm bumped up against the limiter at the edge. The code it loaded from those first few bytes of the disk had to contain the instructions to tell the computer how to read the rest of track zero, which contained the code to perform disk arm movements so that the computer could read the rest of the tracks. Today, all that is built into the controller hardware. Back then, it was a very literal bootstrap process, and the C in CPU was meant in a very total way. Almost everything the computer did went through the CPU. One of the major ways computer performance has improved so greatly over the years is in offloading all the work that can be offloaded, freeing the CPU for general work, no more loading it down with low level disk read and write work, audio work, and especially video graphics work.

      The slop in the Apple DOS was that in their haste to push it out the door, they overlooked a few simple things that greatly slowed disk reads and writes. The time it took their code to process a sector was a shade too long, and by the time it finished, the start of the next sector had rotated just past the head, forcing a wait for the disk to spin all the way around. Took as many as 17 revolutions of the disk to read the entirety of one track. Wasn't long before aftermarket DOSes appeared that addressed that deficiency, reducing the read times for a track to 2 or even 1 revolution.

      • (Score: 3, Interesting) by looorg on Sunday January 09 2022, @08:04AM

        by looorg (578) on Sunday January 09 2022, @08:04AM (#1211216)

        While this does sound like a plausible explanation I sort of wonder why you would allow this junk into the program tho if the goal was to save bytes of memory? You probably would also waste bytes of storage, which at the time also was quite expensive. Wouldn't it have been a lot better in that regard to just zero it out, or just make it something controlled so it could be compressed better?

        In that regard I almost wonder if some of it was left in there as a copyright claim. Considering there was a multitude of DOS:es etc at the time things was probably left behind there for all the people that copied your stuff so you could later claim they copied you and it was lawsuit time. So instead of leaving something legible you leave some "junk". Sounds like something Bill and friends would do.

  • (Score: 2) by DrkShadow on Sunday January 09 2022, @02:37AM

    by DrkShadow (1404) on Sunday January 09 2022, @02:37AM (#1211177)

    :-D

    The junk in the PC DOS 1.1 boot sector isn’t the only instance of such junk. For example IBMBIO.COM also contains a different and larger junk sequence which is partly a repetition of the contents of IBMBIO.COM itself.

    It is virtually certain that the junk bytes came indirectly from development tools used for building PC DOS 1.1, namely Microsoft’s assembler/linker.

    So the junk probably comes from the linker.. which put the junk into format.com.. which dumps code and junk into the bootsector. Who'da thought, and how the hell did that not result in errors? "Works for me!"

    I recall seeing something like xbmbio.com on the Dell boot stuff - for automatically flashing the BIOS. This sort of thing persists for a long, long time. It's really amazing. Imagine how we'll be using EFI boot packages in 30 more years.

  • (Score: 2, Funny) by Anonymous Coward on Sunday January 09 2022, @04:17AM (1 child)

    by Anonymous Coward on Sunday January 09 2022, @04:17AM (#1211188)

    This is breaking news, and it came just in time. I was planning to upgrade my trusty 8088 to one of those new 80286 processors. Not sure if this release of DOS will run on the new hardware though...

    • (Score: 2) by Thexalon on Sunday January 09 2022, @11:44PM

      by Thexalon (636) on Sunday January 09 2022, @11:44PM (#1211347)

      Why would you do that? We all know that 640Kb should be enough for anybody!

      --
      Alcohol makes the world go round ... and round and round.
  • (Score: 0) by Anonymous Coward on Sunday January 09 2022, @02:38PM (1 child)

    by Anonymous Coward on Sunday January 09 2022, @02:38PM (#1211244)

    Now if you'll excuse me, I have to get back to read the newspaper from 1979, yes I got a bit behind

    • (Score: 1, Insightful) by Anonymous Coward on Sunday January 09 2022, @04:54PM

      by Anonymous Coward on Sunday January 09 2022, @04:54PM (#1211259)

      It is useless and out of date junk, but that's also how I feel about any web-related technologies I am forced to learn. I've got to know it, but it very, very soon becomes obsolete knowledge. Makes it hard to get motivated to learn any more than is absolutely necessary to get the job done.

(1)