4 ms·

I must be missing something. The article lists three libcs (Open Watcom, Microsoft Visual C++ 6.0, IBM C/C++ 3.6 for Windows) from the good old times. Does the

I must be missing something. The article lists three libcs (Open Watcom, Microsoft Visual C++ 6.0, IBM C/C++ 3.6 for Windows) from the good old times. Does the emulator link to Open Watcom, i.e., does it emulate DOS on machines about as old as DOS itself? What's the point here?

AntiRush 2y ago
The article is about compiling and running a program inside the emulator. When the unexpected behavior occurred, the author assumed it was a bug in the emulator.
- purplesyringa 2y ago
  So if it's not a bug in the emulator, then it's a bug in COMMAND.COM? I don't think that's the case, surely it couldn't have been missed by Microsoft at the time. The article goes on to talk about fread/fwrite calls, but COMMAND.COM was written in assembly, I'm pretty sure it didn't link to any libc, and certainly not to Open Watcom -- why would MS use it instead of their own library?
  - grodriguez100 2y ago
    It is not a bug. The article explains that this is the expected behaviour.
    - purplesyringa 2y ago
      What is expected behavior? Surely `echo AB> foo.txt; echo CD>> foo.txt` producing `ABBC` is either a bug in COMMAND.COM, the emulator, or something else? That can't be correct.
      - deleted 2y ago
        [deleted]
justin_ 2y ago
I believe it is a bug in the the emulator's implementation of COMMAND.COM. Often, these DOS "emulators" re-implement the standard commands of DOS, including the shell[1]. This is in addition to emulating weird 16-bit environment stuff and the BIOS. The bug can pop up in any C program using stdio that assumes it's fine to do `fread` followed immediately by `fwrite`. The spec forbids this. To make matters more confusing, this behavior does _not_ seem to be in modern libc implementations. Or at least, it works on my machine. I bet modern implementations are able to be more sane about managing different buffers for reading and writing. The original COMMAND.COM from MS-DOS probably did not have this problem, since at least in some versions it was written in assembly[2]. Even for a shell written in C, the fix is pretty easy: seek the file before switching between reading/writing. The title of this post is confusing, since it clearly _is_ a bug somewhere. But I think the author was excited about possibly finding a bug in libc: > Sitting down with a debugger, I could just see how the C run-time library (Open Watcom) could be fixed to avoid this problem. [1] Here's DOSBox, for example: https://github.com/dosbox-staging/dosbox-staging/blob/main/src/shell/shell_cmds.cpp https://github.com/dosbox-staging/dosbox-staging/blob/main/s... [2] MS-DOS 4.0: https://github.com/microsoft/MS-DOS/tree/main/v4.0/src/CMD/COMMAND https://github.com/microsoft/MS-DOS/tree/main/v4.0/src/CMD/C...
- rep_lodsb 2y ago
  The article is very vague about which emulator and COMMAND.COM it is about, and if they're integrated with each other. Can't be DOSBox, since it handles it correctly: C:\> echo AB> foo.txt C:\> echo CD>> foo.txt C:\> type foo.txt AB CD (Note that echo adds a newline, same as on real DOS, or even UNIX without "-n". This other shell doesn't for some reason.) The "real" COMMAND.COM, and all other essential parts of MS-/PC-/DR-DOS, have always been written in asm, where none of this libc nonsense matters. Also it annoys me greatly when people talk about "the C Library" as if it exists in some Platonic realm, and is essential to all software ever written.
stevage 2y ago
There's a lot of weird missing details.

AntiRush 2y ago

The article is about compiling and running a program inside the emulator. When the unexpected behavior occurred, the author assumed it was a bug in the emulator.

purplesyringa 2y ago
So if it's not a bug in the emulator, then it's a bug in COMMAND.COM? I don't think that's the case, surely it couldn't have been missed by Microsoft at the time. The article goes on to talk about fread/fwrite calls, but COMMAND.COM was written in assembly, I'm pretty sure it didn't link to any libc, and certainly not to Open Watcom -- why would MS use it instead of their own library?
- grodriguez100 2y ago
  It is not a bug. The article explains that this is the expected behaviour.
  - purplesyringa 2y ago
    What is expected behavior? Surely `echo AB> foo.txt; echo CD>> foo.txt` producing `ABBC` is either a bug in COMMAND.COM, the emulator, or something else? That can't be correct.
    - deleted 2y ago
      [deleted]

justin_ 2y ago

I believe it is a bug in the the emulator's implementation of COMMAND.COM. Often, these DOS "emulators" re-implement the standard commands of DOS, including the shell[1]. This is in addition to emulating weird 16-bit environment stuff and the BIOS. The bug can pop up in any C program using stdio that assumes it's fine to do `fread` followed immediately by `fwrite`. The spec forbids this. To make matters more confusing, this behavior does _not_ seem to be in modern libc implementations. Or at least, it works on my machine. I bet modern implementations are able to be more sane about managing different buffers for reading and writing. The original COMMAND.COM from MS-DOS probably did not have this problem, since at least in some versions it was written in assembly[2]. Even for a shell written in C, the fix is pretty easy: seek the file before switching between reading/writing. The title of this post is confusing, since it clearly _is_ a bug somewhere. But I think the author was excited about possibly finding a bug in libc: > Sitting down with a debugger, I could just see how the C run-time library (Open Watcom) could be fixed to avoid this problem. [1] Here's DOSBox, for example: https://github.com/dosbox-staging/dosbox-staging/blob/main/src/shell/shell_cmds.cpp https://github.com/dosbox-staging/dosbox-staging/blob/main/s... [2] MS-DOS 4.0: https://github.com/microsoft/MS-DOS/tree/main/v4.0/src/CMD/COMMAND https://github.com/microsoft/MS-DOS/tree/main/v4.0/src/CMD/C...

rep_lodsb 2y ago
The article is very vague about which emulator and COMMAND.COM it is about, and if they're integrated with each other. Can't be DOSBox, since it handles it correctly: C:\> echo AB> foo.txt C:\> echo CD>> foo.txt C:\> type foo.txt AB CD (Note that echo adds a newline, same as on real DOS, or even UNIX without "-n". This other shell doesn't for some reason.) The "real" COMMAND.COM, and all other essential parts of MS-/PC-/DR-DOS, have always been written in asm, where none of this libc nonsense matters. Also it annoys me greatly when people talk about "the C Library" as if it exists in some Platonic realm, and is essential to all software ever written.

stevage 2y ago

There's a lot of weird missing details.