home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #31 / NN_1992_31.iso / spool / comp / lang / pascal / 7708 < prev    next >
Encoding:
Text File  |  1992-12-29  |  2.2 KB  |  49 lines
  1. Newsgroups: comp.lang.pascal
  2. Path: sparky!uunet!spool.mu.edu!torn!news.ccs.queensu.ca!slip205.telnet1.QueensU.CA!dmurdoch
  3. From: dmurdoch@mast.queensu.ca (Duncan Murdoch)
  4. Subject: Re: Distributing TPUs
  5. Message-ID: <dmurdoch.254.725594757@mast.queensu.ca>
  6. Lines: 37
  7. Sender: news@knot.ccs.queensu.ca (Netnews control)
  8. Organization: Queen's University
  9. References: <1992Dec27.022633.14853@beaver.cs.washington.edu> <765338d8368876t211@witsend.uucp>
  10. Date: Tue, 29 Dec 1992 02:05:57 GMT
  11.  
  12. In article <765338d8368876t211@witsend.uucp> "D. C. Sessions" <dcs@witsend.tnet.com> writes:
  13. >In <1992Dec27.022633.14853@beaver.cs.washington.edu>, andrewb@lynx.cs.washington.edu (Andrew Berg)  wrote:
  14. ># 
  15. ># Does anyone know what the motivation for not ever having any backward com-
  16. ># patibility between any of the TPU formats?  It seems like it would be a useful
  17. ># thing.
  18.  
  19. It's a trade-off.  .TPU files contain some optimizations that make compiling 
  20. and linking go much faster than it could with .OBJ files; these mean upward 
  21. compatibility is essentially impossible.
  22.  
  23. >  A while back I asked whether anyone had cooked up a TPU converter.
  24. >  Seems like the sort of thing that might even be useful, don't it?
  25. >
  26. >  Well, folk?
  27.  
  28. I'd suspect that conversion among TP 6/TPW 1.0/TPW 1.5 would be possible, as 
  29. would conversion among the various BP 7 types, because there are only 2 
  30. formats involved.  I think the formats are close enough that it would even 
  31. be feasible to convert between the two types, certainly from BP 7 backwards 
  32. if not TP 6 forwards.
  33.  
  34. But:  It would be a lot of work.  It's not something that would be 
  35. very interesting, and it's not something that would make anyone any money.  
  36. It solves a problem that doesn't exist for most people, since the 
  37. alternative of keeping source code to all third party units is pretty much 
  38. standard practice.  It's not certain to succeed, since there may be changes 
  39. to the RTL between versions that just can't be converted (e.g. the heap 
  40. manager changes frequently; code that works closely with it needs rewriting, 
  41. not just recompiling).
  42.  
  43. I've been tempted to try it sometimes, but the problems above have held me 
  44. back.  I'd be happy to give advice to anyone who wants to give it a try, 
  45. though.
  46.  
  47. Duncan Murdoch
  48. dmurdoch@mast.queensu.ca
  49.