home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #30 / NN_1992_30.iso / spool / comp / os / mswindo / programm / misc / 4207 < prev    next >
Encoding:
Text File  |  1992-12-14  |  2.8 KB  |  58 lines
  1. Organization: Carnegie Mellon, Pittsburgh, PA
  2. Path: sparky!uunet!cis.ohio-state.edu!news.sei.cmu.edu!fs7.ece.cmu.edu!crabapple.srv.cs.cmu.edu!andrew.cmu.edu!ak10+
  3. Newsgroups: comp.os.ms-windows.programmer.misc
  4. Message-ID: <wf=Fjj_00WB8QZoUYr@andrew.cmu.edu>
  5. Date: Mon, 14 Dec 1992 18:42:39 -0500 
  6. From: Andrew Joseph Kompanek <ak10+@andrew.cmu.edu>
  7. Subject: Segmented Memory Woes and Portability
  8. Lines: 48
  9.  
  10.  
  11. I recently started porting some data structure libraries I wrote on Unix
  12. to the PC under Windows 3.1.  I'm using Borland C++ 3.1.
  13.  
  14. I naively assumed that all of the segmented memory issues would be
  15. more or less transparent to me and that the compiler would take care
  16. of pointer conversions, alignment problems, etc.  I figured if I
  17. compiled my code with the Compact option, my pointer declarations
  18. would be interpreted as far pointers and that I could address within a
  19. 1 Mb address space without changing a bit of my code.  This doesn't
  20. _seem_ to work, though I just started and still don't know very much
  21. about the 80x86.
  22.  
  23. So, if this doesn't work, what is the best way to write code portable to
  24. 80x86 architectures -- both under DOS and in Windows programs and DLLs?
  25.  
  26. I realize with a little research and a lot of #ifdefs I could write some
  27. portable code but it would be extremely useful to be able to hide the
  28. PC-specific code from the programmer using malloc().  Has somebody put
  29. some sort of library together?
  30.  
  31. Alternatively, is it possible to simply call GlobalAlloc() or whatever
  32. the function is to allocate memory from Windows global heap, convert the handle
  33. to a far/huge pointer (the pointer declarations somehow declared this way
  34. implicitly), lock the memory then when you're done with it, convert the
  35. pointer back to a handle, unlock and free it?  This seems like sensible
  36. behavior -- assuming that this doesn't force Windows to keep in memory
  37. stuff that should it should be able to move and swap in/out.
  38.  
  39. As a programmer, it doesn't seem like I should have to deal with the
  40. quirks of the processor I'm running on...
  41.  
  42. My understanding of the 386/486 is that it has better support for virtual
  43. memory management and that its virtual 32-bit pointers look like contiguous,
  44. unmoving addressable memory.  Is there a way to do this in Borland C++ 3.1?
  45. Judging from some of the other posts about memory management, it seems that
  46. a lot of people might benefit from discussing some of the stuff I've
  47. brought up.  If this is FAQ material, I'm sorry for clogging network
  48. bandwith with this message.
  49.  
  50. Drew
  51.  
  52.  
  53. ------------------------------------------------------------------------------
  54. Andrew Kompanek                        e-mail: drew@chimera.hgen.pitt.edu,
  55. Department of Human Genetics                  ak10@andrew.cmu.edu,
  56. University of Pittsburgh                      kompanek@cs.cmu.edu
  57. ------------------------------------------------------------------------------
  58.