home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #16 / NN_1992_16.iso / spool / comp / os / msdos / programm / 8057 < prev    next >
Encoding:
Text File  |  1992-07-25  |  1.5 KB  |  29 lines
  1. Newsgroups: comp.os.msdos.programmer
  2. Path: sparky!uunet!wupost!usc!zaphod.mps.ohio-state.edu!rpi!batcomputer!lynx.msc.cornell.edu!boris
  3. From: boris@msc.cornell.edu (Boris Yost)
  4. Subject: BC++2.0 vs. National GPIB:  Who's on DS?!?
  5. Message-ID: <1992Jul24.181425.12478@msc.cornell.edu>
  6. Sender: news@msc.cornell.edu
  7. Organization: Cornell-Materials-Science-Center
  8. Date: Fri, 24 Jul 1992 18:14:25 GMT
  9. Lines: 18
  10.  
  11. I'm writing a data acquisition/machine control application using BC and
  12. National GPIB using National's software library, huge model.  Ran into a
  13. most curious bug:  one of my constant strings came out with snot in the
  14. middle of it.  Worked fine before--until I split the source file in two for
  15. easier handling.  Reason:  TD reveals that one of my GPIB functions is
  16. stomping on it, and the reason for that is that the data segment for the
  17. GPIB functions is getting merged with the data segment for main(), but the
  18. calls are from another module, and DS is set for the data segment for that
  19. module.  I'm following directions (don't tell me to RTFM) that came with it,
  20. which said the large library works with the huge model--or maybe Borland
  21. changed how their huge model works.  Calls work fine if I change DS to
  22. main's DS immediately before each 'call far _function' and then change back
  23. on return, or if I cram all the source into one module (which is almost too
  24. big a meal for the compiler).  
  25.  
  26. So, how do I either get the linker to merge the data segment with the one
  27. that calls all the functions (there is only one), or fix it for real--so
  28. that any module could call the GPIB.
  29.