Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!wuarchive!uunet!math.fu-berlin.de!unido!rwthinf!slcdec!hippo!f1.n6000.z2.fidonet.org!f340.n632.z3.fidonet.org!John_Morey From: John_Morey@f340.n632.z3.fidonet.org (John Morey) Newsgroups: comp.windows.ms.programmer Subject: Tsr problems Message-ID: Date: 29 May 91 16:08:00 GMT Reply-To: John_Morey%f340.n632.z3@hippo.dfv.rwth-aachen.de (John Morey) Organization: D'Bridge Support/Australia Lines: 54 Comment-To: All@f1.n6000.z2.fidonet.org (All) 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?