home *** CD-ROM | disk | FTP | other *** search
/ The World of Computer Software / World_Of_Computer_Software-02-385-Vol-1of3.iso / p / prbgi097.zip / C.ZIP / HUGE.NOT < prev    next >
Text File  |  1992-12-15  |  3KB  |  58 lines
  1.                A special note for BC++ 2.0 users.
  2.  
  3.    I encountered some difficulties using this PrintBGI package in huge
  4. memory model with BC++ 2.0. The program behaved very strangely in some
  5. rare but unpredictable situations. After few days of debugging sessions I
  6. narrowed the problem but couldn't eliminate it. So what happens?
  7.  
  8.    The problem is strongly related to coprocessor emulation.
  9. Since I don't have sources of Borland's coprocessor emulation
  10. routines all what I'm writing here is only my speculation
  11. and may be not necessarily the truth.
  12.  
  13.    The coprocessor emulation routines use some space for saving their
  14. variables and to emulate the stack of coprocessor. Since in huge memory
  15. model all user or library functions use DS register for their own purposes
  16. the emulator must either save it, use as it wants and restore or set ES
  17. register and use it to access it's working space. Isn't this right? It isn't.
  18. It uses the third method. Addresses it's working space using SS register.
  19. Simply it uses the bottom of the stack. The start of the stack has even
  20. an external label called _emu. I will refer to emulation working space as
  21. a _emu variable.
  22.  
  23.    Now let's look at the Turbo debugger CPU window. After we execute
  24. Go to e086_Entry command we may see something like that
  25.    xxxx:xxxx e086_Entry: sti
  26.                          cld
  27.                          push  AX
  28.                          ....  some other push statements
  29.                          mov   BP,SP
  30.                          mov   SS:[032h],BP
  31.                          ....  other code
  32.    Let's look at the statement mov SS:[032h],BP. In this statement emulator
  33. saves BP register in it's working space. But not in the code of my BGIDEMO 
  34. generated for huge model by BC++ 2.0. In that case instead of   mov 
  35. SS:[032h],BP 
  36. you may see  mov SS:[1EC2h],BP.
  37.    Why it happens?
  38.    It seems that linker  resolves all references to _emu variable assuming
  39. it is in the data segment not in the stack segment. Maybe it finds somewhere
  40. a GROUP directive grouping Start up data segment and the stack together?
  41.  
  42.    So I get wrong results from linking process and have no idea how can I
  43. correct it. It is not simply a bug in BC++ 2.0 since all small testing
  44. programs I wrote were linked correct. 
  45. Note also that there is only one version of emulation library used for
  46. all memory model. It links O.K. in large model (independently of compiler
  47. version) with my program. It also links O.K. in BC++ 3.0. The only one wrong
  48. case is huge model, BC++ 2.0 (I have no idea about earlier compilers), and
  49. my program. I even compiled it entirely in huge memory model and the results
  50. were the same. I suppose the problem is related with GROUP concepts.
  51. But I don't use GROUP directive explicitly in any of my modules.
  52. So I assume it is in one of standard LIB files but I'm not sure about it.
  53.  
  54.    I'm not so experienced with PC's to know what to do. If you have any ideas
  55. which may help let me know of them.
  56.                                       Thanks.
  57.  
  58.