I'm looking to do some changes to the wine vdm - or more accurately to the winedos dll to make the handling for some DOS applications more useful. This is mainly driven from a desire to run DOS apps without a wineconsole, so using the unix stdin/stdout/stderr as the DOS file handles. i.e. ala the BSD doscmd program; mind it also has similar issues (plus I'd have to port it :)
There are a few things I'll have to alter wrt to the existing console handling (within winedos), but the main part will be using the JFT within the PSP/PDB and creating SFTs. i.e. in effect fleshing out dlls/kernel/file.c:dos_handles to be a pseudo-SFT. I think I've figured out more or less where I need to hack^h^h^h^hcode.
Looking at what's done at the moment, I see the above two functions being used. Now really, what I'd like to have available is Win32HandleToDosSFT and DosSFTToWin32Handle; so I'll have to create something along those lines.
So a few questions :
a) Is the behaviour of the above two functions correct? i.e. should they be DosFileHandle <-> Win32Handle conversion routines? Or is this just an artifact of how the DOS file handles are currently implemented? b) Do any real apps (that anyone knows of) depend upon calling them?
I do see that they are used in a number of places for the existing 16 bit routines.
If the behaviour is correct, then I guess I'll have to adjust them so that they involve a lookup of the current PSP/PDB and hence indirect through the JFT.
Does anyone know if there is already a defined set of functions for SFT handling at the NT abstraction level? I'd have expected that the NT vdm would have used it if such was available.
DF
Derek Fawcus wrote:
not sure what you're exactly trying to achieve. why do you need this ? do you really have programs peeking inside the JFT/SFT structures ?
A+
On Fri, Jan 27, 2006 at 09:24:13PM +0100, Eric Pouech wrote:
It's not the peeking, it's to make some other emulation more accurate.
I don't anticipate making the SFT look like the DOS SFT, or even having it visible to the DOS/win16 program. It'll be an abstraction within the VDM which is equivalent to a SFT.
At the moment, if program 1 opens a file, execs program 2 and then program 2 closes the file, program 1 will no longer have a valid file handle. Or at least that's how I read the code, since there does not seem to be any increment of a reference count across the DOS int 21/4b.
I suppose one could do something in the VDM process to mark the file handles as having multiple references, and then do proper open / close handling. But that would require a valid JFT anyway.
So th JFT gives a way to update a reference count in the SFT.
Another place where I think it'll come in handy is for redirection, where it'll allow for stashing an equivalent of the device info word. I think this'll make some of the console handling a bit better.
So at the moment, I'm thinking of something like:
struct pseudo_SFT { WORD refcnt; HANDLE win32_file_handle; WORD device_info_word; };
There are also othe bits of the int21.c code which could be simplified if the above existed (possibly by adding more fields).
DF
yes, what's currently missing is the JFT layer... one can consider that the Win32HandleToDosHandle (and its friends) to handle the SFT, and allow to bridge between the DOS world and the Win32 world.
So th JFT gives a way to update a reference count in the SFT.
but, you'll have to patch every possible file usage in winedos so that you don't mixup sft indexes and jft indexes...
you mean regarding the char / block caps for example? not sure we need to store that in the SFT, we can get it back from the win32 handle anyway.
A+
On Sat, Jan 28, 2006 at 10:52:26AM +0100, Eric Pouech wrote:
What I'm suggesting is that as soon as there is a JFT, and we have to store a reference count outside the JFT, then the place we store it is an equivalent to the SFT.
I know :-( But the majority of it will be where Win32HandleToDosFileHandle is called - i.e. the FCB code, as for a lot of the rest the existing code using DosFileHandleToWin32Handle _could_ be retained.
Yup. Since it could (also) be used to revector some routines on a per file type basis - i.e. move the special case code that currently exists out of the common path.
not sure we need to store that in the SFT, we can get it back from the win32 handle anyway.
Well with a round trip. But the 'inherit file handle' bit is one that DOS stores in the device info word. We'd really need to store the same bit. At which point the rest of the word is available for use.
DF
Derek Fawcus wrote:
that's true from the winedos point of view, but that's used from some other places as well (krnl386.exe for example), where you should also know if a FILE16 is a SFT or a JFT handle... IMO, what could be easily done is: - a FILE16 is a SFT index - a DOS fd is a JFT index - the Win32Handle... functions manipulate SFT indexes... however, this will work as long as a 16 bit program doesn't open a FILE16 handle an pass it down to DOS function, which some of them may do. therefore, I'd suggest before further testing on this to make all SFT and JFT indexes equal A+
-
Derek Fawcus -
Eric Pouech