From: George Foot Newsgroups: comp.os.msdos.djgpp Subject: Re: Intermittent Run-Time of DJGPP App under Win95 Date: 27 Nov 1997 12:38:38 GMT Organization: Oxford University, England Lines: 67 Message-ID: <65jpke$rn6$1@news.ox.ac.uk> References: <348488fe DOT 61835728 AT news DOT uni-duisburg DOT de> <65hssl$h8s$1 AT news DOT ox DOT ac DOT uk> <34833aa9 DOT 7560146 AT news DOT uni-duisburg DOT de> NNTP-Posting-Host: sable.ox.ac.uk To: djgpp AT delorie DOT com DJ-Gateway: from newsgroup comp.os.msdos.djgpp Precedence: bulk On Thu, 27 Nov 1997 13:12:03 +0100 in comp.os.msdos.djgpp Michael Mauch 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