Hi guys,
It is probably better to use the source of VMSMOUNT as basis for TSR
drivers for exFAT access :-)
Thanks, I'll keep that in mind. I already downloaded it.
However, my plan is to _first_ release and test the (then read/write)
access as a _C_ program and when the algorithm is stable and bugfree (?!)
then rewrite the whole thing, instruction by instruction, in DOS
assembly. I already did the opposite once. (Fortunately, there's not much
to do to translate between C and assembly. ;-) ) Honestly, I don't wish
to debug an assembly program, seeing the debug facilities of any C
environment.
Regarding nasty integers above 32 bits: No worries, as long as we do
not support GPT, we only support 2^32 sectors in MBR :-p
Then why does INT 13h, AH = 42h (BIOS extended read disk) expect the LBA
sector number in a 64-bit integer? Oh, I see: _this_ supports LBA48 (and
further), while now the _MBR_ becomes a new constraint, with its 32-bit
LBA sector numbers. Ehhh...
I haven't looked into GPT yet but I don't think it should be _that_
complicated.
Also, you can of course use 64 bit data types in DOS software.
I know. :-) I wrote a DOS program in assembly that lists the contents of
compressed archives: http://sta.c64.org/pcutils.html#arclds . (This is
the one that I translated to C but it's not released yet.) It compiles
for 386 and above and uses two 32-bit registers for 64-bit integers. But
Borland C++ is too ancient for this, and we agreed on that drivers
shouldn't require protected mode, which move us to...
I agree that OpenWatcom would be nicer than Borland C++ here.
I agree. I forgot to mention that, while I never tried OpenWatcom and
only looked at DJGPP a few times, I plan to "port" (read: add lots of
ifdef's :-) ) the program to both.
(At this moment, the 16-bit DOS program and the 32-bit Windows program
creates _identical_ output, including the lots of debug messages, for the
directory tree of a virtual disk image with a few directories and
hundreds of files. So, this really is possible. gcc's warnings, when all
enabled, helped a lot with my integer size compatibility problems.
Amazing!)
Not sure if Pascal would be nice for TSR drivers: You can do
it (see keyboard driver) but the extra effort is that you have
to translate existing filesystem code which probably is in C.
I wrote a complete Norton Commander clone with lots of extras:
http://sta.c64.org/sc.html in Borland Pascal (OOP, heavily modified Turbo
Vision) but that project started in 1994. Now I see: Pascal is child's
play compared to C. (And I knew even back in 1994 that OOP sucks. ;-) )
Sorry to Pascal lovers. (And, yes, I've already started to port it to
Free Pascal, with good results.)
In any case: Do not panic.
Actually, I don't think you could dissuade me from this anymore. ;-)
Now I have a bit more work to do with my daily job but I'll continue
development. I'll keep you informed.
Joe
--
KOVÁCS Balázs aka Joe Forster/STA; [email protected]; http://sta.c64.org
Don't E-mail spam, HTML or uncompressed files! More contacts on homepage
------------------------------------------------------------------------------
_______________________________________________
Freedos-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/freedos-devel
