Note: We do need to explicitly close FCBs. Reasons are as follows: If we
; are running in the no-sharing no-network environment, we are simulating the
; 2.0 world and thus if the user doesn't close the file, that is his problem
; BUT... the cache remains in a state with garbage that may be reused by the
; next process. We scan the set and blast the ref counts of the FCBs we own.
;
; If sharing is loaded, then the following call to close process will
; correctly close all FCBs. We will then need to walk the list AFTER here.
;
; Finally, the following call to NET_Abort will cause an EOP to be sent to all
; known network resources. These resources are then responsible for cleaning
; up after this process.
;
; Sleazy, eh?~
MS-DOS, Source public available on March 25 2014 with MS Research License, released with as Free Software MIT license in 2018, this yer released as Open Source MS-DOS 4.0.
Anyway, the Source code was available since 2014, only different licenses since then.
So cool, thanks. As a kid I spent so much time in DEBUG, stepping through DOS's executables, and especially the Interrupt handlers. It's so neat to see the actual source code-- way easier to read and follow. I didn't know it was all written in assembly, from within Debug it sometimes seemed so messy and convoluted that I just assumed more was written in C.
Is this useful for hobbyists besides poking around and seeking the design philosophy at work back then?
Like would there be any advantage or reason to implement this in a home project? For example maybe that it's lightweight and has some rare compatibility or anything like that?
reminds me of the last time I had to remember that dir/copy/move with backslashes. dad's insurance 'software'. always amazed me how computer users get stuck in a way of doing things. print mail