home *** CD-ROM | disk | FTP | other *** search
/ CD Actual 15 / CDACTUAL15.iso / cdactual / program / pascal / PASTRANS.ZIP / READ.ME < prev    next >
Encoding:
Text File  |  1991-03-19  |  10.0 KB  |  244 lines
  1. Dear User:
  2.  
  3. The substance of the computer bulletin board messages below is that
  4. there are problems in passing far FILE pointers to child processes under
  5. many otherwise respectable DOS C compilers.  So, your `external'
  6. procedures and functions may work fine, as long as they don't do stream
  7. I/O, or as long as they only do so from a MEDIUMP (medium model)
  8. interpreter.  The reason for this problem is that most C compilers
  9. insert their own local file tables into their compiled programs.  So, C
  10. programs check their local file tables before doing I/O, and a child C
  11. process will fail to discover files opened in a parent process when it
  12. searches its local file tables. 
  13.  
  14. The solution to this problem, linking the C compiler's libraries into
  15. the interpreter, and altering the interpreter to trap all calls to
  16. "external" C procedures and functions and call them locally in
  17. iosystem(), is illegal.  It is illegal for me to compile such an
  18. interpreter and distribute it, because C compilers' libraries are
  19. copyright.  If you, however, alter assemble.c and/or iosystem.c to do
  20. this, and abide by the copyright restrictions (your personal use only),
  21. then it is legal to use your C compilers' libraries directly in your
  22. Pascal programs. 
  23.  
  24. A future version of the system, expected to be released in mid-to-late
  25. 1991, will be compatible with other microcomputer versions of Pascal
  26. (while retaining ISO compatibility with a command-line switch), and it
  27. will feature a large library of Turbo Pascal (TM) functions implemented
  28. in C.
  29.  
  30. Still later versions of the system will run under Windows 3 (TM) and
  31. will include objects.
  32.  
  33. ==============================================================================
  34.  
  35. Date: 10-04-90 (04:31)              Number: 13446 of 13897 (Echo)
  36.   To: VICTOR SCHNEIDER              Refer#: NONE
  37. From: BJORN KAARIGSTAD                Read: 10-06-90 (01:26) HAS Reply/Replies
  38. Subj: PORTABLE OVERLAYS IN C        Status: PUBLIC MESSAGE
  39. Conf: C-LANG (70)                Read Type: MAIL FOR YOU (+)
  40.  
  41. VS> dynamically loads overlays and then uses them as part of the
  42. VS> parent process, via actual procedure calls and returns.
  43.  
  44. That is a difficult one. Then you have to develop your own dynamic
  45. linker, if I understand you correctly.
  46.  
  47. But if you can use a non-resident solution, you can use spawn and
  48. pass on a filehandle. You can not return one, becouse when the
  49. program terminates normaly, it will close all opened files. At
  50. least that is true with TC.
  51.  
  52. To pass a file from a parent process to a child you could use
  53. something like this:
  54.  
  55. Parent:
  56.  
  57. #include <io.h>
  58. #include <fcntl.h>
  59. #include <process.h>
  60. #include <stdio.h>
  61.  
  62. main()
  63. {
  64.  int handle;
  65.  char chandle[10];
  66.  char *dummy="path";
  67.  if((handle=open("child.c",O_RDONLY))==-1)
  68.    return 1;
  69.  itoa(handle,chandle,10);
  70.  spawnl(P_WAIT,"child.exe",dummy,chandle,NULL);
  71.  close(handle);
  72. }
  73. -------------------------------------
  74. Child:
  75. -------------------------------------
  76.  
  77. #include <io.h>
  78. #include <fcntl.h>
  79. #include <stdio.h>
  80.  
  81. main(int argc,char *argv[])
  82. {
  83.   int handle;
  84.   FILE *in;
  85.   char buf[500];
  86.   handle=atoi(argv[1]);
  87.   fdopen(handle,"rb");
  88.   fread(buf,1,500,in);
  89.   printf("%d\n%s",handle,buf);
  90.   return 0;
  91. }
  92.  
  93. -> MegaMail v2.01 #0:
  94. ---
  95.  ■ QNet 2.04: Interlink: Southboard ■ Lyngdal ■ Norway ■ 043-43880 HST 4 lines
  96.  
  97. Date: 10-06-90 (21:05)              Number: 13566 of 13897 (Echo)
  98.   To: VICTOR SCHNEIDER              Refer#: NONE
  99. From: DAVE SIEGEL                     Read: 10-08-90 (04:28) HAS Reply/Replies
  100. Subj: PORTABLE OVERLAYS IN C        Status: PUBLIC MESSAGE
  101. Conf: C-LANG (70)                Read Type: MAIL FOR YOU (+)
  102.  
  103. VS>Does anyone out there have any words of advice about this?
  104.  
  105. This can't be done within the ANSI framework.  Protected mode systems
  106. generally require OS intervention to turn data into code (OS/2, for
  107. example, has a call to create a code segment alias for a data segment).
  108. Since this stuff is absolutely system specific, ANSI stayed as far away
  109. from it as possible.
  110.  
  111. Why not use the linker to set up overlays?  Borland, and to a rather
  112. lesser extent Microsoft, support overlays in a straight-forward fashion.
  113.  
  114. -dms
  115. ---
  116.  ■ EZ-Reader 1.21 ■
  117.  ■ QNet 2.04: InterLink: ■ Thunder Road BBS ■ NY, NY ■ (718) 392-8836 HST
  118.  
  119. Date: 10-08-90 (15:38)              Number: 13650 of 13897 (Echo)
  120.   To: VICTOR SCHNEIDER              Refer#: NONE
  121. From: ALAN BARCLAY                    Read: 10-09-90 (13:33) HAS Reply/Replies
  122. Subj: PORTABLE OVERLAYS IN C        Status: PUBLIC MESSAGE
  123. Conf: C-LANG (70)                Read Type: MAIL FOR YOU (+)
  124.  
  125. VS>Although it looks plausible on paper, C has very few ANSI supported
  126. VS>mechanisms for doing this.  "system()" and "spawnl()" work to load
  127. VS>non-resident child processes, but interesting things like opening a
  128. VS>file and returning a valid pointer to the parent process or sending
  129. VS>a file pointer from parent to child and having the child perform
  130. VS>I/O are completely impossible under, say, DOS, and the idea that
  131. VS>anyone might want to do this apparently didn't cross the C gurus'
  132. VS>minds.
  133.  
  134. The reason that K&R and ANSI didn't do anything like this is because
  135. swapping & virtual memory is really the concern of the operating system
  136. and the programmer should never ever need to do this. However DOS doesn't
  137. and we have to.....
  138.  
  139. ■ Created on 10-07-90 at 5:03pm
  140. ---
  141.  ■ DeLuxe² #36sa ■ * UNIX is a Trademark of Bell Laboratories.
  142. QNet 2.04: Interlink:■Edinburgh Castle ■ Scotland ■ +44 (31) 334 7043
  143.  
  144. Date: 10-08-90 (00:27)              Number: 13658 of 13897 (Echo)
  145.   To: VICTOR SCHNEIDER              Refer#: NONE
  146. From: BJORN KAARIGSTAD                Read: 10-09-90 (02:26) HAS Reply/Replies
  147. Subj: PORTABLE OVERLAYS IN C        Status: PUBLIC MESSAGE
  148. Conf: C-LANG (70)                Read Type: MAIL FOR YOU (+)
  149.  
  150. Hi Victor,
  151. I must say that I have not tested on the stream functions, but I
  152. failto see why they should not work. I my last reply I was passing
  153. the file handle, and then you have to use the fdopen to make it a
  154. stream. If however you pass the pointer you MUST use a memorymodel
  155. that uses FAR pointers. If not you may suffer the failure you
  156. describe. It is not enough to override on the FILE pointer itself,
  157. becouse that will not have any effect on the internal pointers in
  158. the FILE structure. So you end up  with a far pointer to the FILE
  159. struct, but a near pointer to the buffer.
  160.  
  161. I stress this point couse I suspect you (as I know I would) want to
  162. have your routines in a .com file and therby uses the tiny model.
  163.  
  164. Please let me know if you find a useable solution, becouse I'm
  165. planning a project where I might need something like this.
  166.  
  167. B.I.Kaarigstad...
  168.  
  169. -> MegaMail v2.01 #0:
  170. ---
  171.  ■ QNet 2.04: Interlink: Southboard ■ Lyngdal ■ Norway ■ 043-43880 HST 4 lines
  172.  
  173. 10-09-90 (21:43)              Number: 13780 of 13897 (Echo)
  174.   To: VICTOR SCHNEIDER              Refer#: NONE
  175. From: RALPH GOERS                     Read: 10-10-90 (16:25) HAS Reply/Replies
  176. Subj: PORTABLE OVERLAYS IN C        Status: PUBLIC MESSAGE
  177. Conf: C-LANG (70)                Read Type: MAIL FOR YOU (+)
  178.  
  179. VS>Thanks for your astute reply.  I am implementing a somewhat portable
  180. VS>Pascal interpreter with and EXTERNAL procedure/function declaration
  181. VS>capability.  And, I was hoping to find a reasonable way to call a
  182. VS>program that passes back a pointer to a requested library procedure/
  183. VS>function.  I assumed that, since it was possible to actually link in
  184. VS>such a program in OS/2 and even DOS, that other systems might have
  185. VS>comparable facilities.
  186.  
  187. If I understand you correctly, we are doing something similar (in MVS).
  188. They are not called overlays though, since they don't overlay the
  189. original load module, they are just additionally loaded modules. As
  190. a matter of fact I think what you are describing is just a DLL in OS/2.
  191.  
  192. Ralph
  193. ---
  194.  ■ EZ 1.30 ■
  195.  ■ RNet 1.05L:You Bet Your Ascii ■ Van Nuys ■ CA
  196.  
  197. Date: 10-10-90 (15:55)              Number: 13795 of 13897 (Echo)
  198.   To: VICTOR SCHNEIDER              Refer#: NONE
  199. From: DAVID FOX                       Read: 10-12-90 (02:54) HAS Reply/Replies
  200. Subj: PORTABLE OVERLAYS IN C        Status: PUBLIC MESSAGE
  201. Conf: C-LANG (70)                Read Type: MAIL FOR YOU (+)
  202.  
  203.                      ══════╡Wednesday, 10 October╞══════
  204.  
  205. VS┤Thanks very much for your replies.  I have just about exhausted the
  206.   │possibilities.  The major point is that, in C, the FILE pointer alone
  207.   │does not have enough information to specify everything needed to do
  208.   │i/o.  And, my overlays are all large-model, not com-file code. This
  209.  
  210. I don't follow you here.
  211.  
  212. I've always assumed that FILE * had an adequate definition for all
  213. types of stream i/o (fread,fwrite, etc.) and I've not had problems
  214. with the 'default' definition of the FILE structure in <stdio.h>
  215. under MSC.
  216.  
  217. Are you using FILE * stream i/o to load/execute child processes?
  218.  
  219. If so, why?  What's wrong with the spawn.. class of procedures?
  220. ---
  221.  ■ EZ 1.33 ■ Internal Stack Failure: Plates Broken
  222.  ■ RNet 1.05M:Interlink ■ Higher Powered BBS ■ Sunnyvale CA ■ 408-737-9447
  223.  
  224. Date: 10-13-90 (04:54)              Number: 13878 of 13897 (Echo)
  225.   To: VICTOR SCHNEIDER              Refer#: NONE
  226. From: JOEY LIZZI                      Read: 10-13-90 (22:01)
  227. Subj: PORTABLE OVERLAYS IN C        Status: PUBLIC MESSAGE
  228. Conf: C-LANG (70)                Read Type: MAIL FOR YOU (+)
  229.  
  230. ╞═╡I saw your public message on portable overlays, a subject I am
  231. ╞═╡very interested in right now.  Can you tell me where POVR or POVRL
  232. ╞═╡is available?  And, can you pass a file pointer to an overlay and
  233. ╞═╡have the overlay do i/o on it?
  234.  
  235.    POVR is a shareware program on BBSes. POVRL is the commercial version, I
  236. think. The overlay should be able to work with current file pointers,
  237. arrays, etc. Just remember that POVR needs a LINK or LINK-compatible .OBJ
  238. file linker. These are used in all MS languages and in Turbo C/C++.
  239.  
  240.                                  ⌡ΘΣÿ
  241. ---
  242.  ■ EZ 1·33 ■ PC RAID -- Kills Program Bugs DEAD!!
  243.  ■ QNet 2.04: InterLink:  Compu-Data ■ Turnersville ■ NJ ■ (609) 232-1245
  244.