Hi there,

I am looking for a way to determine drive types in plain DOS. I already found a piece of software in the SWAG archive but the results on modern hardware and FreeDOS are not exactly convincing. Does anybody know of any forums with dedicated DOS programming sections? All suggestions are highly welcome

Hi...

Imho, this is one of the best DOS programming resources web page:
http://www.ctyme.com/rbrown.htm

Regards,
Opc0de

Opcode, cool, I like the searchable web-interface.

laola, if you're interested, here's the official page for RBIL: http://www.cs.cmu.edu/afs/cs.cmu.edu/user/ralf/pub/WWW/files.html ("http://www.cs.cmu.edu/afs/cs.cmu.edu/user/ralf/pub/WWW/files.html")

If you can read Chinese, or know how to use a Translator, then http://cn-dos.net is a good site to read through. It seems a lot of DOS-related material has moved over into the East. They also have DOS forums at http://bbs.cn-dos.net/

Thanks for all the suggestions, I know about RBIL and in the little time I had to work on DOS level now, I instantly became a great fan of it I already have a local mirror of the ctyme url, the html version is really great
However, the mass of information accumulated there is just huge and I'm digging for the needle in the hay
At present, I have a nice little problem, I use NTFS4DOS to be able to read from NTFS drives in DOS. But I can't seem to get any information about the mounted drives. Even the most simple checks like Int21h/AX=4409 fail for the NTFS drives. Well, AX=4409 delivers a valid return value at least for the first mounted partition, the others fail as if they weren't there.
*big sigh*
That's why I am searching for advanced dos programming resources. Thanks for the tip with chinese pages, I hope there is a bit of automated translation available on the web

Howdy,

NTFS4DOS is a sweet suite of tools.
You dont say what OS you are playing with.
If it is 2000/XP you need to work from the floppy/boot disk and run CHKDSKG.
In older versions of windows 98/me ? You can work from a DOS box and run the same command.
The command you are trying to use is probably not supported.

I am going to play around with this a bit.

Woodmann

Hi Woodmann,

I am building my own disk with recovery utilities, based on the current FreeDOS kernel. I am not sure if you got me right, using the drives from the dos prompt, etc. works perfectly. I just can't seem to enumerate all the available drives with common Int21h functions. For example: I tried calling Int21h with AX=4409 (BL=drivenumber). RBIL says, CF will be set on error. On my current setup, I'll get CF=1 from C: to W: (as these drives do not exist), and CF=0 for X: (ramdisk), Y: (cdrom) and Z: (cdrom). Loading NTFS4DOS and running my test program again shows this:

NTFS4DOS detects C:, D: and E: (my NTFS hard disks), and assigns F: for its internal ramdrive (why do I have to have an additional ramdrive here, I already have one!). My test program, however, delivers CF=0 for C: and CF=1 for D: to F:! This is what gets me stumped quite a bit.

Meanwhile (reading FreeDOS sources) I found that the CDS structure should have a number of flags to help me out. If I read RBIL right, I can get the CDS array from the LOL which shouldn't be a problem. I'll write up some test programs tomorrow and keep you updated on my findings

Oh, forgot to mention, the NTFS drives are both native 2K and XP drives (NTFS4/5).

Howdy,

The extended DOS functions are available through software interrupt 21h (INT 21h). The function number is placed in register AH. If the function was successful, carry flag on return will be cleared, otherwise the carry flag will be set, and an error code will be placed in the EAX register.

Me thinks you are on the correct path .

Woodmann

Why don't you reverse NTFS4DOS and figure out how it works, then integrate NTFS read/write functionality into the FreeDOS kernel or implement it as a filesystem driver?

I remember reading a Chinese page that claimed they had successfully booted an MS-DOS kernel from an NTFS partition, with full read/write... I'll see if I can find that URL. If I remember correctly, they integrated an NTFS filesystem driver into the kernel.

Why are you wasting time with interrupts? Why not just use IN and OUT x86 instructions instead?

disavowed: No need to ridicule me. I'm using the (sort of) documented DOS API because I don't feel like inventing all sorts of wheels once more. And by the way, I'd like to see your code sample of how to determine drive letters with IN and OUT

LLXX: NTFS4DOS is not exactly trivial, and I think it will cost much more time to reverse that than to find out how to retrieve the desired information from DOS structures. It's just the overwhelming amount of incomplete documentation, combined with lack of detail knowledge about the inner workings that slows me down, often enough I just have to write up test programs to find out more. That's why I am asking here, just searching for additional sources of information to speed up the whole process. I'd appreciate a good "DOS internals" book for example

Woodmann: Yeah, I know all that (and more) from RBIL, I'm not that n00b I'll post my findings as soon as they are complete

About ntfs implementation: NTFS core needs quite some space and you know, in plain dos memory is a very limited resource. Not even taking into account MS' patents on NTFS and the lack of documentation of the format. NTFS is so much different from FAT, amazing work (if it really exists) from these chinese guys.

It sounds like two groups are working to similar DOS projects powered with NTFS and USB support(!):

russian - http://www.amparo.com.ru/silver_disk_eng.htm
chinese - http://www.cn-dos.net/newdos/dosmain.htm (search for DOS71_1 for downloading it)

Regards, bilbo

Howdy,

I now understand what you are doing. The funny thing about int21 with regards to DOS and NTFS is, there are tools that claim to support int21 but they cannot display the information.

Check out NTFS Browser for DOS.

Woodmann

Update: After trying quite a lot of things, I can now determine everything I wanted to. I had to go the hard way, retrieving a pointer to the LOL (list of lists), then getting the pointer to the CDS array from it and parsing the CDS array content.
The last thing that's missing is the network drive benchmark I didn't have time to setup dos network yet, I'll test that tomorrow.

@Woodmann: I'm not exactly interested in reading NTFS drives now, I just want to be able to say "here this drive F: is a (native FAT|NTFS|Ramdrive|CDROM|Network) drive." Everything else comes a bit later

I wasn't implying you perform a full reverse, but only the portions that are of interest to you. In this case, it would be the "partition enumerator" component. It seems NTFS4DOS isn't

On the topic of documentation, there is a book by the name of "Undocumented DOS" written by Andrew Schulman. It has been digitised and can be retrieved from the Internet with a suitable Google query

hehe

working on DOS, the LOL is the only thing you can rely on imho

too late, cool you figured it out allready! man thaaaaat were times !!!

regards,

--
0xf001

And the odyssey continues... after clearing up the issues concerning core functionality, I now have to fight with a graphics library that's just insane. *big sigh* Who ever invented (or allowed) cyclic references between pascal units, he really deserves a beating. I'm still not sure if I should just rewrite the stuff or make someone find out how to compile the unit completely

What's the problem with compiling the pascal unit? Note that circular (what you call "cyclic" references are allowed (i.e. compilable) in the "implementation" section of a Pascal unit but not in the "interface" section...

It's a large library consisting of quite some units, missing obj files and much more. If you'd like to have a look at it, check this out: http://sourceforge.net/projects/gvision

Fortunately, I found a board with a pascal section where a very nice guy took the effort of looking at it, finding out how to compile it properly and telling me what he found out

Alas, this one was really nasty. And the next nastyness (is that a word?) is already ahead: Somewhere during the process of creating the dialog with the detected drives, a major memory corruption takes place I have no idea where as of yet, just that it works if I skip the detection and return bogus data to fill the dialog. That'll be another funny piece of work *sigh*

Maybe I should create a blog for this adventure

why not use the original Turbo Vision if you're going 16-bit? there is also another port of turbo vision called TVision at http://tvision.sourceforge.net and they say they have a DOS version. it might be better? i'm not even sure if thats the problem you're having now :P.

Well I have a lot of code that would require rewriting if I'd switch to Turbo Vision. Anyway, I located the bug in question, simply a dynamically allocated buffer that was too small (stupid folks, can't they even read RBIL?!) for the requested data, thus overwriting whatever was on the heap behind it. This bit is working properly now, but there seem to be more issues. I have an odd crash when quitting the program. Now I am trying to find out how do use standalone debugging with Turbo Debugger properly. Parts of the program environment (namely the NTFS driver) cause a reboot when I try to start tpx.exe (the Turbo Pascal DPMI IDE, the source is too large to the basemem IDE). Gnaaaaa.....