John_Morey@f340.n632.z3.fidonet.org (John Morey) (05/29/91)
Help
For the past two years we have been developing a turbo machinery monitoring
product running under windows 3.0. We are nearing the end of this project and
are having major difficulties trying to fit it all into the 640K DOS limit. We
have decided that the only way to get passable performance out of the product
will be to run it in standard or enhanced mode.
Part of the product uses ADC boards and software, supplied by a third party.
The software is in the form of a TSR and while this will run under windows in
real mode it will not run in standard or enhanced modes.
We can't get a copy of the source code from this third party and their help is
very limited. We are writing this in the hope that someone has had to solve a
similar problem or has some suggestions on how to solve this.
The TSR patches into interrupt vector 60h and is called by pushing the
appropriate parameters onto the stack and then invoking the interrupt.
When we use the TSR in enhanced mode it appears to perform properly but does
not return the correct answers. We think this is something to do with the
different addressing modes ie segment:offset vs selector:offset but it is
difficult to tell. We have done tests which prove the TSR is actually called
and at the correct location. Also once we return back to DOS the TSR is
corrupted in some way and won't give the right answers there either, and it has
to be reinstalled.
When we run a DOS program under windows in enhanced mode it can communicate
with the TSR and get the correct answers. The problem then becomes how to talk
between the DOS program and windows. We need a combined buffer for
communication between the two programs of about 128K.
We tried GlobalDosAlloc which we noticed in other messages but this doesn't
appear to function correctly in standard / enhanced mode. We are going to try
blocking out an area of memory from windows and using this.
If anyone can answer the following questions or provide any information on this
topic at all please send us a message.
1) Is it possible to get the physical location of a piece
of GlobalAlloc'ed memory in standard or enhanced mode?
2) Does GlobalDosAlloc work in standard or enhanced mode and how?
3) Is there a bug in this GlobalDosAlloc function ?
4) Where is a safe area of memory to block out and how can
we create a selector to point to it?
5) What is DPMI and where can we get more information on it?
6) Any suggestions on how we can solve this problem?Chris_Graham@f344.n632.z3.fidonet.org (Chris Graham) (06/01/91)
* Original <29 May 91 17:08:00> was from John Morey to All > JM: Part of the product uses ADC boards and software, supplied > JM: by a third party. The software is in the form of a TSR and > JM: while this will run under windows in real mode it will not run > JM: in standard or enhanced modes. Whose ADC board? > JM: The TSR patches into interrupt vector 60h and is called by > JM: pushing the appropriate parameters onto the stack and then invoking > JM: the interrupt. Ints 60-67h are defines as user ints, except 67h has been used by EMS. So they have done the correct thing here. > JM: > JM: When we use the TSR in enhanced mode it appears to perform > JM: properly but does not return the correct answers. We think This is correct. The TSR is being called, but it is still in protected mode, so all of the segment registers have selectors not physical segments in them. Only the TSR ( some of mine included ) don't know when they are being called in protected mode. > JM: 5) What is DPMI and where can we get more information > JM: on it? Ask MS or Intel ( yes Intel ), you should be able to get a copy of the 0.90 Beta spec for the Dos Protected Mode Interface. > JM: 6) Any suggestions on how we can solve this problem? Write another TSR that can detect if it being called in a protected mode, switch back to real mode, call the TSR and then pop back and return to windows. Filthy I know but... Another suggestion is to have a look through the DDK ( Device Drive Kit ), I think they have had to do some real nasty stuff there. Filthiest thought: Write a device drive for dos, and read/write to it ( set it up as a character device ). It _HAS_ to be called in real mode! Well you did ask... Give my board a ring on 384-1060 ( 9 am - 5 pm MON - FRI ) and we'll see what we can do. -Chris
Joachim_Kainz@p11.f11.n310.z2.fidonet.org (Joachim Kainz) (06/03/91)
> [..] suggestion is to have a look through the DDK ( Device Drive Kit [..]
Be careful with the beast!Norbert_Unterberg@p4.f36.n245.z2.fidonet.org (Norbert Unterberg) (06/04/91)
> If anyone can answer the following questions or provide any information > on this topic at all please send us a message. > > 1) Is it possible to get the physical location of a piece > of GlobalAlloc'ed memory in standard or enhanced mode? Yes. But this won't help you much, because Windows allocates the global memory from an area above 1 MB. So the linear address will be a number > 100000h and is not accessible from your real mode TSR. > 2) Does GlobalDosAlloc work in standard or enhanced mode and how? This function is specially designed for protected mode applications. However, it also works in real mode. It allocates memory below the 1 MB `fence' and returns both the _segement address_ and the _selector_ of that memory. Use the selector in your windows application, and pass the segment address for the TSR. So for Windows the memory beginns at the address LOWORD(return value):0, the TSR will sees the same memory at HIWORD(return value):0 > 3) Is there a bug in this GlobalDosAlloc function ? I don't know, why do you think? > 4) Where is a safe area of memory to block out and how can > we create a selector to point to it? Don't do it that way. Use the GlobalDosAlloc or some DPMI functions for that, but do not try to work around Windows' memory management. To create a selector from a segement address, the DPMI provides the neccesary functions. > 5) What is DPMI and where can we get more information on it? DPMI is the `Dos Protected Mode Interface'. It ia a specification/programming interface for protected mode programs and dos extenders, which provides an interface between protected mode programs and real mode (dos) applications, and is implemented in Windows 3.0 enhanced mode. It provides function calls from Local Descriptor Table management (allocate/free selector, get segment base address etc.) up to interrupt services and communication with TSRs (simulate real mode interrupt, call real mode procedure with far return/iret frame etc.). If you are doing `low level things', hardware interrupts, memory mapped i/o, you need the DPMI. A free(!) copy of the specification is available at Intel. Contact Intel in Australia(?) and ask for a copy. The Intel Order Number is 240736-001. > 6) Any suggestions on how we can solve this problem? DPMI. See above. Hope I could help, Norbert