Re: [Freedos-32-dev] Removing the UseLfn parameter in the FAT driver

[luca a. <l_...@ho...>]

Hi all,
today is a rainy saturday in oregon, hence I have a lot of time for sending 
mails :)

[...]
>What you have as the "FD32 device list" looks much like the int20h of
>DOS386.EXE or KRNL386.EXE or whatever you call it, in Microsoft
>terminology. The action of "registering a device" would be analogous to
>"hook the appropriate subf. of int20h".
Ok, I am beginning to get it... I (once again :) proposed something similar 
to this ``interrupt hooking mechanism'' at the beginning of the project, but 
it was refused because it was not efficient enough (ehhhh... At that time, 
in this mailing list there were a lot of very skilled programmers...).

>You say that the DPMI redirects
>the int 21h call of DOS calls to the appropriate fd-32 driver.
>MS-DOSMGR
>redirects (iirc) these calls to the appropriate VxD driver.
Yes, I agree. Same concepts, different mechanisms.

>Are these functions offered to applications as an API? If so, how?
For the future, we plan to have a ``FD/32 native API'', but it is still not 
clear how it will look like...
An FD/32 native program will be dynamically linked into the kernel (exaclty 
as a driver), and will be be able to invoke kernel functionalities just 
using simple function calls (as the DPMI driver does, for example).
We still have to define the native API, and I am inclined to think that we 
could do it after that the DPMI support will be fully working: we could look 
at the functions used by the DPMI driver (and by other drivers, of course), 
and use them as a base for defining the FD/32 API.
(for having a look at the functions that are currently esported by the 
kernel, see fd32/kernel/syscalls.c
http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/freedos-32/fd32/kernel/syscalls.c?rev=1.5&content-type=text/vnd.viewcvs-markup

>If it's via some interrupt, why not use int 20h?
Currently, the INT-based ABI/API that we are supporting is DPMI.
As already said, nothing prevent us from exporting another INT20 based ABI 
(through a different driver) in the future.

>Just as an example, consider the VxD called VMM, the kernel of the
>DOS/Windows of 32-bits, and see the API:
>http://www.ctyme.com/intr/rb-2473.htm
I am studying it in my spare time... Our problem, right now, is that we have 
a lot of things to do, but only few (2?) coders willing to work on them... 
Hence, I don't know when I'll have the time to start working more seriously 
on this VxD issue.

>THe project in itself looks interesting. However, as I said in other
>messages, I still need a lot to learn, specially about EMM386.EXE. As
>far as I know, this driver, in the Microsoft version, offers EMS via
>processor paging, so it's a potential focus of information about VMs,
>and a potential focus of problems about installing the fd-32 once DOS is
>booted.
Yes, EMM386 has fairly different goals respect to FD/32 (for example, FD/32 
is not interested in EMM & similar things)... Probably it could be a good 
source of information, but I never had the time to study it.

>In DR-DOS, this seems to be an interesting and fundamental piece for
>this all, please read this article that you can find easily searching
>with Google:
>http://www.drdos.net/quicknote/32mb_ems.htm
I'll have a look at it, thanks.

                                   Thanks,
                                       Luca

_________________________________________________________________
Chat with friends online, try MSN Messenger: http://messenger.msn.com