Mail Archives: djgpp/1997/11/27/10:31:17
On Thu, 27 Nov 1997 13:12:03 +0100 in comp.os.msdos.djgpp Michael Mauch <michael DOT mauch AT gmx DOT de> wrote:
: > I don't suppose this is that significant since
: > our timing resolution is milliseconds, though.
: Yes, but I think it is significant for the 840 nanoseconds timer
: (function 0x100 of the VTD API). And there are no drawbacks with your
: direct method, are there any? Are there any chances that the VTD code
: gets paged out sometimes (I don't think so), so that the lcall could
: fail?
Yes, I think without a doubt that it must be significant on the 840ns
timer. One of the test programs in that ZIP attempts to estimate the
overhead in calling the function; it gets about 15 timer ticks on my
machine, and that shouldn't even involve a mode switch to call.
Presumably with a mode switch it would hit the roof... ;)
Re: the VTD code being paged out, isn't that Windows' problem? I
don't know a great deal about this though; I wasn't aware that an
lcall would fail (I would have expected it to just take a while, while
the relevant memory block is paged in again).
: > it didn't work quite properly for the registry access VxD
: > though. [The calls worked fine, and valid error codes were returned;
: > I just couldn't pass parameters to it properly.]
: But I guess you would have had the same problems if you had used the
: DPMI way, wouldn't you?
Not quite. I didn't really have any documentation for thix VxD; my
tinkering was based solely upon looking at Alfons Hoogervorst's
Dossock code, which uses it, and looking briefly at the O'Reilly book
on the registry (which said exactly what Alfons' code said really).
The Dossock was written for 16-bit real mode compilers, running under
Win95.
Getting the entry point in protected mode (using `int') and calling it
directly (with `lcall') consistently gave me error 87 (bad parameter
format or something like that). I assumed that Win95 was
interpretting my pointers (pushed to the stack) in a way I didn't
understand. Even using linear physical addresses, or segment:offset
addresses, of DOS memory blocks failed to work. One thing I
particularly didn't know was whether I should use a 16-bit or 32-bit
push when giving my DS. Neither worked though ;).
Getting the entry point via a DPMI hook, as you did in your earlier
post, and calling it with a simulated real-mode call gave different
errors which I've forgotten right now. I used conventional memory for
the parameters exclusively, and tried both making my own stack and
using the __dpmi_simulate_real_mode_procedure_retf_stack function to
make one for me, to no avail. It's silly, really -- the real mode
version should work if I dedicate myself to it, since I have template
real-mode code to access it, and so I know how to push the pointers :).
So the point is, Windows seems to know whether I called it from
protected mode or real mode, and interprets the stack differently in
each case. AFAICS -- I could be wrong.
: Yes, thank you, it works fine here on Win95 and WfW3.11. vtd_init()
: fails without problems on plain DOS 7, just like it is supposed to do.
Oh, so this works in older Windows versions too? I didn't know that :).
--
Regards,
george DOT foot AT merton DOT oxford DOT ac DOT uk
- Raw text -