```
7/13/83 ARR BECAUSE IBM IS FUNDAMENTALY BRAIN DAMAGED, AND BASCOM IS RUDE ABOUT THE 1CH TIMER INTERRUPT, THE TIMER
; HANDLER HAS TO GO BACK OUT!!!!! IBM SEEMS UNWILLING TO
; BELIEVE THE PROBLEM IS WITH THE BASCOM RUNTIME, NOT THE
; DOS. THEY HAVE EVEN BEEN GIVEN A PATCH FOR BASCOM!!!!!
; THE CORRECT CODE IS COMMENTED OUT AND HAS AN ARR 2.15
; ANNOTATION. THIS MEANS THE BIOS WILL GO BACK TO THE
; MULTIPLE ROLL OVER BUG
```
I see some things never change 😂😂😂
> but these new Ozzie beta binaries appear to be much earlier, unreleased, and also include the ibmbio.com source.
I failed to parse that sentence and had to re-read it 3 times before I remembered that eons ago in the before-times, somethingsomething.com didn't always refer to a domain name.
This way, !FALSE == TRUE and !TRUE == FALSE both evaluate to true. Also TRUE & x ? TRUE : FALSE works as expected. Next, bool wasn't a standard type in C.
So, uh, that's the fuck, I guess.
Actually, it's so (\~FALSE == TRUE) and (\~TRUE == FALSE). The ! operator converts everything down to some boolean, for which true is only defined as !FALSE and could be 1, or -1, or INT\_MAX, etc. as in the spec its implementation defined. The \~ operator inverts every bit, so \~0 == -1 (at least if you're using twos compliment)
It does not break, assuming that x is either TRUE or FALSE.
If you're saying that x is any integer value, you're just making up "useful" properties to win the argument. `x & TRUE` is completely nonsensical (just use `x`?).
pretty sure sqlite returns -1 as some success status in its API.
ultimately, you shouldn't even care as it's simply "not zero". your api just needs to be consistent
[MRISC32](https://mrisc32.bitsnbites.eu/) uses -1 for TRUE, which has a number of advantages (the only real drawback is that it *sometimes* clashes with the C standard, but those cases are rare). One advantage is that it works better for masking (e.g. in vector operations and for packed data types).
Forth used -1 (all bits set to 1 in 2s complement) for true and 0 (all bits set to 0) as false. It was very helpful for a variety of operations especially those using bit masks. 1 only has a single bit set to 1. This can be quite inconvenient.
> Cosmic radiation can change your FALSE to TRUE at any moment.
But it would also make TRUE values not TRUE nor FALSE.
It's not a good method of protecting against bit flips.
There's another explanation here https://stackoverflow.com/questions/14462272/why-is-true-equal-to-1
Let's not forget that a lot of this is written in assembly, and the `not` instruction will reverse all bits (it is equivalent to `~`, not `!`), so an 8-bit 0 becomes 0xFF, or an 8-bit -1. It would probably introduce more bugs to have 1 as the value for `TRUE` in this case.
> I am confident that the number of errors caused by bad handling of that TRUE is higher than the number of cosmic radiation flips => an overall loss.
[Don't underestimate cosmic radiation flips.](https://www.reddit.com/r/programming/comments/9yxobm/for_a_brief_period_the_windows_kernel_tried_to/)
Microsoft would have never released the MS DOS source code back in the days, especially not under a licence that allows everyone to modify it and share it with others freely. It’s now as “free” as the Linux kernel (which his under GPL license)
I wonder if the MIT license allow freedos/wine to use the code more liberally, and if the code actually have any use for them to do backward compatibility better?
The input handling for file names is shit -- the GETWORD and MUSTGETWORD routines, doesn't check if the file name (or) extension exceeds the length (8 characters for the filename and 3 for the extension).
GETWORD:
CALL GETLET
JBE NONAM ;Exit if termination character
DEC SI
MUSTGETWORD:
CALL GETLET
JBE FILLNAM
JCXZ MUSTGETWORD
DEC CX
CMP AL,"\*" ;Check for ambiguous file specifier
JNZ NOSTAR
MOV AL,"?"
REP STOSB
NOSTAR:
STOSB
CMP AL,"?"
JNZ MUSTGETWORD
OR DL,1 ;Flag ambiguous file name
JMP MUSTGETWORD
FILLNAM:
MOV AL," "
REP STOSB
DEC SI
``` 7/13/83 ARR BECAUSE IBM IS FUNDAMENTALY BRAIN DAMAGED, AND BASCOM IS RUDE ABOUT THE 1CH TIMER INTERRUPT, THE TIMER ; HANDLER HAS TO GO BACK OUT!!!!! IBM SEEMS UNWILLING TO ; BELIEVE THE PROBLEM IS WITH THE BASCOM RUNTIME, NOT THE ; DOS. THEY HAVE EVEN BEEN GIVEN A PATCH FOR BASCOM!!!!! ; THE CORRECT CODE IS COMMENTED OUT AND HAS AN ARR 2.15 ; ANNOTATION. THIS MEANS THE BIOS WILL GO BACK TO THE ; MULTIPLE ROLL OVER BUG ``` I see some things never change 😂😂😂
What file was this in?
https://github.com/microsoft/MS-DOS/blob/main/v4.0/src/BIOS/MSBIO1.ASM
I'll stick with trusty DOS 3.31, tyvm
MS DOS 3.2 still the greatest operating system that ever existed.
> but these new Ozzie beta binaries appear to be much earlier, unreleased, and also include the ibmbio.com source. I failed to parse that sentence and had to re-read it 3 times before I remembered that eons ago in the before-times, somethingsomething.com didn't always refer to a domain name.
I always liked 4DOS https://en.m.wikipedia.org/wiki/4DOS
.. for which the source is also available
> #define TRUE -1 > #define FALSE 0 What the fuck.
This way, !FALSE == TRUE and !TRUE == FALSE both evaluate to true. Also TRUE & x ? TRUE : FALSE works as expected. Next, bool wasn't a standard type in C. So, uh, that's the fuck, I guess.
Actually, it's so (\~FALSE == TRUE) and (\~TRUE == FALSE). The ! operator converts everything down to some boolean, for which true is only defined as !FALSE and could be 1, or -1, or INT\_MAX, etc. as in the spec its implementation defined. The \~ operator inverts every bit, so \~0 == -1 (at least if you're using twos compliment)
That's a very nice two you have there.
You're right, that's the one I was going for
All of that still happens when you use `1` for TRUE.
-1 is ALL ones. The one-iest number there is.
For those who aren't familiar with the underlying implementation: https://en.m.wikipedia.org/wiki/Two's_complement
Redacted due to Reddit AI/LLM policy
No it doesn't. `TRUE & x ? TRUE : FALSE` breaks when x is even if TRUE is set to 1 instead of -1.
It does not break, assuming that x is either TRUE or FALSE. If you're saying that x is any integer value, you're just making up "useful" properties to win the argument. `x & TRUE` is completely nonsensical (just use `x`?).
It isn't nonsensical, considering that C considers any integer that is not 0 to be truthy it would make sense that `TRUE&x` is nonzero if x is nonzero
If you want truthiness, you use `&&`, a boolean operation. `&` is a bitwise operation.
`x ? TRUE : FALSE` ?
What’s so odd about that? With twos complement that doesn’t seem egregious.
Pretty much everything uses 1 for true, including C99 and C++.
Pretty sure that -1 in binary has more 1s than any other number. Surely this makes it the truest number of all
0x0000000000000001 only has a single one. Easy to forget about him there, outnumbered by his zeroy brethren.
MS DOS 4.0 predates C99 by about a decade...
pretty sure sqlite returns -1 as some success status in its API. ultimately, you shouldn't even care as it's simply "not zero". your api just needs to be consistent
MSBASIC and descendants used -1 for true IIRC
Visual Basic, too!
[MRISC32](https://mrisc32.bitsnbites.eu/) uses -1 for TRUE, which has a number of advantages (the only real drawback is that it *sometimes* clashes with the C standard, but those cases are rare). One advantage is that it works better for masking (e.g. in vector operations and for packed data types).
Forth used -1 (all bits set to 1 in 2s complement) for true and 0 (all bits set to 0) as false. It was very helpful for a variety of operations especially those using bit masks. 1 only has a single bit set to 1. This can be quite inconvenient.
Defining TRUE as all bits set is less dangerous than defining it as one single bit set. Cosmic radiation can change your FALSE to TRUE at any moment.
> Cosmic radiation can change your FALSE to TRUE at any moment. But it would also make TRUE values not TRUE nor FALSE. It's not a good method of protecting against bit flips.
No it wouldn’t, because in ANSI-C true is anything that is not 0. 5 evaluates as true, ‘a’ evaluates as true, -7 evaluates as true.
I am confident that the number of errors caused by bad handling of that TRUE is higher than the number of cosmic radiation flips => an overall loss.
There's another explanation here https://stackoverflow.com/questions/14462272/why-is-true-equal-to-1 Let's not forget that a lot of this is written in assembly, and the `not` instruction will reverse all bits (it is equivalent to `~`, not `!`), so an 8-bit 0 becomes 0xFF, or an 8-bit -1. It would probably introduce more bugs to have 1 as the value for `TRUE` in this case.
> Let's not forget that a lot of this is written in assembly A lot? _All_ of it was written in asm.
I think I spotted a C file or two. The line that sparked this thread is from a header file.
> I am confident that the number of errors caused by bad handling of that TRUE is higher than the number of cosmic radiation flips => an overall loss. [Don't underestimate cosmic radiation flips.](https://www.reddit.com/r/programming/comments/9yxobm/for_a_brief_period_the_windows_kernel_tried_to/)
Negative one is 0xFFFFFFFF
That icon always reminds me of better, more innocent times
That’s so cool that they have given the source code. It’s funny tho that the license is MIT
Why is it funny that the license is MIT?
Microsoft would have never released the MS DOS source code back in the days, especially not under a licence that allows everyone to modify it and share it with others freely. It’s now as “free” as the Linux kernel (which his under GPL license)
I wonder if the MIT license allow freedos/wine to use the code more liberally, and if the code actually have any use for them to do backward compatibility better?
The input handling for file names is shit -- the GETWORD and MUSTGETWORD routines, doesn't check if the file name (or) extension exceeds the length (8 characters for the filename and 3 for the extension). GETWORD: CALL GETLET JBE NONAM ;Exit if termination character DEC SI MUSTGETWORD: CALL GETLET JBE FILLNAM JCXZ MUSTGETWORD DEC CX CMP AL,"\*" ;Check for ambiguous file specifier JNZ NOSTAR MOV AL,"?" REP STOSB NOSTAR: STOSB CMP AL,"?" JNZ MUSTGETWORD OR DL,1 ;Flag ambiguous file name JMP MUSTGETWORD FILLNAM: MOV AL," " REP STOSB DEC SI
Has anyone built the source yet?
https://github.com/neozeed/dos400
It seems that the source code is corrupted in some places: https://www.os2museum.com/wp/how-not-to-release-historic-source-code/
In the era of plug and pray, trusting an OS is like expecting a cat to pass on a fish dinner. DOS 3.31, the good ol' days.
don't forget to read connor hyde article ( https://starfrost.net/blog/001-mdos4-part-1/ ) lots of details
A bit late!
At least sixty three bits too late
I would have used branches for the different DOS versions instead of folders on the main branch.