home *** CD-ROM | disk | FTP | other *** search
/ DP Tool Club 15 / CD_ASCQ_15_070894.iso / vrac / watcom.zip / WATCOM.CAP < prev    next >
Text File  |  1994-03-04  |  220KB  |  6,462 lines
  1.  
  2. From:    Bob Trabucco                           Rec'd
  3. To:      Kevin Kitsemetry                       Msg #2324, Feb-01-94 10:25AM
  4. Subject: Spawning and memory
  5.  
  6. Thanks for the response...
  7.  
  8. Unfortionatly the powers that be insist that I need no special memory managers
  9. that don't come with dos.  I will try to play with EMM386 so more.  We did
  10. order the TNT dos extender and I have been given 2 days to see if it helps,
  11. I hope so...  Boy it's difficult explaining some problems to non-computer
  12. people (like marketing departments)
  13.  
  14. *** This is a reply to #2315.
  15.  
  16.  
  17. From:    Johann Walter
  18. To:      Kevin Kitsemetry                       Msg #2326, Feb-01-94 02:41PM
  19. Subject: VFW 1.1
  20.  
  21.   Any chance that the B level patch will be out soon?  We are nearing shipping
  22. for our product and I need to know if the level B patch will fix the problems
  23. I'm having with VFW1.1.
  24.  
  25.  
  26. *** This is a reply to #2251.
  27.  
  28.  
  29. From:    Patrick Lamb
  30. To:      Kevin Kitsemetry                       Msg #2327, Feb-01-94 06:07PM
  31. Subject: unexpected interrupt
  32.  
  33. I have run into a strange problem with Watcom C32 9.5a.  The problem stops
  34. with the message
  35.     Unexpected interrupt 0D (code 46E80000) at 158:45D41F
  36.     TSF32: prev_tsf32 4F74
  37. and a bunch of register dumps.
  38.  
  39. I tried running the program under the debugger (WVIDEO), and it stops at
  40. (apparently) the same place with the message
  41.     *****TASK EXCEPTION***** PAGE FAULT.
  42. The line it bombs on is
  43.     free( array[i] )
  44. where array has previously been allocated, and array[i] allocated for i<6;
  45. it bombs when i=1 (the second time through a for loop).
  46.  
  47. I'm running with the DOS4GW extender under DOS 6.2 on a 386/20 with 10 Mb
  48. (got kicked off the 486!).
  49.  
  50. What gives?
  51.  
  52. And can't you include more informatio, but I can stand the slow response better
  53. than the bombing.
  54.  
  55.             Pat
  56.  
  57.  
  58. From:    John Lansdale
  59. To:      John Axline                            Msg #2328, Feb-01-94 11:25PM
  60. Subject: C386/NT beta
  61.  
  62.  
  63. *** This is a reply to #844.
  64.  
  65.  
  66. From:    John Lansdale
  67. To:      Technical Support                      Msg #2329, Feb-01-94 11:34PM
  68. Subject: WIN32s + NT DLLs
  69.  
  70. I'm having a small problem running a NT program under win32s. I've created
  71. a 32-bit DLL using th  NT_DLL linker mode and the DOS-based wcc386 compiler.
  72. When I try to use this library in a simple NT-compiled program under win32s
  73. the loader complains that it cannot find a number of DLL support libraries
  74. such as win32spl.dll, etc. Are these included with an updated version of
  75. win32s SDK or must I set some compiler/linker flags for win32s program
  76. generation?
  77.  
  78. John Lansdale
  79.  
  80.  
  81.  
  82. The MESSAGE Section
  83. There are 1676 messages in this area.  The highest is #2562
  84. The last message you read was 2329.
  85.  
  86.  
  87. [2329 / 2562]  Msg.area 12 ... WATCOM C/C++32 9.5 Problems and Fixes
  88.                Type message number, or press <enter> for NEXT msg.
  89.  
  90. MESSAGE:
  91. A)rea Change        N)ext Message       P)revious Message   E)nter Message
  92. R)eply to a messag  C)hange a message   =)read_non-stop     -)read_original
  93. +)read_reply        L)ist (brief)       M)ain Menu          J)ump to file area
  94. G)oodbye (log off)  U)pload a message   F)orward (copy)     B)rowse messages
  95. *)ReadCurrent       T)ag areas          ?)help
  96. Select: =
  97.  
  98.  
  99.  
  100. Message area 12 ... WATCOM C/C++32 9.5 Problems and Fixes
  101.  
  102. From:    Michael Hung                           Rec'd
  103. To:      Kevin Kitsemetry                       Msg #2330, Feb-02-94 04:20PM
  104. Subject: dos4gw crashes
  105.  
  106. I am running QEMM 7.03 and QDPMI 1.03, pminfo reports mode switching
  107. using VCPI instead of DPMI.  When I used QDPMI EXTCHKOFF option,
  108. rminfo reports mode switching using DPMI but pminfo and dos4gw crash
  109. the machine.  I thought this should have been fixed in level a patch.
  110.  
  111. BTW, I am using the level a patched version.  The dos4gw version is 1.92
  112.  
  113. Thanks
  114. Michael
  115.  
  116. *** See also #2331.
  117.  
  118.  
  119. From:    John Lagerquist                        Rec'd
  120. To:      Michael Hung                           Msg #2331, Feb-02-94 07:02PM
  121. Subject: dos4gw crashes
  122.  
  123.  
  124. *** This is a reply to #2330.
  125.  
  126.  
  127. From:    Steve Chiang
  128. To:      All                                    Msg #2332, Feb-02-94 07:34PM
  129. Subject: Dos 4GW
  130.  
  131. I d/l'ed the level A patches, and when it attempted to patch Dos 4gw,
  132. it returned a checksum error.
  133. Now, I think I have a problem due to Dos 4gw... and I want to get an
  134. updated version.  How can I get v1.95 of 4gw.  I'm not sure if I want
  135. to purchase the pro version without looking into the other extenders
  136. out there.
  137. thanks
  138. Steve
  139.  
  140. *** See also #2342.
  141.  
  142.  
  143. From:    Chris Boogmans                         Rec'd
  144. To:      Kevin Kitsemetry                       Msg #2333, Feb-04-94 11:27AM
  145. Subject: Just a few C 9.5 questions
  146.  
  147. KK> Internal Report #16679
  148.  
  149.  
  150. Kevin,
  151. i have a few questions regarding the WatCom C9.5 library. I hope you can
  152. provide me with the answers. First some background on these questions : In
  153. certain situations, my (and other people's) application has the need to switch
  154. it's stack. That is, all functions which are called on another stack,need to
  155. re-establish the 'flat model' environment before they can safely call any
  156. library function (or any C written function that was not 'specially'
  157. compiled). Since it is not safe to take any assumptions on the value of ESP
  158. when the application was interrupted, and since that value cannot be retrieved,
  159. a simple way to do this is : allocate one (or a few) stack areas at applica-
  160. tion startup, lock that memory, keep it's address (top & bottom) in a global
  161. variable, and use it as a stack frame when needed. So far, so good, but a pro-
  162. blem may rise if any of the called functions was compiled using the stack-heck
  163. option (since the malloced area may be at an address below the main stack).
  164. Therefore :
  165. Q1- are there any LIB functions that call the stack-checking code ? Q2- if the
  166. application would like to use that stack-checking option in ALL
  167.     situations (even when it has switched it's stack), would it be safe to
  168.         take the following actions :
  169.         1- replace [__STACKLOW] with the appropriate value each time a stack
  170. switch
  171.            is done (in both directions)
  172.         2- provide another implementation of __exit_with_message, so that any
  173.            exit would be delayed untill the application is running 'in
  174. foreground'
  175. I would appreciate if you guys could provide me with that information. PS1: On
  176. december 8, i reported a performance problem in _scrolltextwindow();
  177.     on december 9, you said you had reproduced it and would have to investi-
  178.         gate further (Msg #2007, Incident report #12416); any status update
  179. here ?
  180. PS2: If the b level patches become available, will your BBS message which
  181.     announces such be on the FIRST page of info after logon ? (calling overseas
  182.         at only 2400 bps; it takes some time to go through all the info each
  183. time).
  184. Many thanks in advance, Chris.
  185.  
  186. *** See also #2343.
  187.  
  188.  
  189. From:    Debra Mudar                            Rec'd
  190. To:      Kevin Kitsemetry                       Msg #2334, Feb-03-94 09:59AM
  191. Subject: Font Usage Questions
  192.  
  193. #include <graph.h>
  194. #include <stdlib.h>
  195. #include <stdio.h>
  196. #include <conio.h>
  197. #include <string.h>
  198.  
  199. #define NFONTS 6
  200.  
  201. char *options[NFONTS] =
  202. {
  203.         "Courier", "Helv", "Tms Rmn", "Modern", "Script", "Roman" };
  204.  
  205. int main(void)
  206. {
  207.    /* request auto detection */
  208.    int gdriver , gmode,  x1, y1, x2, y2, nfont;
  209.    char graphdirectory[30], list[30], fondir[30];
  210.  struct _fontinfo fi;
  211.  int result;
  212. // THIS STRING MUST BE SET FOR THE DIRECTORY WHERE THE FONT (*.FON) // FILES
  213. ARE FOUND
  214.    strcpy(graphdirectory, "c:\\windows\\system\\*.fon");
  215.    if( _registerfonts( graphdirectory   ) <= 0 )
  216.    {
  217.         _outtext( "Enter full path where .FON files are located: " );
  218.         gets( fondir );
  219.         strcat( fondir, "\\*.FON" );
  220.         if( _registerfonts( fondir ) <= 0 )
  221.         {
  222.          _outtext( "Error: can't register fonts" );
  223.          exit( 1 );
  224.         }
  225.         }
  226.    gdriver = _MAXRESMODE;
  227.    /* initialize graphics mode */
  228.    gmode = _setvideomode(gdriver);
  229.  
  230.    if (!gmode)  /* an error occurred */
  231.    {
  232.           printf("Graphics error: Unable to initialize graphics adapter.");
  233.           printf("Press any key to halt:");
  234.           getch();
  235.           exit(1);             /* return with error code */
  236.    }
  237.    x1 = 100; y1 = 50; x2 = 540; y2 = 430;
  238.    /* draw a line */
  239.    _rectangle(_GBORDER, x1, y1 , x2, y2);
  240.    nfont = 0;
  241.    strcat( strcat( strcpy( list, "t'" ), options[nfont] ), "'");
  242.    strcat( list, "h12w10b" );
  243.    if( _setfont( list ) >= 0 )
  244.    {
  245.          result = _getfontinfo(&fi);
  246.          _moveto(150, 200);
  247.          _outgtext("WATCOM C GRAPHICS AND FONT TEST");
  248.          _moveto(190,220);
  249.          _outgtext("PRESS ANY KEY TO EXIT");
  250.    }
  251.    /* clean up */
  252.    getch();
  253.    _unregisterfonts();
  254.    _setvideomode( _DEFAULTMODE );
  255.    return 0;
  256. }
  257.  
  258.  
  259. From:    Debra Mudar                            Rec'd
  260. To:      Kevin Kitsemetry                       Msg #2335, Feb-04-94 01:53PM
  261. Subject: Lost Text - Here's the Message
  262.  
  263. KK> Internal Report #16680
  264.  
  265.  
  266. To WATCOM Tech Support:
  267.  
  268. I am having a small problem using the WATCOM C/C++(32) font-related
  269. commands,particularly _setfont.  The problem lies with the use of the best fit
  270. option (b) with the raster fonts.  Following I have attached a program which
  271. calls this routine using the Windows system fonts.  I can successfully display
  272. the strings using any of the vector fonts with the best fit option. I cannot
  273. successfully display any of the raster fonts with the best fit option, or any
  274. of the other options. I have tried many combinations such as r and f.  The
  275. real problem lies with using Courier.  No matter what options I try,selecting
  276. the Courier font displays Script instead or sometimes I get no text at all.
  277. (The typeface returned in fi.typeface = Script.  This same program will work
  278. properly under MSC 7.0 using the Windows fonts.  I would really like to be
  279. able to successfully select any of the fonts using the best fit option,
  280.  
  281.  
  282. From:    Hal Lonas                              Rec'd
  283. To:      Kevin Kitsemetry                       Msg #2336, Feb-03-94 10:11AM
  284. Subject: B-level patches
  285.  
  286. Kevin,
  287.    I think you guys are being very responsible to hold the B-level
  288.    stuff until QA says its ok, especially in light of the obvious
  289.    pressure you're getting.
  290.  
  291.    Having said that, I wonder if you're making the patches available
  292.    on a beta basis to folks who could test.  We use C/C++ 32 to build
  293.    a Windows DLL and require w386dll.ext to work right and have helped
  294.    find problems with it in the past (as with the A-level patches.)
  295.  
  296.    Tell me to buzz off if you want, we'd like to get a heads-up on the
  297.    patches if we could.
  298. Thanks,
  299. Hal Lonas
  300.  
  301. *** See also #2344.
  302.  
  303.  
  304. From:    David Alderman                         Rec'd
  305. To:      Kevin Kitsemetry                       Msg #2337, Feb-03-94 03:34PM
  306. Subject: File Handles Open Across Spawn
  307.  
  308. In regards to file handles across a spawn:  DOS does not close file handles
  309. across a spawn with most 16-bit compilers.  For example if I write a parent
  310. and child app under Microsoft C 6,  file descriptors in the parent are
  311. available in the child.  And let's not forget file descriptors 0, 1, & 2.
  312. They always stay open and if I redirect stderr (handle 2) it stays redirected
  313. in the spawned program.  Closing and reopening the handle is not a very good
  314. option for me, as the printer to which I am attached will despool on network
  315. printers (unless the printer is specifically set up not to despool on close
  316. which causes problems with other apps).  I'm sorry about mentioning the "M*"
  317. word;  I know that their libraries may be exhibiting aberrant behavior (BG)
  318. but I would like to reproduce that "aberration"!  Thanks for your reply.
  319.  
  320. BTW, Can you tell me a good place to order VX-REXX?
  321. Dave.
  322.  
  323. *** This is a reply to #2313.  *** See also #2345.
  324.  
  325.  
  326. From:    Kevin Kitsemetry
  327. To:      Johann Walter                          Msg #2338, Feb-04-94 10:52AM
  328. Subject: VFW 1.1
  329.  
  330.  JW>   Any chance that the B level patch will be out soon?
  331.  JW> We are nearing shipping for our product and I need to
  332.  JW> know if the level B patch will fix the problems I'm
  333.  JW> having with VFW1.1.
  334.  
  335. If I knew I would tell you.  If I try to take a guess, there is a 99% change
  336. that I would be wrong.  Soon is all I can say,and that is a relative word!
  337.  
  338. Sorry!
  339. Kevin
  340.  
  341. *** This is a reply to #2326.
  342.  
  343.  
  344. From:    Kevin Kitsemetry                       Rec'd
  345. To:      Patrick Lamb                           Msg #2339, Feb-04-94 10:55AM
  346. Subject: unexpected interrupt
  347.  
  348.  PL> I have run into a strange problem with Watcom C32
  349.  PL> 9.5a.  The problem stops
  350.  PL> with the message
  351.  PL>     Unexpected interrupt 0D (code 46E80000) at 158:45D41F
  352.  PL>     TSF32: prev_tsf32 4F74
  353.  PL> and a bunch of register dumps.
  354.  PL>
  355.  PL> I tried running the program under the debugger (WVIDEO), and it stops at
  356.  PL> (apparently) the same place with the message
  357.  PL>     *****TASK EXCEPTION***** PAGE FAULT.
  358.  PL> The line it bombs on is
  359.  PL>     free( array[i] )
  360.  PL> where array has previously been allocated, and
  361.  PL> array[i] allocated for i<6;
  362.  PL> it bombs when i=1 (the second time through a for loop).
  363.  PL>
  364.  PL> I'm running with the DOS4GW extender under DOS 6.2 on a 386/20 with 10 Mb
  365.  PL> (got kicked off the 486!).
  366.  PL>
  367.  
  368. One useful feature of DOS/4GW is setting the environment variable dos4g=nullp.
  369.  Run the program and let it crash and see if it then tells you that it has
  370. found a null poiner.  You may also want to fire up the debugger and look at
  371. the address of the array that is about to be free'd just before you execute
  372. that line.  Chances are it is going to be a bogus value.
  373.  
  374.  
  375. Kevin Kitsemetry
  376. WATCOM TECHNICAL SUPPORT
  377.  
  378. *** This is a reply to #2327.  *** See also #2360.
  379.  
  380.  
  381. From:    Kevin Kitsemetry                       Rec'd
  382. To:      John Lansdale                          Msg #2340, Feb-04-94 11:06AM
  383. Subject: WIN32s + NT DLLs
  384.  
  385.  JL> I'm having a small problem running a NT program under
  386.  JL> win32s. I've created
  387.  JL> a 32-bit DLL using th  NT_DLL linker mode and the DOS-
  388.  JL> based wcc386 compiler.
  389.  JL> When I try to use this library in a simple NT-compiled
  390.  JL> program under win32s
  391.  JL> the loader complains that it cannot find a number of
  392.  JL> DLL support libraries
  393.  JL> such as win32spl.dll, etc. Are these included with an updated version of
  394.  JL> win32s SDK or must I set some compiler/linker flags for win32s program
  395.  JL> generation?
  396.  
  397. The idea behind Win32s is that a Windows NT program that will run under NT
  398. will run under Win32s, provided that it does not make any NT API calls. As far
  399. as what comes with the Win32s SDK, you will have to check with Microsoft on
  400. that one.
  401. There are no special compiler/linker flags designed for creating Win32s
  402. applications.  You should just create an NT style executable.
  403.  
  404.  
  405. Kevin Kitsemetry
  406. WATCOM TECHNICAL SUPPORT
  407.  
  408. *** This is a reply to #2329.
  409.  
  410.  
  411. From:    Kevin Kitsemetry                       Rec'd
  412. To:      Steve Chiang                           Msg #2342, Feb-04-94 11:15AM
  413. Subject: Dos 4GW
  414.  
  415.  SC> I d/l'ed the level A patches, and when it attempted to patch Dos 4gw,
  416.  SC> it returned a checksum error.
  417.  
  418. This is most likely due to an error in communication over the phone line.
  419.  
  420.  
  421.  SC> Now, I think I have a problem due to Dos 4gw... and I want to get an
  422.  SC> updated version.  How can I get v1.95 of 4gw.  I'm not sure if I want
  423.  SC> to purchase the pro version without looking into the other extenders
  424.  SC> out there.
  425.  
  426. If you provide your registration number to us, we can give you the location of
  427. the latest extender.
  428.  
  429.  
  430. Kevin Kitsemetry
  431. WATCOM TECHNICAL SUPPORT
  432.  
  433. *** This is a reply to #2332.  *** See also #2367.
  434.  
  435.  
  436. From:    Kevin Kitsemetry                       Rec'd
  437. To:      Chris Boogmans                         Msg #2343, Feb-04-94 11:23AM
  438. Subject: Just a few C 9.5 questions
  439.  
  440.  CB>     on december 9, you said you had reproduced it and
  441.  CB> would have to investi-
  442.  CB>         gate further (Msg #2007, Incident report
  443.  CB> #12416); any status update here ?
  444.  CB> PS2: If the b level patches become available, will your BBS message which
  445.  CB>     announces such be on the FIRST page of info after
  446.  CB> logon ? (calling overseas
  447.  
  448. This was brought to the attention of the developers.  They said at that time
  449. that they would look into the possibility of speeding it up, but nothing was
  450. promised.  I will look into you questions and respond to them at a later date
  451. when I have had a chance to discuss them with the development team.
  452.  
  453.  
  454. Kevin Kitsemetry
  455. WATCOM TECHNICAL SUPPORT
  456.  
  457. *** This is a reply to #2333.
  458.  
  459.  
  460. From:    Kevin Kitsemetry                       Rec'd
  461. To:      Hal Lonas                              Msg #2344, Feb-04-94 11:35AM
  462. Subject: B-level patches
  463.  
  464.  HL> Kevin,
  465.  HL>    I think you guys are being very responsible to hold the B-level
  466.  HL>    stuff until QA says its ok, especially in light of the obvious
  467.  HL>    pressure you're getting.
  468.  HL>
  469.  HL>    Having said that, I wonder if you're making the patches available
  470.  HL>    on a beta basis to folks who could test.  We use C/C++ 32 to build
  471.  HL>    a Windows DLL and require w386dll.ext to work right and have helped
  472.  HL>    find problems with it in the past (as with the A-level patches.)
  473.  HL>
  474.  HL>    Tell me to buzz off if you want, we'd like to get a heads-up on the
  475.  HL>    patches if we could.
  476.  
  477. Thanks for offer, and the vote of confidence!  Beta testing the patches might
  478. be a good idea.  It's not something that we currently do.
  479.  
  480. Functionality testing has actually ended.  What we are working on now is
  481. making sure that the 'b' level masters will equal the patched 'a' level stuff.
  482.  If one file in the bunch is different by one byte, the 'c' level patch will
  483. not work on that file!
  484.  
  485.  
  486. Kevin Kitsemetry
  487. WATCOM TECHNICAL SUPPORT
  488.  
  489. *** This is a reply to #2336.
  490.  
  491.  
  492. From:    Kevin Kitsemetry
  493. To:      David Alderman                         Msg #2345, Feb-04-94 02:32PM
  494. Subject: File Handles Open Across Spawn
  495.  
  496.  DA> In regards to file handles across a spawn:  DOS does
  497.  DA> not close file handles across a spawn with most 16-bit
  498.  DA> compilers.  For example if I write a parent and child
  499.  DA> app under Microsoft C 6,  file descriptors in the
  500.  DA> parent are available in the child.  And let's not
  501.  DA> forget file descriptors 0, 1, & 2.
  502.  DA> They always stay open and if I redirect stderr (handle
  503.  DA> 2) it stays redirected
  504.  
  505. The operating system, upon spawning a program, does know about the file
  506. handles.  The problem is that the runtime library of the child application
  507. does NOT know about it (was it opened for binary or text output, etc.).  What
  508. you might try is using the _dos_xxx functions, since that uses the INT 21h
  509. functions
  510. directly.
  511.  
  512.  
  513.  DA> BTW, Can you tell me a good place to order VX-REXX?
  514.  
  515. You can contact our sales department at 1-800-265-4555.  They would be able to
  516. provide you with the most up to date information.
  517.  
  518.  
  519. Kevin Kitsemetry
  520. WATCOM TECHNICAL SUPPORT
  521.  
  522. *** This is a reply to #2337.
  523.  
  524.  
  525. From:    Joseph Molnar
  526. To:      Tech Support (Kev)                     Msg #2346, Feb-07-94 04:00PM
  527. Subject: Problem
  528.  
  529. Internal report #16902
  530.  
  531. Having a slight problem with token pasteing(?).  I am doing some unicode stuff
  532. under NT, and as you might know MS creates a MACRO that they put in front of
  533. all strings so they can choose whether or not to make is ASCII or UNICODE
  534. across compiles.  It isn't working well, the string is returning a char*
  535. instead of long char*.  This is an edited example:
  536.  
  537. #define UNICODE
  538. #include <windows.h>
  539.  
  540. // btw, NT defines TEXT to be
  541. #define TXT( quote ) L##quote
  542.  
  543. LPCTSTR szProject = TXT("CASEY");
  544. LPCTSTR szSpecNum = TXT("1.2");
  545. LPCTSTR szBuildNum = TXT("1056");
  546.  
  547. Any ideas?
  548.  
  549. Also I was curious about the funny, is it possible for MS C8 code to be
  550. debugged by WVIDEO, and for WinBug (NT's debugger) to debug W9.5 NT code?  I
  551. guess I am asking how is the cross tool support.  I recall something about the
  552. use of COFF on your end, but I was too sure.
  553.  
  554. *** See also #2407.
  555.  
  556.  
  557. From:    Dan Cummins                            Rec'd
  558. To:      Chris Boogmans                         Msg #2347, Feb-04-94 05:10PM
  559. Subject: Just a few C 9.5 questions
  560.  
  561. KK> Internal Report #16679
  562.  
  563.  
  564.  CB> Kevin,
  565.  CB> i have a few questions regarding the WatCom C9.5 library. I hope you can
  566.  CB> provide me with the answers. First some background on
  567.  CB> these questions : In certain situations, my (and other
  568.  CB> people's) application has the need to switch it's
  569.  CB> stack. That is, all functions which are called on
  570.  CB> another stack,need to re-establish the 'flat model'
  571.  CB> environment before they can safely call any library
  572.  CB> function (or any C written function that was not
  573.  CB> 'specially' compiled). Since it is not safe to take
  574.  CB> any assumptions on the value of ESP when the
  575.  CB> application was interrupted, and since that value
  576.  CB> cannot be retrieved,
  577.  CB> a simple way to do this is : allocate one (or a few) stack areas at
  578.  CB> applica-tion startup, lock that memory, keep it's
  579.  CB> address (top & bottom) in a global variable, and use
  580.  CB> it as a stack frame when needed. So far, so good, but
  581.  CB> a pro-blem may rise if any of the called functions was
  582.  CB> compiled using the stack-heck option (since the
  583.  CB> malloced area may be at an address below the main
  584.  CB> stack). Therefore :
  585.  
  586. Kevin is going to be away for a while so I have been asked to respond to some
  587. of your questions.
  588.  
  589.  CB> Q1- are there any LIB functions that call the stack-
  590.  CB> checking code ?
  591.  
  592. Yes, according to our development team.
  593.  
  594.  CB> Q2- if the application would like to
  595.  CB> use that stack-checking option in ALL
  596.  CB>     situations (even when it has switched it's stack),
  597.  CB> would it be safe to
  598.  CB>         take the following actions :
  599.  CB>         1- replace [__STACKLOW] with the appropriate
  600.  CB> value each time a stack switch
  601.  CB>            is done (in both directions)
  602.  
  603. Here is an example that demonstrates how to do this.
  604.  
  605. *****
  606. This example is now in file area 10 (WC)
  607. *****
  608. extern void
  609. CallFuncWithNewStack( void (*func)(void), void *new_stack_ptr);#pragma aux
  610. CallFuncWithNewStack = \
  611.         "sub    edx,16"         /* allocate space from new stack */\
  612.         "mov    [edx],esp"      /* save current SS:ESP on new stack */\
  613.         "mov    4[edx],ss"      \
  614.         "mov    8[edx],edx"     /* set up new values for SS:ESP */\
  615.         "mov    12[edx],ds"     \
  616.         "lss    esp,8[edx]"     /* switch to new stack */\
  617.         "call   eax"            /* call user's function */\
  618.         "lss    esp,[esp]"      /* switch back to original stack */\
  619.         parm [eax] [edx];
  620. #define STACK_SIZE      4096
  621. char TempStack[STACK_SIZE];
  622. void myfunc(void)
  623. {
  624.     printf( "Hello\n" );
  625. }
  626. main()
  627. {
  628.     CallFuncWithNewStack( myfunc, &TempStack[STACK_SIZE] );}
  629.  
  630.  CB>         2- provide another implementation of
  631.  CB> __exit_with_message, so that any
  632.  CB>            exit would be delayed untill the
  633.  CB> application is running 'in foreground'
  634.  CB> I would appreciate if you guys could provide me with that information.
  635.  CB> PS1: On december 8, i reported a performance problem
  636.  CB> in _scrolltextwindow();
  637.  CB>     on december 9, you said you had reproduced it and
  638.  CB> would have to investi-
  639.  CB>         gate further (Msg #2007, Incident report
  640.  CB> #12416); any status update here ?
  641.  
  642. Apparently, this is in the hands of our graphics developers.  I don't know
  643. whether it was fixed for B-level.
  644.  
  645.  CB> PS2: If the b level patches become available, will your BBS message which
  646.  CB>     announces such be on the FIRST page of info after
  647.  CB> logon ? (calling overseas
  648.  CB>         at only 2400 bps; it takes some time to go
  649.  CB> through all the info each time).
  650.  
  651. I will pass your suggestion along to Kevin.
  652.  
  653.  CB> Many thanks in advance, Chris.
  654.  
  655. Dan Cummins
  656. WATCOM Languages Support
  657.  
  658. *** This is a reply to #2333.
  659.  
  660.  
  661. From:    Matt Howard
  662. To:      All                                    Msg #2348, Feb-05-94 01:22AM
  663. Subject: Watcom C/C++ - getting started
  664.  
  665. To anyone out there willing to help,
  666.  
  667.         I just purchased Watcom C/C++ 32 and I feel like I'm in way over my
  668. head. I'm a very experienced Borland Dos coder but maybe I've been spoiled by
  669. their IDE's. Anyway, I might as well cut to the chase on the many problems I'm
  670. having:
  671.  
  672.         1. Converting Real-mode Assembly- I've got many vital .asm routines
  673. that I want to convert to protected mode under WC/C++. I don't really
  674. understand how I should handle the pointers generated by WC. If I just treat
  675. them as DWORD's and dereference them will that give me the correct location?
  676. And can all the assembling be done with TASM or do I need a 32-bit assembler
  677. too? Could you possibly give me just a routine to put a pixel from a memory
  678. location to the video memory? Or possibly a simple mouse Int 33h call?
  679.  
  680.         2 .Also, what does the asm keyword do in WC. The Bjarne Stroustrup
  681. says it is dependent on implimentation, but I had been using it often in BC++
  682. for inline assembly. Do I have to convert all this to external?
  683.  
  684.         3. Is there a better help program than that WHELP which gives you only
  685. reference on C functions and nothing on C++ or the pre-defined Structs of C?
  686.  
  687.         4. I know I should be compiling for the flat mem model, but does that
  688. mean I can convert all my old far pointers to near ones? And what is the use
  689. of the big mem model if there is no runtime library to go with it (at least
  690. that's what the manual seem to say)?
  691.  
  692.         5. Where can I get some more in-depth documentation on DOS/4GW and the
  693. workings of protected mode? And is DOS/4GW Professional worth it?
  694.  
  695.         6. Is it true that functions can't be declared without a type
  696. specifier and default to "int"?
  697.  
  698.         7. Just a side question- Many professional games lately have been
  699. displaying the DOS/4GW banner. Since DOS/4GW (and Pro version) are specific to
  700. Watcom, does that mean that these games were compiled with the Watcom compiler?
  701.  
  702. Thanks alot to anyone who replies.
  703.                                 Sincerely,
  704.                                 Matt Howard
  705.  
  706. *** See also #2353.
  707.  
  708.  
  709. From:    Kellee Crisafulli
  710. To:      Watcom Tech Support                    Msg #2349, Feb-06-94 02:42AM
  711. Subject: Thanks for the B patches!
  712.  
  713. I waited until you had the A rev patches out to purchase 9.5 so it would be
  714. solid.  I received it this week and recompiled my code only to find out that I
  715. had 2 internal compiler errors #28.  I was just about to scream when I thought
  716. I would check your BBS.  The rev B patches fixed this error and my other big
  717. complaint (VESA support).
  718.  
  719. Great job, your work is really appreciated!
  720.  
  721. Kellee Crisafulli, HyperLynx
  722.  
  723.  
  724. From:    Brian Burton
  725. To:      All                                    Msg #2350, Feb-07-94 04:20PM
  726. Subject: filename in NT
  727.  
  728. Internal report #16903
  729.  
  730. The NT hosted tools do not handle long file names properly. wcl386 truncates
  731. longfilename.obj to longfilenam and then
  732. searches for longfilenam.cxx/cpp/cc/c.  This is a major annoyance since I
  733. prefer to name source files after the class that they implement and I don't
  734. want short class names.  It seems like a trivial fix.  Does Watcom have any
  735. plans to address this problem?
  736. ++Brian
  737.  
  738. *** See also #2399.
  739.  
  740.  
  741. From:    Brian Burton
  742. To:      All                                    Msg #2351, Feb-06-94 05:50PM
  743. Subject: ntheaders.zip
  744.  
  745. The header file excpt.h was not included and rpc.h requires it.
  746. ++Brian
  747.  
  748. *** See also #2398.
  749.  
  750.  
  751. From:    Peter Schauer                          Rec'd
  752. To:      Kevin Kitsemetry                       Msg #2352, Feb-14-94 12:10PM
  753. Subject: acc. 16bit dll's too
  754.  
  755. Internal Report #17054
  756.  
  757. I have some trouble with accesing 16-bit code in a MSC-generated Dll too. (
  758. MSG 1587 from Mr. Edward Palandri)
  759. I red the problem but no solution (if exist). Can you send it to me or please
  760. ship to me a additional microcode to link with my application ( there seems to
  761. be similar problems with FORTRAN ??!!??  MSG Nr. ????). With the best regards
  762. from 'good old' germany
  763. Peter
  764.  
  765. *** See also #2486.
  766.  
  767.  
  768. From:    David Kennedy                          Rec'd
  769. To:      Matt Howard                            Msg #2353, Feb-07-94 01:17PM
  770. Subject: Watcom C/C++ - getting started
  771.  
  772.  MH>         1. Converting Real-mode Assembly- I've got many vital .asm
  773.  MH> routines that I want to convert to protected mode
  774.  MH> under WC/C++. I don't really understand how I should
  775.  MH> handle the pointers generated by WC. If I just treat
  776.  MH> them as DWORD's and dereference them will that give me
  777.  MH> the correct location?
  778.  MH> And can all the assembling be done with TASM or do I
  779.  MH> need a 32-bit assembler too? Could you possibly give
  780.  MH> me just a routine to put a pixel from a memory
  781.  MH> location to the video memory? Or possibly a simple
  782.  MH> mouse Int 33h call?
  783.  
  784. On page 41 and 42 of the Commonly Asked Questions and Answers, you will find a
  785. short example of an interrupt handler.  If you examine the protected mode
  786. section, you should be able to find appropriate examples if interrupt calls
  787. and memory handling.
  788.  
  789.  MH>         2 .Also, what does the asm keyword do in WC.
  790.  MH> The Bjarne Stroustrup says it is dependent on
  791.  MH> implimentation, but I had been using it often in BC++
  792.  MH> for inline assembly. Do I have to convert all this to
  793.  MH> external?
  794.  
  795. The .asm keyword is unrecognized by the WATCOM C compiler.  You should refer
  796. to the section starting on page 166 of the User's Guide for examples of
  797. creating auxiliary pragmas to generate inline assembler code.
  798.  
  799.  MH>         3. Is there a better help program than that
  800.  MH> WHELP which gives you only reference on C functions
  801.  MH> and nothing on C++ or the pre-defined Structs of C?
  802.  
  803. We do provide the Winhelp utility and the .hlp files for the windows SDK in
  804. the BINW directory.
  805.  
  806.  MH>         4. I know I should be compiling for the flat
  807.  MH> mem model, but does that mean I can convert all my old
  808.  MH> far pointers to near ones? And what is the use of the
  809.  MH> big mem model if there is no runtime library to go
  810.  MH> with it (at least that's what the manual seem to say)?
  811.  
  812. Under the flat memory model, which should always be used with the 32-bit
  813. compiler, it is not necessary to declare functions as far or near.
  814.  
  815.  MH>         5. Where can I get some more in-depth documentation on DOS/4GW
  816.  MH> and the workings of protected mode? And is DOS/4GW
  817.  MH> Professional worth it?
  818.  
  819. You can find more information on protected mode programming in a book called
  820. "Extending DOS" by Duncan.  DOS/4GW professional provides faster,more powerful
  821. virtual memory support that is useful in some applications.
  822.  
  823.  
  824.  MH>         6. Is it true that functions can't be declared
  825.  MH> without a type specifier and default to "int"?
  826.  
  827. I believe this is the standard C specification.  If a function has not been
  828. prototyped before it is referenced, it is assumed to be of type "int"
  829.  
  830.  MH>         7. Just a side question- Many professional
  831.  MH> games lately have been displaying the DOS/4GW banner.
  832.  MH> Since DOS/4GW (and Pro version) are specific to
  833.  MH> Watcom, does that mean that these games were compiled
  834.  MH> with the Watcom compiler?
  835.  
  836. We cannot speculate on who does or does not use our compiler.
  837.  
  838.  MH> Thanks alot to anyone who replies.
  839.  MH>                                 Sincerely,
  840.  MH>                                 Matt Howard
  841.  
  842. *** This is a reply to #2348.  *** See also #2365.
  843.  
  844.  
  845. From:    Joseph Molnar
  846. To:      Tech Support (Kevin)                   Msg #2354, Feb-08-94 12:22AM
  847. Subject: The DEBUGGER
  848.  
  849. Okay, I am not really in a good mood, but I am heading to bed and need to get
  850. this off my chest.  The debugger is bad, really bad I mean.  You see,
  851. compilers were supposed to head to incremental compiling, but then someone
  852. (Bjarne) made C++, where inlining was a possibility, but required it be put it
  853. the header, then he added templates, requiring even more to be put in the
  854. header, in fact, doind what I am right now, everything of mine is pretty much
  855. in the header.  While this is really annoying and all, I can't debug a single
  856. bit of it.  I have approximately 5000 lines I would like to debug and I can't
  857. (not all 5000 is buggy, just I have a total of 5000 lines in all my headers).
  858. Please tell me I am missing something and that in fact I can debug my headers,
  859. otherwise the debugger is useless and I have to start doing the PRINTF method,
  860. and if it is true, tell me I can get a beta or something of that new debugger.
  861.  Otherwise I can't really use Watcom C++ for this project, and I would like to
  862. but....  Perhaps as a final resort, are you guys COFF compliant, and if so, do
  863. you know of any COFF debuggers.  I know MSC8.0 debugs headers fine, but I
  864. don't know if it is COFF debugger.
  865.  
  866. Please help ... too many printf's ...
  867.  
  868. Joseph Molnar
  869.  
  870. *** See also #2356.
  871.  
  872.  
  873. From:    Chris Boogmans                         Rec'd
  874. To:      Dan Cummins                            Msg #2355, Feb-08-94 10:24AM
  875. Subject: Same question again
  876.  
  877. Internal report #16945
  878.  
  879. Hi Dan,
  880. thanks for your reply to my question ... only, my question was not HOW i have
  881. to call a function with another stack, but rather whether or not the update of
  882. [__STACKLOW] would generate a correct check on the new stack. In your example,
  883. if the function printf() and/or the source file containing the example
  884. code would have been compiled without the /s option, than the example code will
  885. fail (an invalid 'stack overflow' will be generated if the new stack is below
  886. the default stack, and the stack may very well overflow without any message in
  887. the other case). I would like to have a mechanism that is waterproof, even if
  888. a lib function calls another lib function, both compiled with the stack check
  889. option on. So, as stated in my original message, i would be very glad if you
  890. could provide me with **THAT** information.
  891. Thanks in advance, Chris.
  892.  
  893. *** See also #2361.
  894.  
  895.  
  896. From:    Kevin Blenkinsopp                      Rec'd
  897. To:      Anthony Scian                          Msg #2357, Feb-08-94 10:16AM
  898. Subject: Destructors in B-level
  899.  
  900. Anthony,
  901.  
  902. I downloaded the b-level last night, and rebuilt the system with it this
  903. morning, and noticed something very different, namely my destructors are not
  904. getting called. This is bad. The snippet below reproduces the problem:
  905. 'anothera' gets destroyed properly, but 'a' doesn't. This wasn't the case with
  906. the pre-release b-level I had (29 Nov) if that helps you track this down. I
  907. just shelled out for a second to check a hunch - the destructor for 'a' DOES
  908. get called if you take out the exit() at the end of main(), which means I can
  909. live with this, as that is the only exit() in the whole program. Still, I
  910. guess you should probably be aware of this.
  911.  
  912. Anyway, thanks for your time, and if you reply to this with something like
  913. "the january 94 draft of ansi c++ says that you don't have to call destructors
  914. when a non-zero argument is passed to exit()", I will come up to Canada and
  915. marmalise you!
  916.  
  917. Cheers,
  918.  
  919. Kevin.
  920.  
  921. (code follows...)
  922.  
  923.  
  924. #include        <iostream.h>
  925. #include        <stdlib.h>
  926.  
  927. struct A {
  928.         A(void) { cout << "ctor\n"; }
  929.         ~A() { cout << "dtor\n"; }
  930. };
  931.  
  932. void foo(void)
  933. {
  934.         throw("Bye");
  935. }
  936.  
  937. void main()
  938. {
  939.         A a;
  940.  
  941.         try {
  942.          A anothera;
  943.          foo();
  944.         } catch (char *z) {
  945.          cout << "Somebody threw '" << z << '\'' << endl;
  946.         }
  947.  
  948.         exit(1);
  949. }
  950.  
  951. *** See also #2359.
  952.  
  953.  
  954. From:    Kevin Blenkinsopp                      Rec'd
  955. To:      Kevin Kitsemetry                       Msg #2358, Feb-08-94 10:23AM
  956. Subject: Jumping on the bandwagon
  957.  
  958. Kevin,
  959.  
  960. I hate to be another of the many voices hassling you about this, but what are
  961. the odds we'll see video dead and buried by the end of second quarter 94. I've
  962. really tried to be friends with it, but it just doesn't want to play ball.
  963.  
  964. Kevin
  965.  
  966. *** See also #2377.
  967.  
  968.  
  969. From:    Anthony Scian                          Rec'd
  970. To:      Kevin Blenkinsopp                      Msg #2359, Feb-08-94 11:18AM
  971. Subject: Destructors in B-level
  972.  
  973.  KB> Anthony,
  974.  
  975.  KB> I downloaded the b-level last night, and rebuilt the system with it this
  976.  KB> morning, and noticed something very different, namely
  977.  KB> my destructors are not getting called. This is bad.
  978.  KB> The snippet below reproduces the problem: 'anothera'
  979.  KB> gets destroyed properly, but 'a' doesn't. This wasn't
  980.  KB> the case with the pre-release b-level I had (29 Nov)
  981.  KB> if that helps you track this down. I just shelled out
  982.  KB> for a second to check a hunch - the destructor for 'a'
  983.  KB> DOES get called if you take out the exit() at the end
  984.  KB> of main(), which means I can live with this, as that
  985.  KB> is the only exit() in the whole program. Still, I
  986.  KB> guess you should probably be aware of this.
  987.  
  988.  KB> Anyway, thanks for your time, and if you reply to this
  989.  KB> with something like "the january 94 draft of ansi c++
  990.  KB> says that you don't have to call destructors when a
  991.  KB> non-zero argument is passed to exit()", I will come up
  992.  KB> to Canada and marmalise you!
  993.  
  994.  Marmalizing doesn't sound pleasant but the ISO/ANSI C++
  995.  draft (Sept'93) does support the B-level C++ compiler's
  996.  behaviour.
  997.  
  998.  I checked the GA version, A-level, and B-level C++ compilers
  999.  and all of them did not destruct the object 'a'.  This is
  1000.  correct behaviour.  It has nothing to do with what you pass
  1001.  to exit(); it simply has to do with the fact that exit()
  1002.  is an ANSI C function and is not connected at all with the
  1003.  C++ exception handling mechanism (an exit() four levels
  1004.  down will not destruct temporaries either).  The current
  1005.  ISO/ANSI C++ draft states this in 17.4.10.4.3:
  1006.  
  1007.     "... all static objects are destroyed in the reverse
  1008.      order of their construction. (Non-static local objects
  1009.      are not destroyed as a result of calling exit.)"
  1010.  
  1011. The pre-release B-level compiler must have temporarily had a bug in it where
  1012. it destructed too many objects.
  1013.  
  1014. *** This is a reply to #2357.  *** See also #2366.
  1015.  
  1016.  
  1017. From:    Patrick Lamb                           Rec'd
  1018. To:      Kevin Kitsemetry                       Msg #2360, Feb-08-94 12:27PM
  1019. Subject: unexpected interrupt
  1020.  
  1021. Here's one more voice doening video.  I have to compile everything at the same
  1022. time to get wvideo to run, see the source file, and not crash.  Obiously not
  1023. good when you have a make file to handle multiple files!
  1024.  
  1025. Apparently part of my original message disappeared into the ether.  The
  1026. problem with re-compiling everything is that, after wmake issues a command
  1027. line, it takes between a minute and two minutes and a half before the compiler
  1028. actually starts to run!  This combination led me to re-install, to see if it
  1029. was the A patches, re-make, update with the patches, re-make, etc.  Hard to
  1030. get any productive work done with that combination.  Plus, with 2 minutes
  1031. disappearing into compiling each file, it takes another twenty minutes to see
  1032. if any change has worked.
  1033.  
  1034. After ranting a while, let me clarify what I was trying to say.  The files are
  1035. not terribly large; and average is some 500 lines, with perhaps 750 included.
  1036. When the compiler is invoked (from wmake or from the command line), the
  1037. computer sits there for 2:30 or so before the compiler comes back with its
  1038. cheery "Watcom C32 9.5a" response.  After that, the compilation time is normal
  1039. (maybe 20-30 seconds).
  1040.  
  1041. This machine is a 386-20 with 12 Mb of memory; I tried it this morning with a
  1042. client's compiler on his 486-66 with 20 Meg, and it only took about thirty
  1043. seconds to respond.
  1044.  
  1045. I'd like to help you track this problem down; what other information do you
  1046. need?
  1047.  
  1048.                 Pat
  1049.  
  1050.  
  1051. *** This is a reply to #2339.  *** See also #2378.
  1052.  
  1053.  
  1054. From:    David Kennedy                          Rec'd
  1055. To:      Chris Boogmans                         Msg #2361, Feb-08-94 01:19PM
  1056. Subject: Same question again
  1057.  
  1058. DK> Internal report #16945
  1059.  
  1060.  CB> whether or not the update of
  1061.  CB> [__STACKLOW] would generate a correct check on the new
  1062.  CB> stack.
  1063.  
  1064. Stack checking will work correctly if you modify the variable that points to
  1065. the bottom of the stack.  The appropriate variable varies with operating
  1066. system, and can be determined using WVIDEO to trace into an alloca() function
  1067. which calls stackavail() which references the stack bottom variable.
  1068.  
  1069. David Kennedy
  1070. WATCOM Languages Support
  1071.  
  1072. *** This is a reply to #2355.
  1073.  
  1074.  
  1075. From:    Ian Currie
  1076. To:      David Kennedey                         Msg #2363, Feb-14-94 12:07PM
  1077. Subject: Weird bug
  1078.  
  1079. Internal report #17496
  1080.  
  1081. I have been experiencing what I'm convinced is a bug in either Watcom or
  1082. Rational for a while now. I just applied the latest patch (level B) and there
  1083. has been no change.
  1084.  
  1085. I am creating a rather large application and cannot upload it all to
  1086. you,however let me explain the situation.
  1087.  
  1088. The problem seems to be whenever the code "grows". What appears to be the
  1089. offending lines of code NEVER execute - but just by them being there seem to
  1090. cause a problem later.
  1091.  
  1092. The program crashes when I try to use fclose() to close a file that was open
  1093. (I've verified that the file pointer does not get trashed).
  1094.  
  1095.  
  1096. The error I get is:
  1097.  
  1098. DOS/4GW error (2001):exception 0Eh (page fault) at 150:004A3A71 TSF32:
  1099. prev_tsf32 512C
  1100. SS       158 DS       158 ES        158 FS         0 GS  20 EAX 46016B74 EBX
  1101.       0 ECX        C7 EDX   4B344A
  1102. ESI   4AC079 EDI   6A6DED EBP    6A6CDC ESP   6A6CC8
  1103. CS:IP  150:004A3A71 ID 0E COD         0 FLG    10206
  1104. CS=  150, USE32, page granular, limit FFFFFFFF, base        0, acc CF9B SS=
  1105. 158, USE32, page granular, limit FFFFFFFF, base        0, acc CF93 DS=
  1106. 158,USE32, page granular, limit FFFFFFFF, base        0, acc CF93 ES=
  1107. 158,USE32, page granular, limit FFFFFFFF, base        0, acc CF93 FS=
  1108. 0,USE16, byte granular, limit        0, base       13, acc 0 GS=   20,
  1109. USE16,byte granular, limit     FFFF, base    60E40, acc 93 CR0: PG: 1 ET: 1
  1110. TS:0 EM:0 MP:0 PE:1   CR2: 46016B78 CR3:64067 Crash address (unrelocated) =
  1111. 1:00038A71
  1112.  
  1113.  
  1114. whenever the line:
  1115.  
  1116.      fclose(fpSecLib);
  1117.  
  1118. gets executed (fpSecLib being type FILE *).
  1119.  
  1120.  
  1121. I once alleviated the problem by not linking in some assembler code that I was
  1122. using and had thought that the assembler code was the problem.
  1123.  
  1124. But the problem arose again.
  1125.  
  1126. Well, when I tried skipping other code before the point where the file in
  1127. question gets closed, the program did not crash. Thus, I thought once again
  1128. that I may have some offending code.
  1129.  
  1130.  
  1131. I can cause the problem a number of ways. For example if I changed the switch
  1132. statement in the sample code below to switch a local variable "test" instead
  1133. of accessing a field of a structure the crash does not occur.
  1134.  
  1135.  
  1136. int test;
  1137.  
  1138.  for (cnt=1; cnt < 4; cnt++)
  1139.   {
  1140.    // if plant is healing and it is linked (& owned of course)...
  1141.    if (Status.proPlant[cnt].status == 2)
  1142.     {
  1143.        if (Status.proPlant[cnt].repairDays)
  1144.          {
  1145.           Status.proPlant[cnt].repairDays--;
  1146.           if (Status.proPlant[cnt].repairDays == 0)     // fixed!
  1147.            {
  1148.             // make it healed, calc new capacity and forget about others!
  1149.             Status.proPlant[cnt].status = PLANTWORKING;
  1150.  
  1151.             // pop up jack quote before buggering off...
  1152.  
  1153.             // test = Status.tot_plant_capacity
  1154.             // switch(test)
  1155.             switch ( Status.tot_plant_capacity )
  1156.              {
  1157.               case 4: quotenum = 37; break;
  1158.               default : NumMessage("ERROR: new capacity is
  1159. ",Status.tot_plant_capacity); break;
  1160.              }
  1161.  
  1162.             JackQuote(quotenum,QUESTQUOTE);
  1163.             break;
  1164.            }
  1165.          }
  1166.     }
  1167.   }
  1168.  
  1169.  
  1170.  
  1171. Alternatively, I can remove other lines of code that appear just after the
  1172. above loop and fix the problem that way! For example, removing:
  1173.  
  1174.    test += Quest_DayTest(cnt);
  1175.  
  1176. or:
  1177.  
  1178.    test += Quest_DoneTest(cnt);
  1179.  
  1180.  
  1181. will stop the crash from happening, but not the third line in the loop which
  1182. is:
  1183.  
  1184.    test += Quest_NotDoneTest(cnt);
  1185.  
  1186.  
  1187.  
  1188. So, I am at a loss as to where the problem could be. Here is the above
  1189. mentioned code:
  1190.  
  1191.  
  1192.  // test for basic quests
  1193.  for ( cnt=0; cnt < MAXQUESTS; cnt++ )
  1194.  {
  1195.   test = 0;
  1196.  
  1197.   // if day is greater than quest start-up day, test will inc!
  1198.   test += Quest_DayTest(cnt);
  1199.  
  1200.   // if the "dependant" quest did in fact occur, test will stay zero
  1201.   // otherwise a 1 will be returned indicating failure
  1202.   test += Quest_DoneTest(cnt);
  1203.  
  1204.   // if the two "dependant" quests did occur, test will inc
  1205.   test += Quest_NotDoneTest(cnt);
  1206.  
  1207.   // ensure the five sectors are unowned...
  1208.   if (Quest_EnemyOwnsOneOfFive(cnt) == FALSE)
  1209.              test +=1;
  1210.  
  1211.   // if any of five sectors are linked, fail test
  1212.   test += Quest_AnyOneOfFiveLinked(cnt);
  1213.  
  1214.   if (quotenum != 999 && QuestInit[cnt].noOtherQuote)
  1215.       test++;
  1216.  
  1217.   if (Status.sectors_owned < QuestInit[cnt].tot_sectors_owned)
  1218.       test++;
  1219.  
  1220.   // ONE LAST TEST: MAKE SURE THE VERY SAME QUEST IS NOT ALREADY IN PROGRESS
  1221.   if (Status.questProgress[cnt] == INPROGRESS)
  1222.      test++;
  1223.  
  1224.  
  1225.   if (!test && cnt == WATERQUEST2)
  1226.     {
  1227.      test  = random(100);
  1228.      if (test < 20)
  1229.          test = 0;
  1230.      else
  1231.          test = 1;
  1232.     }
  1233.  }
  1234.  
  1235.  
  1236.  
  1237. I am running this on a 486/66 using DOS 5.0 and QEMM v6.0 with 16 megs of RAM.
  1238.  
  1239. Since I am developing under tight deadlines, I would appreciate any feedback
  1240. you can offer.
  1241.  
  1242.  
  1243.  
  1244. Ian Currie
  1245.  
  1246. *** See also #2521.
  1247.  
  1248.  
  1249. From:    Dan Teven                              Rec'd
  1250. To:      David Kennedy                          Msg #2365, Feb-08-94 06:07PM
  1251. Subject: Watcom C/C++ - getting started
  1252.  
  1253. Yes, the games were compiled with WATCOM.
  1254.  
  1255. Dan Teven
  1256. Rational Systems (at liberty to state obvious)
  1257.  
  1258. *** This is a reply to #2353.
  1259.  
  1260.  
  1261. From:    Kevin Blenkinsopp                      Rec'd
  1262. To:      Anthony Scian                          Msg #2366, Feb-08-94 06:06PM
  1263. Subject: Destructors in B-level
  1264.  
  1265. Grrr. I hate it when what you say makes sense. Prepare to be marmalised anyway!
  1266.  
  1267. Thanks.
  1268.  
  1269. Kevin
  1270.  
  1271. *** This is a reply to #2359.
  1272.  
  1273.  
  1274. From:    Ramon Rivas
  1275. To:      Tech Support                           Msg #2369, Feb-15-94 10:40AM
  1276. Subject: Wvideo prob with 9.5b
  1277.  
  1278. Internal report #17588
  1279.  
  1280. /*****************************************************************************
  1281. *                                                                            *
  1282. * The following shows a problem with Wvideo (Watcom C/C++ 9.5b) under * *
  1283. Ergo's OS386 V 2.1.06A. Wvideo locks (cold boot needed) when loading
  1284.  * * the program. The command line to compile was:
  1285.   * *
  1286.    *
  1287. * wcl386 -w3 -d2 -zp1 -j -mf -zp1 /od
  1288. * *
  1289.  *
  1290. * The environment variable settings are:
  1291. * *
  1292.  *
  1293. * WCC386=/3r /j /mf /fp3 /w3 /zp1 /od /dOS386
  1294. * * INC386=c:\wc3\h;c:\wc3\h\sys;c:\c4\h;c:\os386\aiacode
  1295.  * * LIBPHAR=c:\wc3\lib386;c:\wc3\lib386\dos
  1296.   * * LIB=c:\wc3\lib386;c:\wc3\lib386\dos
  1297.    * * WCG386=c:\wc3\bin\386wcgl.exe
  1298.     * * WCGMEMORY=?
  1299.      * * WATCOM=c:\wc3
  1300.       * * WVIDEO=/trap#ecs/dynamic#40000/nofpu/swap
  1301.        * * WCL386=/lergo
  1302.         * *
  1303.          *
  1304. * I've ran into many problems with 9.5 that have been corrected with patches *
  1305. * A and B, this is the only one that remains. Please let me know what is
  1306.  * * going ASAP.
  1307.   * *
  1308.    *
  1309. * Thank you.
  1310. * *
  1311.  *
  1312. * Ramon. [(305)-592-2727 Ext 550]
  1313. * *
  1314.  *
  1315. * Note: I've included the OS386 kernel, loader and trap file for your * *
  1316. reference.
  1317.  * *
  1318.   *
  1319. *****************************************************************************/
  1320.  
  1321. #include    "stdlib.h"
  1322. #include    "stdio.h"
  1323. #include    "conio.h"
  1324. #include    "graph.h"
  1325.  
  1326. void
  1327. outtextrc( int row, int col, char *str )
  1328.  
  1329.     {
  1330.     _settextposition( row, col );
  1331.     _outtext( str );
  1332.     }
  1333.  
  1334. void
  1335. dos( void )
  1336.  
  1337.     {
  1338.     _setvideomode( _DEFAULTMODE );
  1339.     puts( "PRESS ANY KEY TO EXECUTE COMMAND PROCESSOR!" );  getch();
  1340.     system( "COMMAND" );
  1341.     puts( "PRESS ANY KEY TO CONTINUE!" );   getch();
  1342.     _setvideomode( _VRES16COLOR );
  1343.     }
  1344.  
  1345. void
  1346. main( int ac, char *av[] )
  1347.  
  1348.     {
  1349.     if ( _setvideomode( _VRES16COLOR ) )
  1350.         {
  1351.         _setcolor( 1 );
  1352.         _rectangle( _GFILLINTERIOR, 100, 100, 540, 380 );
  1353.  
  1354.         outtextrc( 1, 1, "Press a key to make white rectangle ..." );
  1355.         getch();
  1356.  
  1357.         if ( ac > 1 )
  1358.             dos();
  1359.  
  1360.         _setcolor( 15 );
  1361.         _setfillmask( NULL );
  1362.         _rectangle( _GFILLINTERIOR, 100, 100, 540, 380 );
  1363.  
  1364.         outtextrc( 2, 1, "Should be white ..." );
  1365.  
  1366.         outtextrc( 3, 1, "Press any key to exit." );
  1367.  
  1368.         getch();
  1369.  
  1370.         _setvideomode( _DEFAULTMODE );
  1371.         }
  1372.     else
  1373.         puts( "Sorry, you need 640x480x16 to run this program." );
  1374.     }
  1375.  
  1376.  
  1377. From:    Ramon Rivas
  1378. To:      Tech Support                           Msg #2370, Feb-09-94 08:28AM
  1379. Subject: msg 2369
  1380.  
  1381. There is a zip file in the files area that contains some extra files. The name
  1382. of the ZIP is WV95BPRO.ZIP
  1383. Thanks.
  1384.  
  1385.  
  1386. From:    Jim Gerow                              Rec'd
  1387. To:      Kevin Kitsemetry                       Msg #2372, Feb-09-94 09:53AM
  1388. Subject: WLINK has problems with 16-bit modules when in 32-bit mode
  1389.  
  1390. Kevin,
  1391.     We also have the problem when linking for DOS-32.   Could you also check
  1392. if development knows a work-around.  We're all set setting up a proper 16-bit
  1393. environment, (stack & data areas), but need to have the relocation fixups to
  1394. be properly formed as 16:16 addresses, not as a 0:32 linear address.
  1395.  
  1396. Thanks
  1397.  
  1398. *** This is a reply to #2304.  *** See also #2408.
  1399.  
  1400.  
  1401. From:    Ross Linder
  1402. To:      Technical Support                      Msg #2373, Feb-09-94 11:01AM
  1403. Subject: Wcc386 & DesqviewX
  1404.  
  1405. I am havving trouble getting my dvx applications to work.
  1406.  
  1407. After lots of comms with Qdeck, We noticed that thier compiler (9.5)
  1408. is  dated 2-11-93  9:50 am and is 625 566 bytes long. (wcc386.exe)
  1409.  
  1410. My compiler ser # C329501883 is 627702 bytes long, and dated 05-05-93
  1411.  
  1412. Justin Wilmeyer suggested that I get patch level "C" to fix my problem.
  1413.  
  1414. Now for the tricky part, I have tried to download c32_a.zip, but just can't
  1415. get it down. What is the possibility of getting the patches mailed to me in
  1416. South Africa.
  1417.  
  1418. Please respond to my work FAX at (27) (12) 665-1495, or call me at (27) (12)
  1419. 665-1480 or at (27) (11) 793-4818
  1420.  
  1421. I would appriciate any help you can give me. Oh yea, the problem I am having
  1422. is with the OSF Motif UID library when it calls "stat", I get a exp 13
  1423.  
  1424. Thanks muchly
  1425. Ross Linder.
  1426.  
  1427. *** See also #2409.
  1428.  
  1429.  
  1430. From:    Ramon Rivas
  1431. To:      tech support                           Msg #2374, Feb-09-94 01:28PM
  1432. Subject: Multi site license
  1433.  
  1434. Can somebody give me some info on multisite licensce for WC 9.5. We might be
  1435. adding a few more developers and, techincally, they each need a copy of WC
  1436. 9.5. But, maybe, you offer something by which one just pays an amount an
  1437. receives the necessary documentation without wasting extra sets of disks. Is
  1438. there anything like this? Thanks.
  1439.  
  1440.  
  1441. *** See also #2379.
  1442.  
  1443.  
  1444. From:    Joseph Molnar
  1445. To:      Tech Support                           Msg #2375, Feb-15-94 10:36AM
  1446. Subject: Token Pasting problem
  1447.  
  1448. I posted a message just before I got the 9.5b patch about a problem I was
  1449. having with token pasting.  Well the problem is, it is still not fixed. I am
  1450. not sure which message number it was, but it was I think on this past Sunday.
  1451.  I would appreciate any help on this one since we aer trying to put a beta out
  1452. in a week.  The code is being ported from MSC8.0, and since I am using a lot
  1453. of templates (to handle unicode for the most part), port the Watcom C++ files
  1454. to MSC8.0 will just not be possible with a lot of work on behalf by expanding
  1455. out the templates in all the usage (same classes taking three parametric
  1456. types), we are on a tight schedule as it is <GRIN>.  So please have a look at
  1457. the message and let me know.
  1458.  
  1459. Thanks.
  1460.  
  1461. ***See also #2407
  1462.  
  1463.  
  1464. From:    Michael Mishoe                         Rec'd
  1465. To:      Kevin Kitsemetry                       Msg #2376, Feb-10-94 09:21AM
  1466. Subject: EDITOR - INTEGRATED ENVIRONMENT
  1467.  
  1468. I HAVE BEEN USING MSC 7.0 WITH PWB (PROGRAMMER'S WORKBENCH). I WOULD
  1469. LIKE TO KNOW IF I CAN CUSTOMIZE IT TO USE WATCOM C/C++ 32 9.5.
  1470. IF YOU HAVE NO INFO ON THIS, I WOULD LIKE YOUR RECCOMENDATION ON
  1471. AN EXTENSIBLE EDITOR. CAN YOU HELP? I LIKE VERY MUCH WATCOM PACKAGE.
  1472.  
  1473. *** See also #2380.
  1474.  
  1475.  
  1476. From:    David Kennedy                          Rec'd
  1477. To:      Patrick Lamb                           Msg #2378, Feb-10-94 01:37PM
  1478. Subject: unexpected interrupt
  1479.  
  1480.  PL> files are not terribly large; and average is some 500
  1481.  PL> lines, with perhaps 750 included.  When the compiler
  1482.  PL> is invoked (from wmake or from the command line), the
  1483.  PL> computer sits there for 2:30 or so before the compiler
  1484.  PL> comes back with its cheery "Watcom C32 9.5a" response.
  1485.  PL>  After that, the compilation time is normal (maybe 20-
  1486.  PL> 30 seconds).
  1487.  
  1488.  PL> This machine is a 386-20 with 12 Mb of memory; I tried
  1489.  PL> it this morning with a client's compiler on his 486-66
  1490.  PL> with 20 Meg, and it only took about thirty seconds to
  1491.  PL> respond.
  1492.  
  1493. This problem has been reported before, although usually on a Pentium. It is
  1494. being investigated.
  1495.  
  1496. David Kennedy
  1497. WATCOM Languages Support
  1498.  
  1499. *** This is a reply to #2360.  *** See also #2404.
  1500.  
  1501.  
  1502. From:    David Kennedy                          Rec'd
  1503. To:      Ramon Rivas                            Msg #2379, Feb-10-94 02:00PM
  1504. Subject: Multi site license
  1505.  
  1506.  RR> Can somebody give me some info on multisite licensce
  1507.  RR> for WC 9.5. We might be adding a few more developers
  1508.  RR> and, techincally, they each need a copy of WC 9.5.
  1509.  RR> But, maybe, you offer something by which one just pays
  1510.  RR> an amount an receives the necessary documentation
  1511.  RR> without wasting extra sets of disks. Is there anything
  1512.  RR> like this? Thanks.
  1513.  
  1514. We do not provide such an arrangement.
  1515.  
  1516. David Kennedy
  1517. WATCOM Languages Support
  1518.  
  1519. *** This is a reply to #2374.
  1520.  
  1521.  
  1522. From:    David Kennedy                          Rec'd
  1523. To:      Michael Mishoe                         Msg #2380, Feb-10-94 02:04PM
  1524. Subject: EDITOR - INTEGRATED ENVIRONMENT
  1525.  
  1526.  MM> I HAVE BEEN USING MSC 7.0 WITH PWB (PROGRAMMER'S WORKBENCH). I WOULD
  1527.  MM> LIKE TO KNOW IF I CAN CUSTOMIZE IT TO USE WATCOM C/C++ 32 9.5.
  1528.  MM> IF YOU HAVE NO INFO ON THIS, I WOULD LIKE YOUR RECCOMENDATION ON
  1529.  MM> AN EXTENSIBLE EDITOR. CAN YOU HELP? I LIKE VERY MUCH WATCOM PACKAGE.
  1530.  
  1531. If the Programmer's Workbench is generic, then you should be able to integrate
  1532. the WATCOM compiler by modifying the appropriate command strings and options.
  1533. However, if it is designed specifically for MSC 7.0, you will have more
  1534. difficulty in this respect.  There are many good commercial and public domain
  1535. editors on the market, none of which I can specifically recommend off hand.
  1536.  
  1537. David Kennedy
  1538. WATCOM Languages Support
  1539.  
  1540. *** This is a reply to #2376.
  1541.  
  1542.  
  1543. From:    Jim Ehrismann                          Rec'd
  1544. To:      Kevin Kitsemetry                       Msg #2382, Feb-11-94 10:57AM
  1545. Subject: More Graphics support
  1546.  
  1547. Hi Kevin,
  1548.  
  1549.         Does WATCOM have any plans to add support for higher resolution modes
  1550. and/or 24bit colour modes in your C32 for DOS graphics library?
  1551.  
  1552.                                 Jim Ehrismann
  1553.  
  1554. *** See also #2400.
  1555.  
  1556.  
  1557. From:    Justin Luton
  1558. To:      Pat Brown                              Msg #2384, Feb-11-94 02:17PM
  1559. Subject: watcom c/c++ for windows nt
  1560.  
  1561.  
  1562. *** This is a reply to #822.
  1563.  
  1564.  
  1565. From:    Kevin Blenkinsopp                      Rec'd
  1566. To:      Anthony Scian                          Msg #2385, Feb-11-94 02:28PM
  1567. Subject: Weird stuff again
  1568.  
  1569. Anthony,
  1570.  
  1571. I upgraded to the full b-level a while ago, and have found another issue that
  1572. wasn't there with the a-level or the pre-release b-level that I had. This code:
  1573.  
  1574. main() {
  1575.   .
  1576.   .
  1577.   .
  1578.   try {
  1579.     DoSomething();
  1580.   } catch (char *z) {
  1581.     Window win(...);
  1582.     win << z;
  1583.     getch();
  1584.   }
  1585. }
  1586.  
  1587. causes a page fault when it tries to destroy the window (it never actually
  1588. gets to the destructor - looks like a stack unwinding problem?)
  1589.  
  1590. If I replace the catch block with:
  1591.  
  1592.   Window *pwin = new Window(...)
  1593.   *pwin << z;
  1594.  
  1595. then all is fine. A Window is pretty big, by the way, but not huge, and I have
  1596. a 32K stack. I realise I'm not giving you a lot to work with here - I'll try
  1597. and reproduce it in an uploadable file, but I can't promise anything.
  1598.  
  1599. By the way, if I put the creation of the window OUTSIDE the try/catch block,
  1600. that's okay too.
  1601.  
  1602. Hope the weather's better there than it is here.
  1603.  
  1604. Kevin
  1605.  
  1606. *** See also #2389.
  1607.  
  1608.  
  1609. From:    Ramon Rivas
  1610. To:      Tect Support                           Msg #2386, Feb-11-94 03:07PM
  1611. Subject: msg 2369
  1612.  
  1613. Any idea on the problem reported with message 2369?
  1614.  
  1615. Thanks.
  1616.  
  1617.  
  1618. From:    Jon Maiara
  1619. To:      All                                    Msg #2387, Feb-11-94 03:49PM
  1620. Subject: wvideo w/keyboard handler
  1621.  
  1622. i have a program which takes over the keyboard interrupt (int 9). for a while,
  1623. wvideo would completely lose the keyboard after the handler was installed, but
  1624. that was fixed. but after i installed the b level patches, the debugger
  1625. sometimes works, but it sometimes loses input, wedges or reboots.
  1626.  
  1627. *** See also #2402.
  1628.  
  1629.  
  1630. From:    Anthony Scian                          Rec'd
  1631. To:      Kevin Blenkinsopp                      Msg #2389, Feb-11-94 08:20PM
  1632. Subject: Weird stuff again
  1633.  
  1634.  KB> Anthony,
  1635.  
  1636.  KB> I upgraded to the full b-level a while ago, and have
  1637.  KB> found another issue that wasn't there with the a-level
  1638.  KB> or the pre-release b-level that I had. This code:
  1639.  
  1640.  KB> main() {
  1641.  KB>   .
  1642.  KB>   .
  1643.  KB>   .
  1644.  KB>   try {
  1645.  KB>     DoSomething();
  1646.  KB>   } catch (char *z) {
  1647.  KB>     Window win(...);
  1648.  KB>     win << z;
  1649.  KB>     getch();
  1650.  KB>   }
  1651.  KB> }
  1652.  
  1653.  KB> causes a page fault when it tries to destroy the
  1654.  KB> window (it never actually gets to the destructor -
  1655.  KB> looks like a stack unwinding problem?)
  1656.  
  1657. In section 2.3.1.1.4.5.6.7.8 of the ISO/ANSI C++ standard
  1658. it says that this is undefined behaviour so this is (just kidding... :^) I'll
  1659. try to duplicate the problem on this end of things, thanks.
  1660.  
  1661.  
  1662. *** This is a reply to #2385.
  1663.  
  1664.  
  1665. From:    Matt Howard
  1666. To:      All                                    Msg #2390, Feb-11-94 10:04PM
  1667. Subject: Mem Alloc Error and Asm Questions
  1668.  
  1669. First of all, I would like to say that I am at least initially impressed with
  1670. the Watcom Compiler. However, I would still have a few questions.
  1671.  
  1672.         1. When converting a screen saver program to Watcom, every thing works
  1673. until at the end, I get the error:
  1674.         "Memory Allocation Error"
  1675.         "Cannot load COMMAND, system halted"
  1676. I should note that my tests indicate the actual program finishes before this
  1677. error occurs. I'm not sure whats wrong since:
  1678. a. this didn't occur with a certain "other" 16-bit compiler and
  1679. b. I've check through the program to make sure no memory is left dangling
  1680.  
  1681.         2. Just an asm question. What should I do when asm instructions
  1682. require a segment:offset pair in an instruction. For example, how would I do
  1683. "rep movsw" with watcom pointers. I tried just loading the offset when calling
  1684. a BIOS interrupt(that required a seg:off pointer), and oddly, it worked for
  1685. one program but in another, it caused the computer to reboot itself. Any ideas?
  1686.  
  1687. *** See also #2415.
  1688.  
  1689.  
  1690. From:    Amine Moulay Ramdane                   Rec'd
  1691. To:      Kevin Kitsemetry                       Msg #2391, Feb-12-94 03:56AM
  1692. Subject: Ntheader.zip - excpt.h
  1693.  
  1694. Hi Mr.Kevin is there any chance to get the header file except.h
  1695. that doesn't exist in the ntheader.zip .
  1696. Thanks .
  1697.  
  1698. *** See also #2416.
  1699.  
  1700.  
  1701. From:    Jon Fleming                            Rec'd
  1702. To:      Kevin Kitsemetry                       Msg #2392, Feb-12-94 07:10AM
  1703. Subject: Optimization selection
  1704.  
  1705.      I'm an inexperienced C programmer with lots of experience in other
  1706. languages.  I've written an AutoCAD ADS program using Watcom 9.5.
  1707.      In this program, the sqrt function is called three times.  Each instance
  1708. is in the same form:
  1709.  
  1710.  var = sqrt(a*a + b*b + c*c);
  1711.  
  1712. which certainly should not be negative.
  1713.  
  1714.      If I compile it with the following command line:
  1715.  
  1716. wcc386 /fpi87 /3s /oe=40 /oi /ol /or /ot %1.c
  1717.  
  1718. then one user of the program reports lots of "domain error in sqrt" messages,
  1719. but the program appears to operate properly.  If I compile with only the first
  1720. two switches, the "domain error" messages go away.
  1721.      The user is in the UK with a 2400 baud modem.  He can afford only the
  1722. occasional download.
  1723.      Which of those switches should I use and which should I not use?
  1724.  
  1725. jrf
  1726.  
  1727. *** See also #2417.
  1728.  
  1729.  
  1730. From:    Mike Johnson
  1731. To:      All                                    Msg #2393, Feb-11-94 05:20PM
  1732. Subject: wpp386 patch level?
  1733.  
  1734. Well I got the c32dos_b.zip file and ran applyb and patched the compiler.
  1735.  
  1736. when I ran techinfo, all the files listed except wpp386.exe were patched
  1737. to level b and wpp386.exe stayed at level a.  Is this correct ?
  1738.  
  1739.  
  1740.  
  1741. .
  1742. ___
  1743.  X DeLuxe2/386 1.25 #10176 X Machines of Loving Grace
  1744.  
  1745. *** See also #2418.
  1746.  
  1747.  
  1748. From:    Thomas B. Pollard                      Rec'd
  1749. To:      Kevin Kitsemetry                       Msg #2396, Feb-14-94 09:18AM
  1750. Subject: C/C++ 9.5A Wvideo interrup with <SyRq>
  1751.  
  1752. TO Watcom 519-747-4971
  1753. FROM Tom Pollard 617-275-0100 Ex127
  1754. C/C++ 9.5B Wvideo interrupt using <Print Screen> problem
  1755. |
  1756. Just to let you know that the problem is still in your 9.5B patch
  1757. still has the same problem.  Before I added the B patches I over
  1758. wrote the working RSIHELP.EXP (27064 2-16-93) with the A patch
  1759. RSIHELP.EXP (27064 8-27-93) and applied the B patches.  I then had
  1760. the same problems as before.  I then used the 9.5 LA RSIHELP.EXP
  1761. (27064 2-16-93) and once again fixed the problem.
  1762.  
  1763.  
  1764. *** This is a reply to #1977.  *** See also #2419.
  1765.  
  1766.  
  1767. From:    David Kennedy
  1768. To:      Brian Burton                           Msg #2399, Feb-14-94 12:02PM
  1769. Subject: filename in NT
  1770.  
  1771.  BB> Internal report #16903
  1772.  
  1773.  BB> The NT hosted tools do not handle long file names
  1774.  BB> properly. wcl386 truncates longfilename.obj to
  1775.  BB> longfilenam and then
  1776.  BB> searches for longfilenam.cxx/cpp/cc/c.  This is a
  1777.  BB> major annoyance since I prefer to name source files
  1778.  BB> after the class that they implement and I don't want
  1779.  BB> short class names.  It seems like a trivial fix.  Does
  1780.  BB> Watcom have any plans to address this problem?
  1781.  BB> ++Brian
  1782.  
  1783. The tools now all support long filenames under Windows NT.  Note that you must
  1784. be using the NT-hosted tools located in the BINNT directory. This support was
  1785. added with version 9.0b.
  1786.  
  1787. David Kennedy
  1788. WATCOM Languages Support
  1789.  
  1790. *** This is a reply to #2350.
  1791.  
  1792.  
  1793. From:    David Kennedy                          Rec'd
  1794. To:      Jim Ehrismann                          Msg #2400, Feb-14-94 12:22PM
  1795. Subject: More Graphics support
  1796.  
  1797.  JE> Hi Kevin,
  1798.  
  1799.  JE>         Does WATCOM have any plans to add support for
  1800.  JE> higher resolution modes
  1801.  JE> and/or 24bit colour modes in your C32 for DOS graphics library?
  1802.  
  1803.  JE>                                 Jim Ehrismann
  1804.  
  1805. WATCOM does not support, nor does it plan to support 24-bit colour modes.
  1806. There are several good third-party libraries that provide this support.
  1807.  
  1808. David Kennedy
  1809. WATCOM Languages Support
  1810.  
  1811. *** This is a reply to #2382.
  1812.  
  1813.  
  1814. From:    David Kennedy                          Rec'd
  1815. To:      Kevin Blenkinsopp                      Msg #2401, Feb-14-94 12:28PM
  1816. Subject: Weird stuff again
  1817.  
  1818.  KB> I realise I'm
  1819.  KB> not giving you a lot to work with here - I'll try and
  1820.  KB> reproduce it in an uploadable file, but I can't
  1821.  KB> promise anything.
  1822.  
  1823. If you could try to produce a small working example we will try to diagnose
  1824. the problem.
  1825.  
  1826. David Kennedy
  1827. WATCOM Languages Support
  1828.  
  1829. *** This is a reply to #2385.
  1830.  
  1831.  
  1832. From:    David Kennedy                          Rec'd
  1833. To:      Jon Maiara                             Msg #2402, Feb-14-94 12:32PM
  1834. Subject: wvideo w/keyboard handler
  1835.  
  1836.  JM> i have a program which takes over the keyboard
  1837.  JM> interrupt (int 9). for a while, wvideo would
  1838.  JM> completely lose the keyboard after the handler was
  1839.  JM> installed, but that was fixed. but after i installed
  1840.  JM> the b level patches, the debugger sometimes works, but
  1841.  JM> it sometimes loses input, wedges or reboots.
  1842.  
  1843. Would it be possible to upload a small example of the code, and specify which
  1844. debugger and tools you are using (I assume DOS).  This will help us to more
  1845. easily diagnose the problem.
  1846.  
  1847. David Kennedy
  1848. WATCOM Languages Support
  1849.  
  1850. *** This is a reply to #2387.
  1851.  
  1852.  
  1853. From:    JAM Productions
  1854. To:      All                                    Msg #2403, Feb-14-94 01:40PM
  1855. Subject: ALLFILES listing
  1856.  
  1857. Could someone tell me if there's a listing of all files on this BBS
  1858. (ie: ALLFILES.xxx) that I could download and browse through?
  1859.  
  1860. Jam Productions
  1861.  
  1862. *** See also #2420.
  1863.  
  1864.  
  1865. From:    Patrick Lamb                           Rec'd
  1866. To:      David Kennedy                          Msg #2404, Feb-14-94 06:36PM
  1867. Subject: unexpected interrupt
  1868.  
  1869. The slow response problem on the 386 was apparently fixed by the "B" level
  1870. patches.  I'll get back to you later on the '486 response.
  1871.  
  1872. Thanks for your help!
  1873.  
  1874. Pat
  1875.  
  1876. *** This is a reply to #2378.
  1877.  
  1878.  
  1879. From:    John Lansdale                          Rec'd
  1880. To:      Kevin Kitsemetry                       Msg #2405, Feb-15-94 01:04AM
  1881. Subject: Exporting variables from a NT DLL
  1882.  
  1883. I've finally got Watcom to compile and link Windows NT DLLs that work
  1884. ok under Win32s. However, I have one small problem with exported
  1885. variables from the DLL:
  1886.  
  1887. 1) First, is it possible to export global variables found in a Windows
  1888.         NT DLL?
  1889. 2) I assumed it was ok, so I explicitly exported them using the EXPORT
  1890.         linker keyword.
  1891. 3) My code crashes now whenever it accesses one of these exported variables.
  1892.  
  1893.  
  1894. My questions:
  1895.  
  1896.         1) Why is my code crashing.
  1897.         2) What is the simplest method to export several hundred global
  1898.                 variables from a DLL? I don't want to explicitly export
  1899.                        the variables using the linker. I've tried using
  1900.                         "C-Var-Type __export Variable_Name" in my code
  1901.                         but it won't export the name for some reason.
  1902.  
  1903. John Lansdale
  1904.  
  1905. *** See also #2421.
  1906.  
  1907.  
  1908. From:    Glenn Crownover
  1909. To:      All                                    Msg #2406, Feb-15-94 03:55AM
  1910. Subject: Bank Switching in 640x480x256
  1911.  
  1912. I was wondering what the proper way to switch video banks (64k pages)
  1913. in 640x480 x 256color mode was.  I am using _setvideomode(VRES256COLOR)
  1914. to initialize the mode.  I have had some luck with some cards with
  1915. int 10, but was wondering if there was a way to have the Watcom
  1916. graphics library do it.
  1917.  
  1918. Thanks.
  1919.  
  1920. *** See also #2412.
  1921.  
  1922.  
  1923. From:    David Kennedy                          Rec'd
  1924. To:      Joseph Molnar                          Msg #2407, Feb-15-94 10:24AM
  1925. Subject: Problem
  1926.  
  1927.  JM> Having a slight problem with token pasteing(?).  I am
  1928.  JM> doing some unicode stuff under NT, and as you might
  1929.  JM> know MS creates a MACRO that they put in front of all
  1930.  JM> strings so they can choose whether or not to make is
  1931.  JM> ASCII or UNICODE across compiles.  It isn't working
  1932.  JM> well, the string is returning a char* instead of long
  1933.  JM> char*.
  1934.  
  1935. Note that the type of L"string" is specified as an array of wchar_t as defined
  1936. in <stddef.h>  By default this is char, but changes to long char if _cplusplus
  1937. is defined (ie. if you invoke wpp386).  Long char is two bytes long, as it
  1938. should be.  Note that <stddef.h> IS included by including <windows.h>
  1939.  
  1940.  JM> Also I was curious about the funny, is it possible for
  1941.  JM> MS C8 code to be debugged by WVIDEO, and for WinBug
  1942.  JM> (NT's debugger) to debug W9.5 NT code?
  1943.  
  1944. There is no way to convert MSC debugging information to WATCOM debug
  1945. infomation. However, the WOMP utility allows conversion of WATCOM debug
  1946. information to MS CodeView, Metaware, or Borland debugging information.
  1947.  
  1948. David Kennedy
  1949. WATCOM Languages Support
  1950.  
  1951. *** This is a reply to #2346.  *** See also #2451.
  1952.  
  1953.  
  1954. From:    David Kennedy                          Rec'd
  1955. To:      Jim Gerow                              Msg #2408, Feb-15-94 10:47AM
  1956. Subject: WLINK has problems with 16-bit modules when in 32-bit mode
  1957.  
  1958.  JG> Kevin,
  1959.  JG>     We also have the problem when linking for DOS-32.
  1960.  JG>  Could you also check if development knows a work-
  1961.  JG> around.  We're all set setting up a proper 16-bit
  1962.  JG> environment, (stack & data areas), but need to have
  1963.  JG> the relocation fixups to be properly formed as 16:16
  1964.  JG> addresses, not as a 0:32 linear address.
  1965.  
  1966.  JG> Thanks
  1967.  
  1968. B-level: A bug in handling 16-bit relocations in 32-bit code that prevented
  1969. programs from loading has been corrected.
  1970.  
  1971. David Kennedy
  1972. WATCOM Languages Support
  1973.  
  1974. *** This is a reply to #2372.  *** See also #2414.
  1975.  
  1976.  
  1977. From:    David Kennedy
  1978. To:      Ross Linder                            Msg #2409, Feb-15-94 10:54AM
  1979. Subject: Wcc386 & DesqviewX
  1980.  
  1981. Line trouble, worked fine.
  1982.  
  1983. David Kennedy
  1984. WATCOM Languages Support
  1985.  
  1986. *** This is a reply to #2373.
  1987.  
  1988.  
  1989. From:    Michael Mishoe                         Rec'd
  1990. To:      Glenn Crownover                        Msg #2412, Feb-15-94 02:50PM
  1991. Subject: Bank Switching in 640x480x256
  1992.  
  1993. see file newvesa.c
  1994.  
  1995.  
  1996. *** This is a reply to #2406.  *** See also #2413.
  1997.  
  1998.  
  1999. From:    Glenn Crownover                        Rec'd
  2000. To:      Michael Mishoe                         Msg #2413, Feb-16-94 05:16AM
  2001. Subject: Bank Switching in 640x480x256
  2002.  
  2003. Thanks for the reference.  I can not find, however, this newvesa.c
  2004. Where is it?
  2005.  
  2006. Thanks again in advance.
  2007. -Glenn
  2008.  
  2009. *** This is a reply to #2412.  *** See also #2423.
  2010.  
  2011.  
  2012. From:    Jim Gerow                              Rec'd
  2013. To:      David Kennedy                          Msg #2414, Feb-16-94 08:26AM
  2014. Subject: WLINK has problems with 16-bit modules when in 32-bit mode
  2015.  
  2016. Yes, the Rational DOS-extender has been fixed so that it doesn't abort when
  2017. loading, however, the relocation fix-ups that are done on the addresses within
  2018. the 16-bit code are wrong.  We can get 32-bit code to call the 16-bit code,
  2019. as well as use an operand size override to return properly, however, the fix-
  2020. ups within the 16-bit modules are computed using the flat (0:32) model when
  2021. they should be using the LARGE (16:16) model.  The effect is that the first 16-
  2022. bit far call [to another 16-bit function within the 3rd party library] results
  2023. in a crash.
  2024.  
  2025. (i.e. The previously uploaded test case still fails.)
  2026. If you need any more clarifications, or if there's a work-around, please
  2027. contact me here or at 617/229-2924.
  2028.  
  2029. Thanks
  2030.  
  2031. *** This is a reply to #2408.  *** See also #2425.
  2032.  
  2033.  
  2034. From:    Kevin Kitsemetry                       Rec'd
  2035. To:      Matt Howard                            Msg #2415, Feb-16-94 09:35AM
  2036. Subject: Mem Alloc Error and Asm Questions
  2037.  
  2038.  MH>         1. When converting a screen saver program to
  2039.  MH> Watcom, every thing works until at the end, I get the
  2040.  MH> error:
  2041.  MH>         "Memory Allocation Error"
  2042.  MH>         "Cannot load COMMAND, system halted"
  2043.  MH> I should note that my tests indicate the actual
  2044.  MH> program finishes before this error occurs. I'm not
  2045.  MH> sure whats wrong since:
  2046.  MH> a. this didn't occur with a certain "other" 16-bit compiler and
  2047.  MH> b. I've check through the program to make sure no memory is left dangling
  2048.  
  2049. Try tracing through the program in the debugger.  This will allow you to see
  2050. for certain just where the program is crashing.  If your program has finished,
  2051. perhaps there is an error with the exit routines.
  2052.  
  2053.  
  2054.  MH>         2. Just an asm question. What should I do when
  2055.  MH> asm instructions require a segment:offset pair in an
  2056.  MH> instruction. For example, how would I do "rep movsw"
  2057.  MH> with watcom pointers. I tried just loading the offset
  2058.  MH> when calling a BIOS interrupt(that required a seg:off
  2059.  MH> pointer), and oddly, it worked for one program but in
  2060.  MH> another, it caused the computer to reboot itself. Any
  2061.  MH> ideas?
  2062.  
  2063. You can specify the extended register for the 386.  This means that ax will
  2064. become eax, bx will become ebx, etc.  There are times when you will only want
  2065. to specify the lower order word registers (ex, bx, etc.) such as when you wan
  2066. to execute code in real mode.
  2067.  
  2068. Note that the segment registers are the same size in real mode as in protected
  2069. mode.  So when issuing instructions that involve these registers, the low-
  2070. order word register is all that is needed. For example, getting the current
  2071. stack segment would be the same in real mode as in protected mode:    'mov
  2072. dx,ss'.
  2073.  
  2074.  
  2075. Kevin Kitsemetry
  2076. WATCOM TECHNICAL SUPPORT
  2077.  
  2078. *** This is a reply to #2390.
  2079.  
  2080.  
  2081. From:    Kevin Kitsemetry                       Rec'd
  2082. To:      Amine Moulay Ramdane                   Msg #2416, Feb-16-94 09:56AM
  2083. Subject: Ntheader.zip - excpt.h
  2084.  
  2085.  AMR> Hi Mr.Kevin is there any chance to get the header file except.h
  2086.  AMR> that doesn't exist in the ntheader.zip .
  2087.  
  2088. This file is now in the ntheader.zip archive.  It was left out by accident in
  2089. the previous archive.
  2090.  
  2091.  
  2092. Kevin Kitsemetry
  2093. WATCOM TECHNICAL SUPPORT
  2094.  
  2095. *** This is a reply to #2391.
  2096.  
  2097.  
  2098. From:    Kevin Kitsemetry                       Rec'd
  2099. To:      Jon Fleming                            Msg #2417, Feb-16-94 09:59AM
  2100. Subject: Optimization selection
  2101.  
  2102.  JF>      I'm an inexperienced C programmer with lots of
  2103.  JF> experience in other languages.  I've written an
  2104.  JF> AutoCAD ADS program using Watcom 9.5.
  2105.  JF>      In this program, the sqrt function is called
  2106.  JF> three times.  Each instance is in the same form:
  2107.  JF>
  2108.  JF>  var = sqrt(a*a + b*b + c*c);
  2109.  JF>
  2110.  JF> which certainly should not be negative.
  2111.  JF>
  2112.  JF>      If I compile it with the following command line:
  2113.  JF>
  2114.  JF> wcc386 /fpi87 /3s /oe=40 /oi /ol /or /ot %1.c
  2115.  JF>
  2116.  JF>      Which of those switches should I use and which should I not use?
  2117.  
  2118. There have been some updates to the code generator in the latest revision,
  2119. patch level 'b'.  Please make sure that you have this applied, as it may solve
  2120. the problem altogether.  If this does not work, you can use the default
  2121. switches to be safe.  We would be interested in trying to reproduce the
  2122. example here (after you have applied the 'b' level patches) in hopes that we
  2123. could rectify the problem.
  2124.  
  2125.  
  2126. Kevin Kitsemetry
  2127. WATCOM TECHNICAL SUPPORT
  2128.  
  2129. *** This is a reply to #2392.  *** See also #2432.
  2130.  
  2131.  
  2132. From:    Kevin Kitsemetry                       Rec'd
  2133. To:      Mike Johnson                           Msg #2418, Feb-16-94 10:02AM
  2134. Subject: wpp386 patch level?
  2135.  
  2136.  MJ> Well I got the c32dos_b.zip file and ran applyb and patched the compiler.
  2137.  
  2138.  MJ> when I ran techinfo, all the files listed except wpp386.exe were patched
  2139.  MJ> to level b and wpp386.exe stayed at level a.  Is this correct ?
  2140.  
  2141. C32DOS_B.ZIP is the archive for the WATCOM C32 for DOS compiler.  If you have
  2142. the WATCOM C/C++32 compiler, then you have to apply the patch in the C32_B.ZIP
  2143. archive.
  2144.  
  2145.  
  2146. Kevin Kitsemetry
  2147. WATCOM TECHNICAL SUPPORT
  2148.  
  2149. *** This is a reply to #2393.
  2150.  
  2151.  
  2152. From:    Kevin Kitsemetry                       Rec'd
  2153. To:      Thomas B. Pollard                      Msg #2419, Feb-16-94 10:13AM
  2154. Subject: C/C++ 9.5A Wvideo interrup with <SyRq>
  2155.  
  2156.  TBP> TO Watcom 519-747-4971
  2157.  TBP> FROM Tom Pollard 617-275-0100 Ex127
  2158.  TBP> C/C++ 9.5B Wvideo interrupt using <Print Screen> problem
  2159.  TBP> |
  2160.  TBP> Just to let you know that the problem is still in your 9.5B patch
  2161.  TBP> still has the same problem.  Before I added the B patches I over
  2162.  TBP> wrote the working RSIHELP.EXP (27064 2-16-93) with the A patch
  2163.  TBP> RSIHELP.EXP (27064 8-27-93) and applied the B patches.  I then had
  2164.  TBP> the same problems as before.  I then used the 9.5 LA RSIHELP.EXP
  2165.  TBP> (27064 2-16-93) and once again fixed the problem.
  2166.  
  2167. Yes, I knew that the problem has been fixed for the new debugger in the next
  2168. version, but it was not fixed for the 'b' level patches to 9.5. Fixing version
  2169. 9.5 is not a trivial job apparently.
  2170.  
  2171.  
  2172. Kevin Kitsemetry
  2173. WATCOM TECHNICAL SUPPORT
  2174.  
  2175. *** This is a reply to #2396.
  2176.  
  2177.  
  2178. From:    Kevin Kitsemetry
  2179. To:      JAM Productions                        Msg #2420, Feb-16-94 11:32AM
  2180. Subject: ALLFILES listing
  2181.  
  2182.  JP> Could someone tell me if there's a listing of all files on this BBS
  2183.  JP> (ie: ALLFILES.xxx) that I could download and browse through?
  2184.  
  2185. I have just created a rather cude listing.  You can find it in the General
  2186. File area.
  2187.  
  2188.  
  2189. Kevin Kitsemetry
  2190. WATCOM TECHNICAL SUPPORT
  2191.  
  2192. *** This is a reply to #2403.
  2193.  
  2194.  
  2195. From:    Kevin Kitsemetry                       Rec'd
  2196. To:      John Lansdale                          Msg #2421, Feb-16-94 11:34AM
  2197. Subject: Exporting variables from a NT DLL
  2198.  
  2199.  JL> I've finally got Watcom to compile and link Windows NT DLLs that work
  2200.  JL> ok under Win32s. However, I have one small problem with exported
  2201.  JL> variables from the DLL:
  2202.  
  2203.  JL> 1) First, is it possible to export global variables found in a Windows
  2204.  JL>         NT DLL?
  2205.  
  2206. Currently, we only support exporting functions from Windows NT DLL's. See the
  2207. Linker Supplement for details.
  2208.  
  2209.  
  2210. Kevin Kitsemetry
  2211. WATCOM TECHNICAL SUPPORT
  2212.  
  2213. *** This is a reply to #2405.
  2214.  
  2215.  
  2216. From:    Kevin Kitsemetry                       Rec'd
  2217. To:      Glenn Crownover                        Msg #2423, Feb-16-94 12:14PM
  2218. Subject: Bank Switching in 640x480x256
  2219.  
  2220.  GC> Thanks for the reference.  I can not find, however, this newvesa.c
  2221.  GC> Where is it?
  2222.  
  2223. You can find it in File area 10.
  2224.  
  2225.  
  2226. Kevin Kitsemetry
  2227. WATCOM TECHNICAL SUPPORT
  2228.  
  2229. *** This is a reply to #2413.
  2230.  
  2231.  
  2232. From:    Jim Gerow                              Rec'd
  2233. To:      David Kennedy                          Msg #2425, Feb-16-94 02:25PM
  2234. Subject: WLINK has problems with 16-bit modules when in 32-bit mode
  2235.  
  2236. I uploaded a simple test case: test16.zip that highlights the relocation fixup
  2237. problem. I hope either your tech support or Rational's can solve it. (I also
  2238. posted a message to Rational in area 15).
  2239.  
  2240. Thanks
  2241.  
  2242. *** This is a reply to #2414.
  2243.  
  2244.  
  2245. From:    Jason Blochowiak                       Rec'd
  2246. To:      Kevin Kitsemetry                       Msg #2427, Feb-16-94 04:17PM
  2247. Subject: 16-bit fixup problems
  2248.  
  2249.  Hi. This is just a note to mention that I'm also experiencing 16-bit fixup
  2250. problems. Although I'm not sure if they're exactly the same thing that Jim
  2251. Gerow is running into, it certainly sounds like it. I've written some code
  2252. that gets copied down into real mode memory, and then I patch an interrupt
  2253. handler to point to it. It's supposed to do a signature check - if it
  2254. succeeds,special code gets executed, if it fails, it does a JMP to chain to
  2255. the previously installed handler. The address of the indirect chain jump gets
  2256. screwed up, which I've verified under SoftICE/W and WVIDEO (although I had to
  2257. do a hex dump & hand disassembly in WVIDEO - ahem). I was going to whittle the
  2258. program down to the minimum size necessary to reproduce the problem, but it
  2259. sounds like Mr. Gerow has already done so.
  2260.  
  2261.  Jason
  2262.  
  2263. *** See also #2438.
  2264.  
  2265.  
  2266. From:    Kevin Blenkinsopp                      Rec'd
  2267. To:      Anthony Scian                          Msg #2428, Feb-16-94 07:38PM
  2268. Subject: I'm baaack!
  2269.  
  2270. /*
  2271.  
  2272. Anthony,
  2273.  
  2274. I've got a beauty for you here: I was rather surprised when all my windows
  2275. came up looking they had the focus, but I was REALLY surprised when I figured
  2276. out why...
  2277.  
  2278. */
  2279.  
  2280.  
  2281. typedef int Bool;
  2282. typedef unsigned char Byte;
  2283.  
  2284. class Window {
  2285. public:
  2286.   void Frame(void);
  2287.   Bool HasFocus(void);
  2288.   Byte mbBorder;
  2289. };
  2290.  
  2291. void Window::Frame(void)
  2292. {
  2293.   Byte bTitleColour = (Byte)((mbBorder & 0xF0) | (HasFocus ? 0x0F : 0x0E));
  2294.                                                           ^
  2295.                                                           ^
  2296.                          What's wrong with this picture ? ^ }
  2297.  
  2298.  
  2299. /*
  2300.  
  2301. I know I'm pretty tired and stupid right now, but I have a strong suspicion
  2302. that this shouldn't have compiled!
  2303.  
  2304. BTW: Tried to reproduce that unrolling problem in a snippet but couldn't do
  2305. it. Dropped the stack to 20K with the working version and it still worked, so
  2306. it's not a stack size problem. At least THIS one's easy to duplicate.
  2307.  
  2308. BTW II: Do I officially qualify as a pest yet?! :-)
  2309.  
  2310. Thanks,
  2311.  
  2312. Kevin
  2313.  
  2314. */
  2315.  
  2316. *** See also #2437.
  2317.  
  2318.  
  2319. From:    Jon Fleming                            Rec'd
  2320. To:      Kevin Kitsemetry                       Msg #2432, Feb-21-94 09:53AM
  2321. Subject: Optimization selection
  2322.  
  2323.      I've downloaded & applied the A and B patches.  I'll do some
  2324. investigation.
  2325.  
  2326.      BTW, there's one bothersome but unimportant nit.  WLINK announces that is
  2327. is creating an "AutoCAD Devlopment System Executable".  Note the spelling of
  2328. the second word.  (I havent't tried WLINK since applying the patches).
  2329.  
  2330. jrf
  2331.  
  2332. *** This is a reply to #2417.  *** See also #2440.
  2333.  
  2334.  
  2335. From:    Julian Ayling
  2336. To:      Technical Support                      Msg #2433, Feb-21-94 03:50PM
  2337. Subject: DPMI Memory mapping
  2338.  
  2339. KK> Spoke to on phone
  2340.  
  2341.  
  2342. Hi,
  2343.         I've got another problem for you. I'm trying to map some memory
  2344.         on a card so that I can access the data using DPMI function
  2345.         0x800. I've looked at the example file accmem.c that shows how
  2346.         to do this, but am unable to get my version to work.
  2347.  
  2348.         The actual int386 functions appear to be working correctly, the
  2349.         carry flag is clear after each one but the data that I am
  2350.         getting hold of is either all 0x00, 0xFF or apparantly random
  2351.         values. I know what the data should be by using debug to
  2352.         effectively perform the same memory remapping for me and then
  2353.         viewing the data - basically it tells me that the correct card
  2354.         is available.
  2355.  
  2356.         I know I'm not supposed to put bits of code in the message
  2357.         section but it's very small, so here it is.
  2358.  
  2359. main()
  2360. {
  2361. CARDPTR iface;
  2362. int status, i;
  2363. unsigned short selector;
  2364. unsigned short linhi;
  2365. unsigned short linlo;
  2366. union REGS regs;
  2367. unsigned char __far *xxx;
  2368.  
  2369. BaseAddr = 0xe0000000;
  2370. WrongRead = 0;
  2371. Neg = 0;
  2372. DprAddr = 0xe000ff00;
  2373. IoBase = 0x300;
  2374. IntLev = 5;
  2375.  
  2376. printf("Reseting card\n");
  2377. status = outp(IoBase + REG3, 0);/* Reset Card
  2378. printf("status = %d\n",status);
  2379. printf("Mapping card into pc memory.\n");
  2380. status = outp(IoBase + MAPIN,0); printf("status = %d\n",status);
  2381.  
  2382.    /* DPMI function 0800h -- Physical Address Mapping */
  2383.    /* Map 128 bytes of Physical Address Space starting at 0xe000ff00 */
  2384.    regs.w.ax=0x0800;
  2385.    regs.w.bx=0xe000;
  2386.    regs.w.cx=0xff00;
  2387.    regs.w.si=0x0000;
  2388.    regs.w.di=0x0080;
  2389.    int386(0x31,®s,®s);
  2390.    if ( regs.x.cflag == 0u )
  2391.    {
  2392.       linhi = regs.w.bx;
  2393.       linlo = regs.w.cx;
  2394.    }
  2395.    else
  2396.    {
  2397.       selector = 0;
  2398.    }
  2399.  
  2400.    /* DPMI function 0000h -- Allocate LDT descriptor */
  2401.    /* The default limit on the new descriptor will be zero */
  2402.    regs.w.ax=0x0000;
  2403.    regs.w.cx=1;
  2404.    int386(0x31,®s,®s);
  2405.    if ( regs.x.cflag == 0u )
  2406.    {
  2407.       selector = regs.w.ax;
  2408.    }
  2409.    else
  2410.    {
  2411.       selector = 0;
  2412.    }
  2413.    /* DPMI function 0007h -- Change base address of new selector */
  2414.    regs.w.ax=0x0007;
  2415.    regs.w.bx=selector;
  2416.    regs.w.cx=linhi;
  2417.    regs.w.dx=linlo;
  2418.    int386(0x31,®s,®s);
  2419.    if ( regs.x.cflag == 0u )
  2420.    {
  2421.        puts("Success allocating new descriptor");
  2422. ___
  2423.  X SLMR 2.1a X
  2424.    }
  2425.    else
  2426.    {
  2427.        puts("Failed allocating");
  2428.    }
  2429.    /* DPMI function 0008h -- set selector limit to 64k */
  2430.    regs.w.ax=0x0008;
  2431.    regs.w.bx=selector;
  2432.    regs.w.cx=0x0000;
  2433.    regs.w.dx=0xffff;
  2434.    int386(0x31,®s,®s);
  2435.    if ( regs.x.cflag == 0u )
  2436.    {
  2437.       puts("Success changing limit of new descriptor");
  2438.    }
  2439.    else
  2440.    {
  2441.       puts("Failed changing limit");
  2442.    }
  2443.  
  2444.    sleep(3);
  2445.  
  2446.    /* dump the first 32 bytes of the mapped memory */
  2447.  
  2448.    /*********************************************************************/
  2449.    /* This does not give the correct result - we get all 0x00 or all    */
  2450.    /* 0xff or random vlues                                              */
  2451.    /*********************************************************************/
  2452.  
  2453.    xxx = MK_FP(selector,0);
  2454.    for ( i=0;  i<32; i++)
  2455.    {
  2456.       if (i % 8 == 0)
  2457.       {
  2458.          printf("\n");
  2459.       }
  2460.       printf("%x:",*(xxx+i));
  2461.    }
  2462. }
  2463.  
  2464.    AS you can see it's pretty much the same as ACCMEM.C.
  2465.  
  2466.    When I finally generate the pointer using MK_FP I have to modify xxx
  2467.    with the far modifier otherwise the compiller complains about MK_FP
  2468.    causing a pointer truncation. I'm not quite sure why this needs to be
  2469.    far when the code is 32 bit flat - but it was in the example code.
  2470.  
  2471.    Do you have any sugestions why this is not working.
  2472.  
  2473. ___
  2474.  X SLMR 2.1a X
  2475. ___
  2476.  X SLMR 2.1a X
  2477.  
  2478. *** See also #2435.
  2479.  
  2480.  
  2481. From:    Kevin Blenkinsopp                      Rec'd
  2482. To:      Julian Ayling                          Msg #2435, Feb-17-94 05:39PM
  2483. Subject: DPMI Memory mapping
  2484.  
  2485. Julian,
  2486.  
  2487. I have a similar problem with a card that maps in at 0xC0000000. I don't have
  2488. any suggestions for you, but if you find a solution I'd be very glad to hear
  2489. about it. I thought maybe it was a problem with the selector access rights,
  2490. but I couldn't get anywhere with that either. That doesn't mean that it isn't,
  2491. mind you, but I had a workaround for the board in question that let me map 64K
  2492. of it low at a time, and I was up against a deadline so I just gave up on the
  2493. DPMI stuff. BTW, I tried it with 386MAX and QEMM as the DPMI manager and got
  2494. the same results, so I'm pretty sure it's not a DOS4G problem.
  2495.  
  2496. You might want to try posting this in the DOS4G area anyway, as Dan Teven may
  2497. have some bright ideas.
  2498.  
  2499. Anyway, best of luck. Please let me know if you figure it out.
  2500.  
  2501. Thanks,
  2502.  
  2503. Kevin
  2504.  
  2505. *** This is a reply to #2433.
  2506.  
  2507.  
  2508. From:    Chris Boogmans                         Rec'd
  2509. To:      David Kennedy                          Msg #2436, Feb-18-94 05:53AM
  2510. Subject: _harderr() problem
  2511.  
  2512. Hi,
  2513. i am using C32 version 9.5b in a DOS+DOS/4GW environment. Following a problem
  2514. i had when installing a critical error handler using _harderr(), i had a look
  2515. at the assembly code which is called on int 24h. DOS passes a pointer to the
  2516. device header in BP:SI. The WatCom library has to convert this pointer to a
  2517. pointer in the flat model; this is the part of the WatCom lib code which should
  2518. do that (try it if BP:SI is for example = 0FFF:0010) :
  2519.  sub  ebx, ebx
  2520.  mov  bx, bp
  2521.  shl  ebx, 4
  2522.  add  bx, si        ; here, the carry (if any) gets lost, RESULT = WRONG
  2523. POINTER
  2524. Could this be corrected for the c level patches ?
  2525. Thanks, Chris.
  2526.  
  2527.  
  2528. From:    Anthony Scian                          Rec'd
  2529. To:      Kevin Blenkinsopp                      Msg #2437, Feb-18-94 09:32AM
  2530. Subject: I'm baaack!
  2531.  
  2532.  KB> /*
  2533.  
  2534.  KB> Anthony,
  2535.  
  2536.  KB> I've got a beauty for you here: I was rather surprised
  2537.  KB> when all my windows came up looking they had the
  2538.  KB> focus, but I was REALLY surprised when I figured out
  2539.  KB> why...
  2540.  
  2541.  KB> */
  2542.  
  2543. I'll look at this one.  I think we can at least print out a warning. The
  2544. unadorned id 'HasFocus' is being treated as a member pointer and being
  2545. compared against 0.  This is strictly speaking an extension to C++ but it is
  2546. in the compiler because the MFC library requires it.
  2547.  
  2548.  
  2549.  KB> typedef int Bool;
  2550.  KB> typedef unsigned char Byte;
  2551.  
  2552.  KB> class Window {
  2553.  KB> public:
  2554.  KB>   void Frame(void);
  2555.  KB>   Bool HasFocus(void);
  2556.  KB>   Byte mbBorder;
  2557.  KB> };
  2558.  
  2559.  KB> void Window::Frame(void)
  2560.  KB> {
  2561.  KB>   Byte bTitleColour = (Byte)((mbBorder & 0xF0) |
  2562.  KB> (HasFocus ? 0x0F : 0x0E));
  2563.  KB>                                                           ^
  2564.  KB>                                                           ^
  2565.  KB>                          What's wrong with this picture ? ^ }
  2566.  
  2567. *** This is a reply to #2428.  *** See also #2441.
  2568.  
  2569.  
  2570. From:    Kevin Kitsemetry                       Rec'd
  2571. To:      Jason Blochowiak                       Msg #2438, Feb-18-94 11:14AM
  2572. Subject: 16-bit fixup problems
  2573.  
  2574.  JB> disassembly in WVIDEO - ahem). I was going to whittle
  2575.  JB> the program down to the minimum size necessary to
  2576.  JB> reproduce the problem, but it sounds like Mr. Gerow
  2577.  JB> has already done so.
  2578.  
  2579. Yes, he has.  Keep your eyes on this area and area 15.
  2580. David Kennedy is looking into Mr. Gerow's problem.
  2581.  
  2582.  
  2583. Kevin Kitsemetry
  2584. WATCOM TECHNICAL SUPPORT
  2585.  
  2586. *** This is a reply to #2427.  *** See also #2447.
  2587.  
  2588.  
  2589. From:    Kevin Kitsemetry                       Rec'd
  2590. To:      Jon Fleming                            Msg #2440, Feb-18-94 11:31AM
  2591. Subject: Optimization selection
  2592.  
  2593.  JF>      I've downloaded & applied the A and B patches.
  2594.  JF> I'll do some investigation.
  2595.  
  2596.  JF>      BTW, there's one bothersome but unimportant nit.
  2597.  JF> WLINK announces that is is creating an "AutoCAD
  2598.  JF> Devlopment System Executable".  Note the spelling of
  2599.  JF> the second word.  (I havent't tried WLINK since
  2600.  JF> applying the patches).
  2601.  
  2602. This has been fixed, it just didn't make it in time for the 'b' level patches.
  2603.  
  2604.  
  2605. Kevin Kitsemetry
  2606. WATCOM TECHNICAL SUPPORT
  2607.  
  2608. *** This is a reply to #2432.
  2609.  
  2610.  
  2611. From:    Kevin Blenkinsopp                      Rec'd
  2612. To:      Anthony Scian                          Msg #2441, Feb-18-94 11:55AM
  2613. Subject: I'm baaack!
  2614.  
  2615. Okay, I could live with it being a warning. Funny how after switching
  2616. compilers to get away from Microsoft I STILL end up getting screwed by them!
  2617. Thank you Mr Bill!
  2618.  
  2619. Cheers
  2620.  
  2621. Kevin
  2622.  
  2623. *** This is a reply to #2437.
  2624.  
  2625.  
  2626. From:    Julian Ayling
  2627. To:      Mike Paola                             Msg #2442, Feb-18-94 12:00AM
  2628. Subject: WVIDEO and EMM386     1/
  2629.  
  2630. I've just updated to 9.5b and can no longer get WVIDEO to work from DOS.
  2631.  
  2632. When I invoke WVIDEO the initial sign on banner appears there is a small
  2633. delay of about 2 seconds and then EMM386 jumps in with a exception #01
  2634. error message in an application at address 3083:0048, It always reports the
  2635. same address regardless of the application that I attempt to debug.
  2636.  
  2637. Using exactly the same set up with 9.5a I was at least able to start WVIDEO
  2638. even if it subsequently went on holiday when I was in the middle of
  2639. debugging.
  2640.  
  2641. I am able to start WVIDEO if I use a DOS box from within Windows, but this
  2642. is not what I need to do right now.
  2643.  
  2644. I am running to a secondary mono monitor. I have the WVIDEO environment set
  2645. to /trap#rsi. I have the apporpriate path statements. I have tried with an
  2646. without the NOVCPI option for EMM386 with no effect.
  2647.  
  2648. Here is the output from techinfo, Using the RIPSPEED sections from
  2649. config.sys and autoexec.bat
  2650.  
  2651. WATCOM's Techinfo Utility, Version 1.3
  2652. Current Time: Fri Feb 18 17:32:40 1994
  2653.  
  2654. WATCOM                Phone: (519) 884-0702
  2655. 415 Phillip St.       Fax: (519) 747-4971
  2656. Waterloo, Ontario
  2657. CANADA    N2L 3X2
  2658.  
  2659. ___---------------WATCOM C Environment Variables ----------------
  2660. WATCOM=<C:\WC\.>
  2661. INCLUDE=<C:\WC\H;C:\WC\H\WIN>
  2662. PATH=<C:\DOS;C:\NU;C:\WC\BIN;C:\WC\BINB;C:\WC\BINW;C:\WINDOWS;C:\C700\BIN;
  2663. C:\UTILS;C:\WW;D:\ALD;D:\PR2UK;C:\HJWIN;D:\MGXLIBS>
  2664. WVIDEO=</trap#rsi>
  2665. WCGMEMORY=<3072>
  2666. File 'C:\WC\.\bin\wcc386.exe' has been patched to level '.b'
  2667. File 'C:\WC\.\bin\wvideo.exe' has been patched to level '.b'
  2668. File 'C:\WC\.\binw\wvideo.exe' has been patched to level '.b'
  2669. File 'C:\WC\.\bin\wlink.exe' has been patched to level '.b'
  2670. File 'C:\WC\.\binb\wlib.exe' has been patched to level '.b'
  2671. ___---------------WATCOM SQL Environment Variables ----------------
  2672. ... ERROR...WSQL environment variable not set.
  2673.  
  2674. Amount of extended memory is: 0K
  2675. Amount of base memory is: 640K
  2676. Amount of free base memory is: 580512 bytes
  2677. DOS Version 6.20
  2678.  
  2679. ___---------C:\CONFIG.SYS-------------
  2680. [menu]
  2681. menuitem=MSVC, Microsoft Visual C Development
  2682. menuitem=RipSpeed, Watcom C9.5a Development for RipSpeed
  2683. menuitem=WatcomC95, Watcom C9.5 Development for RipSpeed
  2684. menuitem=DOSRipSpeed, RipSpeed Runtime environment
  2685. menuitem=Test, Try Things Out Here
  2686. menuitem=Newtest, Try Other Things Out Here
  2687. menudefault=RipSpeed, 20
  2688.  
  2689. [MSVC]
  2690. DEVICE=C:\adaptec\ASPI4DOS.SYS /D /x03
  2691. DEVICE=C:\DOS\HIMEM.SYS /VERBOSE
  2692. DEVICE=C:\DOS\EMM386.EXE NOEMS NOVCPI  HIGHSCAN WIN=D900-DBFF WIN=ED00-EFFF
  2693. BUFFERS=30,0
  2694. files=50
  2695. dos=UMB
  2696. LASTDRIVE=E
  2697. FCBS=16,0
  2698. dos=HIGH
  2699. STACKS=0,0
  2700. break=on
  2701. rem device=c:\dos\smartdrv.exe /double_buffering
  2702. shell=c:\dos\command.com c:\dos /e:768 /p
  2703. country=044,,\dos\country.sys
  2704. DEVICE=C:\ADAPTEC\ASPIDISK.SYS /D
  2705. rem DEVICE=C:\CORELDRV\CUNI_ASP.SYS /ID:1 /N:1 /D:MSCD001
  2706.  
  2707. [RipSpeed]
  2708. DEVICE=C:\ADAPTEC\ASPI4DOS.SYS /D /x03
  2709. DEVICE=C:\DOS\HIMEM.SYS /VERBOSE
  2710. DEVICE=C:\DOS\EMM386.EXE NOEMS NOVCPI HIGHSCAN WIN=D900-DBFF WIN=ED00-EFFF
  2711. rem DEVICE=C:\DOS\RAMDRIVE.SYS 4096 /E
  2712. BUFFERS=30,0
  2713. files=50
  2714. DOS=UMB
  2715. LASTDRIVE=E
  2716. FCBS=16,0
  2717. DOS=HIGH
  2718. STACKS=0,0
  2719. break=on
  2720. rem device=c:\dos\smartdrv.exe /double_buffering
  2721. shell=c:\dos\command.com c:\dos /e:768 /p
  2722. country=044,,\dos\country.sys
  2723. DEVICE=C:\ADAPTEC\ASPIDISK.SYS /D
  2724.  
  2725. [WatcomC95]
  2726. DEVICE=C:\DOS\HIMEM.SYS /VERBOSE
  2727. DEVICE=C:\DOS\EMM386.EXE NOEMS NOVCPI
  2728. BUFFERS=10,0
  2729. FILES=30
  2730. DOS=UMB
  2731. LASTDRIVE=E
  2732. FCBS=4,0
  2733. DOS=HIGH
  2734. STACKS=0,0
  2735. break=on
  2736. rem device=c:\dos\smartdrv.exe /double_buffering
  2737. shell=c:\dos\command.com c:\dos /e:768 /p
  2738. country=044,,\dos\country.sys
  2739. rem 10.0Mb/sec Adaptec scsi controller
  2740. DEVICE=C:\ADAPTEC\ASPI4DOS.SYS /D /x03
  2741. rem Adaptec controller for addition SCSI disks
  2742. DEVICEHIGH /L:2,7616 =C:\ADAPTEC\ASPIDISK.SYS /D
  2743.  
  2744.  
  2745. [DOSRipSpeed]
  2746. DEVICE=C:\ADAPTEC\ASPI4DOS.SYS /D /x03
  2747. DEVICE=C:\DOS\HIMEM.SYS /VERBOSE
  2748. rem DEVICE=C:\DOS\EMM386.EXE NOEMS HIGHSCAN I=B000-B7FF NOVCPI
  2749. rem DEVICE=C:\DOS\RAMDRIVE.SYS 16384 /E
  2750. BUFFERS=10,0
  2751. FILES=50
  2752. rem DOS=UMB
  2753. LASTDRIVE=E
  2754. FCBS=4,0
  2755. break=on
  2756. shell=c:\dos\command.com c:\dos /e:768 /p
  2757. country=044,,\dos\country.sys
  2758. DEVICE=C:\ADAPTEC\ASPIDISK.SYS /D
  2759.  
  2760.  
  2761. [Test]
  2762. DEVICE=C:\DOS\HIMEM.SYS /VERBOSE
  2763. rem DEVICE=C:\DOS\EMM386.EXE AUTO RAM
  2764. rem NOEMS NOVCPI WIN=D900-DBFF WIN=ED00-EFFF
  2765. BUFFERS=10,0
  2766. FILES=30
  2767. DOS=UMB
  2768. LASTDRIVE=E
  2769. FCBS=16,8
  2770. DOS=HIGH
  2771. STACKS=9,256
  2772. break=on
  2773. DEVICE=C:\DOS\EMM386.EXE AUTO RAM
  2774. rem device=c:\dos\smartdrv.exe /double_buffering
  2775. >>> Continued to next message
  2776. ___
  2777.  X SLMR 2.1a X
  2778.  
  2779.  
  2780. From:    Julian Ayling
  2781. To:      Mike Paola                             Msg #2443, Feb-18-94 12:00AM
  2782. Subject: WVIDEO and EMM386     2/
  2783.  
  2784. >>> Continued from previous message
  2785. shell=c:\dos\command.com c:\dos /e:768 /p
  2786. country=044,,\dos\country.sys
  2787. rem 10.0Mb/sec Adaptec scsi controller
  2788. DEVICE=C:\ADAPTEC\ASPI4DOS.SYS /D /x03
  2789. rem Adaptec controller for addition SCSI disks
  2790. DEVICEHIGH /L:2,7616 =C:\ADAPTEC\ASPIDISK.SYS /D
  2791.  
  2792. [Newtest]
  2793. DEVICE=C:\ADAPTEC\ASPI4DOS.SYS /D /x03
  2794. DEVICE=C:\DOS\HIMEM.SYS /VERBOSE
  2795. rem DEVICE=C:\DOS\RAMDRIVE.SYS 20480 /E
  2796. shell=c:\dos\command.com c:\dos /e:768 /p
  2797. DEVICE=C:\ADAPTEC\ASPIDISK.SYS /D
  2798.  
  2799. [common]
  2800. rem Don't delete this last block - it's for new bits to be added
  2801.  
  2802. ___---------C:\AUTOEXEC.BAT-------------
  2803. @ECHO OFF
  2804.  
  2805. goto %config%
  2806.  
  2807.  
  2808. :MSVC
  2809. rem C:\CORELDRV\MSCDEX /V /M:10 /D:MSCD001
  2810. LH /L:0;2,45488 /S C:\DOS\SMARTDRV.EXE 2048 2048 /v
  2811. LH /L:2,16656 C:\DOS\KEYB UK,,C:\DOS\KEYBOARD.SYS
  2812. LH /L:2,13984 C:\DOS\SHARE.EXE
  2813. LH /L:2,6384 C:\DOS\DOSKEY
  2814. LH /L:1,56928 C:\DOS\MOUSE
  2815. SET PSEXEC3=C:\PSEXEC3
  2816. SET TMP=C:\TMP
  2817. MODE CON RATE=32 DELAY=1
  2818. SET PATH=C:\DOS;C:\MSVC\BIN;C:\NU;C:\WINDOWS;C:\UTILS;C:\WW;D:\ALD;D:\PR2UK;
  2819. C:\NFS;C:\HJWIN
  2820. set LIB=C:\MSVC\LIB
  2821. set INCLUDE=C:\MSVC\INCLUDE
  2822. set INIT=C:\MSVC
  2823. set TOOLROOTDIR=C:\MSVC
  2824. Set HELPFILES=C:\MSVC\HELP\*.HLP
  2825. SET TEMP=E:\TEMP
  2826. rem SET SSI_ACT=2,2,2
  2827. rem SET SSI_ACT=40,40,40
  2828. dir #.
  2829. touch #.
  2830. PROMPT $p$g
  2831. cd \pom
  2832. goto end
  2833.  
  2834. :RipSpeed
  2835. LH /L:0;2,45488 /S C:\DOS\SMARTDRV.EXE 2048 2048 /v
  2836. LH /L:2,16656 C:\DOS\KEYB UK,,C:\DOS\KEYBOARD.SYS
  2837. LH /L:2,13984 C:\DOS\SHARE.EXE
  2838. LH /L:2,6384 C:\DOS\DOSKEY
  2839. LH /L:1,56928 C:\DOS\MOUSE
  2840. MODE CON RATE=32 DELAY=1
  2841. SET PATH=C:\DOS;C:\NU;C:\WC\BIN;C:\WC\BINB;C:\WC\BINW;C:\WINDOWS;C:\C700\BIN
  2842. ;C:\UTILS;C:\WW;D:\ALD;D:\PR2UK;C:\HJWIN;D:\MGXLIBS
  2843. SET INIT=C:\RIPSPEED\C700\INIT
  2844. SET INCLUDE=C:\WC\H;C:\WC\H\WIN
  2845. SET TEMP=C:\windows\temp
  2846. Set HELPFILES=C:\MSVC\HELP\*.HLP
  2847. SET HOME=C:\RIPSPEED
  2848. SET WATCOM=C:\WC\.
  2849. SET WCGMEMORY=3072
  2850. SET WVIDEO=/trap#rsi
  2851. SET DOS4G=nullp
  2852. SET RIPSPEED_HOME=e:\RIPSPEED
  2853. SET RIPSPEED_TEMP=e:\RIPSPEED\TEMP
  2854. SET RIPSPEED_OUTPUT=e:\RIPSPEED\OUTPUT
  2855. DIR #.
  2856. TOUCH #.
  2857. PROMPT $p$g
  2858. cd \ripspeed
  2859. goto end
  2860.  
  2861. :WatcomC95
  2862. LH /L:0;2,42416 /S C:\DOS\SMARTDRV.EXE 2048 2048 /v
  2863. LH /L:2,15904 C:\DOS\KEYB UK,,C:\DOS\KEYBOARD.SYS
  2864. LH /L:2,13984 C:\DOS\SHARE.EXE
  2865. LH /L:2,6400 C:\DOS\DOSKEY
  2866. LH /L:1,56928 C:\DOS\MOUSE
  2867. MODE CON RATE=32 DELAY=1
  2868. SET PATH=C:\POM311;C:\POM320;C:\DOS;C:\NU;C:\WC95\BIN;C:\WC95\BINB;C:\WC95\B
  2869. INW;C:\WINDOWS;C:\C700\BIN;C:\UTILS;C:\WW;D:\ALD;D:\PR2UK;C:\HJWIN
  2870. SET INIT=C:\RIPSPEED\C700\INIT
  2871. SET INCLUDE=C:\WC95\H;C:\WC95\H\WIN
  2872. SET TEMP=C:\WINDOWS\TEMP
  2873. SET HOME=C:\RIPSPEED
  2874. SET WATCOM=C:\WC95\.
  2875. SET WCGMEMORY=3072
  2876. rem SET WVIDEO=/trap#rsi
  2877. DIR #.
  2878. TOUCH #.
  2879. PROMPT $p$g
  2880. cd \ripspeed
  2881. goto end
  2882.  
  2883. :DOSRipSpeed
  2884. C:\DOS\SMARTDRV.EXE 2048 2048
  2885. C:\DOS\KEYB UK,,C:\DOS\KEYBOARD.SYS
  2886. C:\DOS\DOSKEY
  2887. C:\DOS\MOUSE
  2888. MODE CON RATE=32 DELAY=1
  2889. SET PATH=C:\DOS;C:\NU;C:\WC\BIN;C:\WC\BINB;C:\WC\BINW;C:\C700\BIN;C:\UTILS;C
  2890. :\FREEDOM\BIN
  2891. SET WATCOM=C:\WC\.
  2892. SET DOS4G=NULLP
  2893. SET RIPSPEED_HOME=E:\RIP
  2894. SET RIPSPEED_TEMP=E:\RIP\TEMP
  2895. SET RIPSPEED_OUTPUT=E:\RIP\OUTPUT
  2896. DIR #.
  2897. TOUCH #.
  2898. PROMPT $p$g
  2899. cd \ripspeed
  2900. goto end
  2901.  
  2902. :Test
  2903. LH /L:0;2,42416 /S C:\DOS\SMARTDRV.EXE 2048 2048 /v
  2904. LH /L:2,15904 C:\DOS\KEYB UK,,C:\DOS\KEYBOARD.SYS
  2905. LH /L:2,13984 C:\DOS\SHARE.EXE
  2906. LH /L:2,6400 C:\DOS\DOSKEY
  2907. LH /L:1,56928 C:\DOS\MOUSE
  2908. MODE CON RATE=32 DELAY=1
  2909. SET PATH=C:\POM311;C:\POM320;C:\DOS;C:\NU;C:\WC\BIN;C:\WC\BINB;C:\WC\BINW;C:
  2910. \WINDOWS;C:\C700\BIN;C:\UTILS;C:\WW;D:\ALD;D:\PR2UK;C:\HJWIN;C:\POMTEST
  2911. SET INIT=C:\RIPSPEED\C700\INIT
  2912. SET INCLUDE=C:\WC\H;C:\WC\H\WIN
  2913. SET TEMP=C:\WINDOWS\TEMP
  2914. SET HOME=C:\RIPSPEED
  2915. SET WATCOM=C:\WC\.
  2916. SET WCGMEMORY=3072
  2917. rem SET WVIDEO=/trap#rsi
  2918. rem SET DOS4GVM=@C:\RIPSPEED\NEW4G.VMC
  2919. DIR #.
  2920. TOUCH #.
  2921. PROMPT $p$g
  2922. cd \ripspeed
  2923. goto end
  2924. >>> Continued to next message
  2925. ___
  2926.  X SLMR 2.1a X
  2927.  
  2928. *** See also #2448.
  2929.  
  2930.  
  2931. From:    Julian Ayling
  2932. To:      Mike Paola                             Msg #2444, Feb-18-94 12:00AM
  2933. Subject: WVIDEO and EMM386     3/
  2934.  
  2935. >>> Continued from previous message
  2936. :Newtest
  2937. SET PATH=C:\DOS;C:\WC\BIN;C:\WC\BINB;C:\WC\BINW
  2938. Set DOS4G=VERBOSE
  2939. SET DOS4G=VERBOSE
  2940. SET RIPSPEED_HOME=C:\RIPSPEED
  2941. SET RIPSPEED_TEMP=C:\RIPSPEED\TEMP
  2942. SET RIPSPEED_OUTPUT=C:\RIPSPEED\OUTPUT
  2943. cd \ripspeed
  2944. goto end
  2945.  
  2946. :end
  2947.  
  2948.  
  2949. ___---------------------------------------------------
  2950. A Intel 486 processor is installed in this system.
  2951. 486 math coprocessor is present
  2952.     and Equipment Flags say math coprocessor IS present.
  2953. The next test may cause the system to hang if 486
  2954.     interrupts are not handled properly.
  2955. 486 interrupts are properly enabled.
  2956.  
  2957. ___---------------------------------------------------
  2958. APPEND                  NOT INSTALLED
  2959.  
  2960.  
  2961. Do you have any idea what is happening? Have there been any changes to the
  2962. way in which WVIDEO needs to be invoked that I've missed? When will the IDE
  2963. be avaialable and is there any chance of getting on the beta test list for
  2964. it, pretty please with sugar on?
  2965.  
  2966. This is stopping me from checking any further as to wether the new memory
  2967. management routines are performing any better than the old ones so I can't
  2968. give you an update on this yet.
  2969.  
  2970.  
  2971. Thanks.
  2972. ___
  2973.  X SLMR 2.1a X
  2974.  
  2975. *** See also #2457.
  2976.  
  2977.  
  2978. From:    Bob Vonmoss
  2979. To:      Kevin Kitsemetry                       Msg #2445, Feb-22-94 10:26AM
  2980. Subject: b-level cdecl change
  2981.  
  2982. KK> Contacted via phone.
  2983.  
  2984.  
  2985. I just installed the b-level patches for watcom C/C++ 9.5.
  2986. We had been successfully running with 9.5a.  When we call
  2987. WLINK, we are getting undefined references for external
  2988. assembly routines.  The code originally used cdecl to
  2989. force "C" semantics.  The function name was also mangled.
  2990. I changed that kind of declaration to this style:
  2991. "C" { asm_func() }
  2992. This did not mangle the name, but put _ after the function
  2993. name and it can't find the asm function.  I did notice
  2994. the note in the README that cdecl no longer forces "C"
  2995. semantics.  This was part of the C-scape windowing
  2996. library.
  2997.  
  2998.         Right now I'm unable to link to the external
  2999. .ASM routines.  Can someone get in touch with me as soon
  3000. as possible.  Bob V. with Marathon Software (312) 525-3692
  3001. Chicago, IL, USA.
  3002.  
  3003.  
  3004. From:    Julian Ayling
  3005. To:      Mike Paola                             Msg #2446, Feb-18-94 12:00AM
  3006. Subject: WVIDEO and EMM386 again
  3007.  
  3008. I forgot to give you the source, make and link files used for the WVIDEO
  3009. EMM386 exception problem. I'll zip them as VBS.ZIP in file area 12.
  3010.  
  3011. Thanks.
  3012. ___
  3013.  X SLMR 2.1a X
  3014.  
  3015.  
  3016. From:    Jason Blochowiak                       Rec'd
  3017. To:      Kevin Kitsemetry                       Msg #2447, Feb-18-94 03:58PM
  3018. Subject: 16-bit fixup problems
  3019.  
  3020.  Ok, I'll keep an eye out. Btw, for the time being I'm using a rather heinous
  3021. kludge - I link the .OBJ file that my .ASM source assembles to into an EXE by
  3022. itself (using TLINK), then use EXE2BIN to convert it, then use MAKEHEX (a
  3023. little utility I wrote that converts a file to a bunch of DBs), then assemble
  3024. a file that includes the output of MAKEHEX, and link that into my EXE. Because
  3025. of all of this, I end up with 3 copies of the code - one original, one kludge
  3026. duplicate (TLINK, btw, does generate the correct results), and then the copy
  3027. that ends up down in real mode memory. Fortunately, the code is only about 5k.
  3028.  
  3029.  As I mentioned, I used SoftICE/W to help figure out what's going on - I ended
  3030. up doing a "Fake EXE" with TLINK, then using NuMega's MSYM program to convert
  3031. TLINK's output to a seperate .SYM file, loading that, and using SYMLOC after I
  3032. figured out where the real mode code ends up. There's apparently a utility
  3033. that will convert a 16-bit Watcom .MAP file to something similar to
  3034. Microsoft's .MAP file, so that MSYM will be able to process it, but it fails
  3035. miserably with a 32-bit app (big suprise). In any case, it'd be really nice to
  3036. be able to use source-level debugging with the 32-bit code from within S/W,
  3037. especially seeing as WVideo does such a miserable job of dealing with
  3038. interrupts and such. I've yet to contact NuMega about this (I only got S/W a
  3039. few days ago), but I'd appreciate any information you might have about this,
  3040. and it'd certainly be nice if the folks at Watcom and NuMega could work
  3041. together to get support for this going.
  3042.  
  3043.  Thanks,
  3044.  Jason
  3045.  
  3046. *** This is a reply to #2438.  *** See also #2462.
  3047.  
  3048.  
  3049. From:    Dan Teven                              Rec'd
  3050. To:      Julian Ayling                          Msg #2448, Feb-18-94 04:28PM
  3051. Subject: WVIDEO and EMM386     2/
  3052.  
  3053. Try removing DOS4G=NULLP -- and see the recent message traffic in
  3054. area 15.
  3055.  
  3056. Dan
  3057.  
  3058. *** This is a reply to #2443.
  3059.  
  3060.  
  3061. From:    Joseph Molnar                          Rec'd
  3062. To:      David Kennedy                          Msg #2451, Feb-19-94 02:37PM
  3063. Subject: Problem
  3064.  
  3065.  DK> Note that the type of L"string" is specified as an
  3066.  DK> array of wchar_t as defined in <stddef.h>  By default
  3067.  DK> this is char, but changes to long char if _cplusplus is
  3068.  DK> defined (ie. if you invoke wpp386).  Long char is two
  3069.  DK> bytes long, as it should be.  Note that <stddef.h> IS
  3070.  DK> included by including <windows.h>
  3071.  
  3072. This isn't even what my message is about.  It is qaiute obvious that wchar_t
  3073. and long char are both 2 bytes etc.etc.   I said there was a token pasting
  3074. problem with your preprocessor, that is why I said to look at my other message
  3075. that wasn't responded to at all!
  3076.  
  3077. #define TEXT( x )       L##x
  3078.  
  3079. With the above if I go TEXT( "Hello" ), I should get get a long char string.
  3080. But I am not.  We are trying to do Unicode stuff, but we want to be able to
  3081. change the definition of TEXT so not to be UNICODE all the time.  This was
  3082. the suggestion in the NT SDK, but is NOT working with Watcom's compiler, so
  3083. it must be a token pasting problem with the preprocessor.  To see my original
  3084. message, please look-back in the message to one to Tech support with Kevin in
  3085. brackets I believe, it will tell you more.  We need this fixed, please tell me
  3086. if you can duplicate it, if there is a fix etc etc.
  3087.  
  3088. *** This is a reply to #2407
  3089.  
  3090. From:    Jason Blochowiak                       Rec'd
  3091. To:      Kevin Kitsemetry                       Msg #2452, Feb-19-94 10:54PM
  3092. Subject: DPMI call 300 under Windows
  3093.  
  3094.  Well, now that I've got the heinous kludge in place and working, I've got a
  3095. correct copy of my 16-bit code in memory. Now I'm trying to get the
  3096. communication working under Windows, but I'm having a problem: I'm using DPMI
  3097. call 0300 with ECX set to something non-zero. This works correctly with
  3098. DOS4G/W 1.95 acting as the DPMI host, but when I run it under Windows, the
  3099. parms on the stack when I hit the interrupt are incorrect. I traced into VMM,
  3100. and watched what it did - after going past a few billion instructions, I saw
  3101. what looked like the parm copy (right number back in ECX, and a REP MOVSW),
  3102. but ESI wasn't pointing to my original pre-INT 31 parms. To refresh your
  3103. memory, this is an extended DOS app, now running in a DOS box. Are there any
  3104. known wierdnesses related to Windows' DPMI implementation and call 0300? If it
  3105. makes a difference, I'm not currently locking down my app's memory, but I'm
  3106. also not running Windows in VM mode.
  3107.  
  3108.  Jason
  3109.  
  3110. *** See also #2464.
  3111.  
  3112.  
  3113. From:    John Rex                               Rec'd
  3114. To:      Kevin Kitsemetry                       Msg #2453, Feb-20-94 01:44PM
  3115. Subject: debugging
  3116.  
  3117. Am having a terrible time debugging using Watcom C/C++(32) and the
  3118. new PharLap TNT dos extendder. You guys seems to have your own propriety
  3119. debug data which only your linker can handle, yet i need to to use the
  3120. pharlap tnt linker to get tnt to work correctly. wvideo will not debug
  3121. thinks built with pharlap's linker, so it seems. I have used wvideo
  3122. in the past and would like to use now, but can't get over this hurdle.
  3123. I'd really rather not try to figure out pharlap's sb386 debugger--in
  3124. preliminary trials it is blowing up on me. How do you guys suggest one
  3125. debug in this environment?
  3126.  
  3127. *** See also #2465.
  3128.  
  3129.  
  3130. From:    John Lansdale                          Rec'd
  3131. To:      Kevin Kitsemetry                       Msg #2454, Feb-20-94 11:51PM
  3132. Subject: Compiling a resource into a DLL
  3133.  
  3134. I'm having problems compiling a .rc file directly into an existing DLL
  3135. file. The test scenario is to save the resource file out into a DLL using
  3136. Borland's Resource Workshop (to create the basic DLL file), then using
  3137. 'wrc' on the .rc file as such:
  3138.         wrc resource.rc resource.dll
  3139. However, my application crashes when I access the DLL. This series of
  3140. operations worked fine with Microsoft's 'rc' program which I can no
  3141. longer use it since I'm running out of far memory space. Any suggestions?
  3142.  
  3143. Also, regarding the export of global variables from 32-bit NT DLLs, will
  3144. this be a future capability of WATCOM-compiled DLLs or must I rewrite my
  3145. code to not export variables?
  3146.  
  3147. *** See also #2466.
  3148.  
  3149.  
  3150. From:    Ramon Rivas
  3151. To:      Tech Support                           Msg #2455, Feb-21-94 07:27AM
  3152. Subject: STRANGE ERROR
  3153.  
  3154. #if 0
  3155. 08/18/93
  3156. #endif
  3157.  
  3158. /*****************************************************************************
  3159. *                                                                            *
  3160. * The date above displays the following error message:                       *
  3161. *                                                                            *
  3162. * WATCOM C32 Optimizing Compiler  Version 9.5b                               *
  3163. * Copyright by WATCOM International Corp. 1984, 1993. All rights reserved.   *
  3164. * WATCOM is a trademark of WATCOM International Corp.                        *
  3165. * test.c(2): Error! E1163: Invalid octal constant                            *
  3166. * test.c: 37 lines, 0 warnings, 1 errors                                     *
  3167. *                                                                            *
  3168. *                                                                            *
  3169. * Of course, usualy we have that as part of comments in source files.        *
  3170. * It worked fine up to 9.5b (maybe up to 9.5a, I'm not sure). I understand   *
  3171. * what it's trying to tell me I just don't think it should be telling that   *
  3172. * inside an #if0-endif. Is this going to be once of ANSI specs? My env. is:  *
  3173. *                                                                            *
  3174. * WCC386=/3r /j /mf /fp3 /w3 /zp1 /od /dOS386                                *
  3175. * INC386=c:\wc3\h;c:\wc3\h\sys;c:\c4\h;c:\os386\aiacode                      *
  3176. * LIBPHAR=c:\wc3\lib386;c:\wc3\lib386\dos                                    *
  3177. * LIB=c:\wc3\lib386;c:\wc3\lib386\dos                                        *
  3178. * WCG386=c:\wc3\bin\386wcgl.exe                                              *
  3179. * WATCOM=c:\wc3                                                              *
  3180. * WVIDEO=/trap#ecs/dynamic#40000/nofpu/swap                                  *
  3181. * WCL386=/lergo                                                              *
  3182. *                                                                            *
  3183. * And the command line used was:                                             *
  3184. *                                                                            *
  3185. * wcc386 test.c                                                              *
  3186. *                                                                            *
  3187. *                                                                            *
  3188. *****************************************************************************/
  3189.  
  3190. *** See also #2467.
  3191.  
  3192.  
  3193. From:    Ramon Rivas                            Rec'd
  3194. To:      David Kennedy                          Msg #2456, Feb-21-94 07:28AM
  3195. Subject: Ergo
  3196.  
  3197. Hi David,
  3198.    Any news on that Ergo problem?
  3199. Ramon.
  3200.  
  3201. *** See also #2524.
  3202.  
  3203.  
  3204. From:    Thomas B. Pollard                      Rec'd
  3205. To:      Julian Ayling                          Msg #2457, Feb-21-94 10:30AM
  3206. Subject: WVIDEO and EMM386     3/
  3207.  
  3208. Hi look in area 15.  Make sure you don't set DOS4G=NULLP.  This has
  3209. already been varified not to work properly.
  3210.  
  3211. *** This is a reply to #2444.
  3212.  
  3213.  
  3214. From:    Bob Vonmoss                            Rec'd
  3215. To:      Kevin Kitsemetry                       Msg #2458, Feb-22-94 12:16PM
  3216. Subject: assembly call snipit code
  3217.  
  3218. // example.cpp
  3219. //
  3220. // An attempt to call the assembly function: outside_asm();// without mangling
  3221. the name or having it end with an
  3222. // underscore.  This produces a message about overloading
  3223. // an extern "C" function.
  3224. //
  3225. #pragma aux outside_asm "*";
  3226.  
  3227. extern "C" { void outside_asm(int); }
  3228.  
  3229. int main()
  3230. {
  3231.         outside_asm(1);
  3232.         return(0);
  3233. }
  3234. //Bob VonMoss (708) 361-0001 Marathon Software
  3235.  
  3236. *** See also #2459.
  3237.  
  3238.  
  3239. From:    Anthony Scian                          Rec'd
  3240. To:      Bob Vonmoss                            Msg #2459, Feb-21-94 09:03PM
  3241. Subject: assembly call snipit code
  3242.  
  3243.  BV> // example.cpp
  3244.  BV> //
  3245.  BV> // An attempt to call the assembly function: outside_asm();
  3246.  BV> // without mangling the name or having it end with an
  3247.  BV> // underscore.  This produces a message about overloading
  3248.  BV> // an extern "C" function.
  3249.  BV> //
  3250.  BV> #pragma aux outside_asm "*";
  3251.  BV>
  3252.  BV> extern "C" { void outside_asm(int); }
  3253.  BV>
  3254.  BV> int main()
  3255.  BV> {
  3256.  BV>         outside_asm(1);
  3257.  BV>         return(0);
  3258.  BV> }
  3259.  
  3260. In C++, you must always prototype a function before you use it. The #pragma
  3261. essentially defines a function prototype that accepts any arguments if you
  3262. don't already have the function declared. Its prototype is
  3263.  
  3264.     extern "C" void outside_asm( ... );
  3265.  
  3266. for WATCOM C compatibility reasons.
  3267.  
  3268. Change your code to:
  3269.  
  3270.     extern "C" void outside_asm( int );
  3271.     #pragma aux outside_asm "*";
  3272.  
  3273. and things will be fine.
  3274.  
  3275. *** This is a reply to #2458.
  3276.  
  3277.  
  3278. From:    Kevin Kitsemetry                       Rec'd
  3279. To:      Jason Blochowiak                       Msg #2462, Feb-22-94 10:31AM
  3280. Subject: 16-bit fixup problems
  3281.  
  3282.  JB> Microsoft's .MAP file, so that MSYM will be able to
  3283.  JB> process it, but it fails miserably with a 32-bit app
  3284.  JB> (big suprise). In any case, it'd be really nice to be
  3285.  JB> able to use source-level debugging with the 32-bit
  3286.  JB> code from within S/W, especially seeing as WVideo does
  3287.  JB> such a miserable job of dealing with interrupts and
  3288.  JB> such. I've yet to contact NuMega about this (I only
  3289.  JB> got S/W a few days ago), but I'd appreciate any
  3290.  JB> information you might have about this, and it'd
  3291.  JB> certainly be nice if the folks at Watcom and NuMega
  3292.  JB> could work together to get support for this going.
  3293.  
  3294. We have looked into this.  Our manager of Third Party
  3295. Vendor support has talked to the folks at Numega, but
  3296. there have been no announcements as of yet.
  3297.  
  3298.  
  3299. Kevin Kitsemetry
  3300. WATCOM TECHNICAL SUPPORT
  3301.  
  3302. *** This is a reply to #2447.  *** See also #2474.
  3303.  
  3304.  
  3305. From:    Kevin Kitsemetry                       Rec'd
  3306. To:      Jason Blochowiak                       Msg #2464, Feb-22-94 10:41AM
  3307. Subject: DPMI call 300 under Windows
  3308.  
  3309.  JB>  Well, now that I've got the heinous kludge in place and working, I've
  3310.  JB> got a correct copy of my 16-bit code in memory. Now
  3311.  JB> I'm trying to get the communication working under
  3312.  JB> Windows, but I'm having a problem: I'm using DPMI call
  3313.  JB> 0300 with ECX set to something non-zero. This works
  3314.  JB> correctly with DOS4G/W 1.95 acting as the DPMI host,
  3315.  JB> but when I run it under Windows, the parms on the
  3316.  JB> stack when I hit the interrupt are incorrect. I traced
  3317.  JB> into VMM, and watched what it did - after going past a
  3318.  JB> few billion instructions, I saw what looked like the
  3319.  JB> parm copy (right number back in ECX, and a REP MOVSW),
  3320.  JB> but ESI wasn't pointing to my original pre-INT 31
  3321.  JB> parms. To refresh your memory, this is an extended DOS
  3322.  JB> app, now running in a DOS box. Are there any known
  3323.  JB> wierdnesses related to Windows' DPMI implementation
  3324.  JB> and call 0300? If it makes a difference, I'm not
  3325.  JB> currently locking down my app's memory, but I'm also
  3326.  JB> not running Windows in VM mode.
  3327.  
  3328. The only difference between running the program under Windows and in DOS, is
  3329. that the DPMI services are now being provided by Windows, rather than the DOS
  3330. extender itself.  I have
  3331. checked our database and did not find any known problems with DPMI 300 under
  3332. Windows.
  3333.  
  3334.  
  3335. Kevin Kitsemetry
  3336. WATCOM TECHNICAL SUPPORT
  3337.  
  3338. *** This is a reply to #2452.  *** See also #2475.
  3339.  
  3340.  
  3341. From:    Kevin Kitsemetry                       Rec'd
  3342. To:      John Rex                               Msg #2465, Feb-22-94 10:47AM
  3343. Subject: debugging
  3344.  
  3345.  JR> Am having a terrible time debugging using Watcom C/C++(32) and the
  3346.  JR> new PharLap TNT dos extendder. You guys seems to have your own propriety
  3347.  JR> debug data which only your linker can handle, yet i need to to use the
  3348.  JR> pharlap tnt linker to get tnt to work correctly. wvideo will not debug
  3349.  JR> thinks built with pharlap's linker, so it seems. I have used wvideo
  3350.  JR> in the past and would like to use now, but can't get over this hurdle.
  3351.  
  3352. Currently we do not support debugging Pharlap TNT DOS extender executables.
  3353. You can use the WATCOM linker to create TNT exe's, you just can't use WVIDEO
  3354. to debug them as of yet.  We are looking into supporting this in the future.
  3355.  
  3356.  
  3357. Kevin Kitsemetry
  3358. WATCOM TECHNICAL SUPPORT
  3359.  
  3360. *** This is a reply to #2453.  *** See also #2477.
  3361.  
  3362.  
  3363. From:    Kevin Kitsemetry                       Rec'd
  3364. To:      John Lansdale                          Msg #2466, Feb-22-94 11:15AM
  3365. Subject: Compiling a resource into a DLL
  3366.  
  3367.  JL> I'm having problems compiling a .rc file directly into an existing DLL
  3368.  JL> file. The test scenario is to save the resource file out into a DLL using
  3369.  JL> Borland's Resource Workshop (to create the basic DLL file), then using
  3370.  JL> 'wrc' on the .rc file as such:
  3371.  JL>         wrc resource.rc resource.dll
  3372.  JL> However, my application crashes when I access the DLL. This series of
  3373.  JL> operations worked fine with Microsoft's 'rc' program which I can no
  3374.  JL> longer use it since I'm running out of far memory space. Any suggestions?
  3375.  
  3376. How are you 'accessing' the DLL?  Does it work if you create an exe?  Have you
  3377. tried to create a WIN32 resource file (instead of the default WIN16)?
  3378.  
  3379.  
  3380.  JL> Also, regarding the export of global variables from 32-bit NT DLLs, will
  3381.  JL> this be a future capability of WATCOM-compiled DLLs or must I rewrite my
  3382.  JL> code to not export variables?
  3383.  
  3384. There are no definite plans or dates to add this capability.  I will add you
  3385. name to a list of users asking for this capability.
  3386.  
  3387.  
  3388. Kevin Kitsemetry
  3389. WATCOM TECHNICAL SUPPORT
  3390.  
  3391. *** This is a reply to #2454.
  3392.  
  3393.  
  3394. From:    Kevin Kitsemetry                       Rec'd
  3395. To:      Ramon Rivas                            Msg #2467, Feb-22-94 11:38AM
  3396. Subject: STRANGE ERROR
  3397.  
  3398.  RR> #if 0
  3399.  RR> 08/18/93
  3400.  RR> #endif
  3401.  
  3402.  RR> * The date above displays the following error message:
  3403.  RR>                       * *
  3404.  RR>                                               *
  3405.  RR> * WATCOM C32 Optimizing Compiler  Version 9.5b
  3406.  RR>     * * Copyright by WATCOM International Corp. 1984,
  3407.  RR> 1993. All rights reserved.   * * WATCOM is a trademark
  3408.  RR> of WATCOM International Corp.                        *
  3409.  RR> * test.c(2): Error! E1163: Invalid octal constant
  3410.  RR>                       * * test.c: 37 lines, 0
  3411.  
  3412. Sorry, this is a bug in the 'b' level compiler.  You can download the
  3413. corrected compiler(s) from secret area 'scompnew',
  3414. password 'octal'.
  3415.  
  3416.  
  3417. Kevin Kitsemetry
  3418. WATCOM TECHNICAL SUPPORT
  3419.  
  3420. *** This is a reply to #2455.  *** See also #2470.
  3421.  
  3422.  
  3423. From:    Ramon Rivas                            Rec'd
  3424. To:      Kevin Kitsemetry                       Msg #2470, Feb-22-94 01:05PM
  3425. Subject: STRANGE ERROR
  3426.  
  3427. Thanks,
  3428.     Can you tell me what's happening with the Ergo problem reported in message
  3429. 2369? Ramon.
  3430.  
  3431. *** This is a reply to #2467.  *** See also #2472.
  3432.  
  3433.  
  3434. From:    Patrick Lamb                           Rec'd
  3435. To:      Kevin Kitsemetry                       Msg #2471, Feb-22-94 01:01PM
  3436. Subject: printf/getch/graphics?
  3437.  
  3438.         I'm not able to get a printf to work before a call to the
  3439. graphics library.  I've reduced it to the small test program shown
  3440. below. _I_ think I should be able to read "Press a key to continue:"
  3441. before the graphics call; what actually happens is that I have to press
  3442. a key, it goes and draws its line, I press another key, the screen
  3443. returns to text mode and prints out the message.  IOW, the program does
  3444. wait to get the character before continuing, but my prompt is useless.
  3445.  
  3446.         I'm using the 9.5b version with the dos4gw extender.
  3447.  
  3448.         While this isn't an urgent problem, I would like to be able to
  3449. fix it.
  3450.  
  3451.                                 Pat
  3452.  
  3453.  
  3454.  
  3455. #include <stdio.h>
  3456. #include <graph.h>
  3457. #include <conio.h>
  3458.  
  3459. #define BYTE unsigned char
  3460.  
  3461. main (void)
  3462. {
  3463.     char ch;
  3464.  
  3465.     printf("Press a key to continue:");
  3466.     ch = getch();
  3467.  
  3468. /* Plot the histogram. */
  3469.     _setvideomode( _VRES16COLOR );
  3470.     _moveto(25,450);
  3471.     _lineto(25+2*256,450);
  3472.     ch = getch();
  3473.     _setvideomode( _DEFAULTMODE );
  3474. }
  3475.  
  3476. *** See also #2473.
  3477.  
  3478.  
  3479. From:    Kevin Kitsemetry                       Rec'd
  3480. To:      Ramon Rivas                            Msg #2472, Feb-22-94 03:08PM
  3481. Subject: STRANGE ERROR
  3482.  
  3483.  RR> Thanks,
  3484.  RR>     Can you tell me what's happening with the Ergo
  3485.  RR> problem reported in message 2369? Ramon.
  3486.  
  3487. You can send a message to David Kennedy regarding this one. I will tell him
  3488. you have been asking about it.
  3489.  
  3490.  
  3491. Kevin Kitsemetry
  3492. WATCOM TECHNICAL SUPPORT
  3493.  
  3494. *** This is a reply to #2470.
  3495.  
  3496.  
  3497. From:    Kevin Kitsemetry                       Rec'd
  3498. To:      Patrick Lamb                           Msg #2473, Feb-22-94 03:09PM
  3499. Subject: printf/getch/graphics?
  3500.  
  3501.  PL>         I'm not able to get a printf to work before a call to the
  3502.  PL> graphics library.  I've reduced it to the small test program shown
  3503.  PL> below. _I_ think I should be able to read "Press a key to continue:"
  3504.  PL> before the graphics call; what actually happens is that I have to press
  3505.  PL> a key, it goes and draws its line, I press another key, the screen
  3506.  PL> returns to text mode and prints out the message.  IOW, the program does
  3507.  PL> wait to get the character before continuing, but my prompt is useless.
  3508.  
  3509. Printf() is buffered.  You can set the buffer to NULL using setvbuf(),or put
  3510. in the line feed for your prompt:
  3511.  
  3512. printf("Press and key:\n");
  3513.  
  3514.  
  3515. Kevin Kitsemetry
  3516. WATCOM TECHNICAL SUPPORT
  3517.  
  3518. *** This is a reply to #2471.  *** See also #2476.
  3519.  
  3520.  
  3521. From:    Jason Blochowiak                       Rec'd
  3522. To:      Kevin Kitsemetry                       Msg #2474, Feb-22-94 03:51PM
  3523. Subject: Watcom & SoftICE
  3524.  
  3525.  I presume that such an announcement would show up here?
  3526.  
  3527.  In any case, you've obviously got at least one vote for getting support
  3528. going. It might also be useful for Watcom as a way of deflecting criticism of
  3529. WVideo until the new debugger is done.
  3530.  
  3531.  Jason
  3532.  
  3533. *** This is a reply to #2462.  *** See also #2481.
  3534.  
  3535.  
  3536. From:    Jason Blochowiak                       Rec'd
  3537. To:      Kevin Kitsemetry                       Msg #2475, Feb-22-94 03:54PM
  3538. Subject: DPMI call 300 under Windows
  3539.  
  3540.  Yeah, I'm aware that under Windows, Windows' DOS extender is providing the
  3541. DPMI services - that's what seems to be making the difference.
  3542.  
  3543.  In any case, thanks for checking the database, and I'll see if I can narrow
  3544. down what's going on.
  3545.  
  3546.  Jason
  3547.  
  3548. *** This is a reply to #2464.
  3549.  
  3550.  
  3551. From:    Jason Blochowiak                       Rec'd
  3552. To:      Kevin Kitsemetry                       Msg #2476, Feb-22-94 03:58PM
  3553. Subject: printf/getch/graphics?
  3554.  
  3555.  I've always used fflush(stdout) whenever I wanted to make sure that something
  3556. I printed showed up.
  3557.  
  3558.  Jason
  3559.  
  3560. *** This is a reply to #2473.  *** See also #2482.
  3561.  
  3562.  
  3563. From:    John Rex                               Rec'd
  3564. To:      Kevin Kitsemetry                       Msg #2477, Feb-22-94 10:34PM
  3565. Subject: debugging
  3566.  
  3567. thanks for the explanation . too bad about the lack of support.
  3568.  
  3569. *** This is a reply to #2465.
  3570.  
  3571.  
  3572. From:    Michael Mishoe                         Rec'd
  3573. To:      Kevin Kitsemetry                       Msg #2478, Feb-22-94 10:44PM
  3574. Subject: DOS4GW APP / RUNNING IN OS2 DOS BOX
  3575.  
  3576. KEVIN,
  3577. I HAVE tried running a DOS4GW program in full screen dos box in OS2 and
  3578. I have got mixed results. One simple program runs (test1); however
  3579. a second does not, it halts on a general protection fault. I thought
  3580. it might be the memory settings so I changed them to 10240k of XMS
  3581. for the dos box. Also I can get WVIDEO to run in the dos box ;however,
  3582. when I try to run WVIDEO with my program it crashes with the following
  3583. error.
  3584. SYS2237: DosKrnl: A NPX instruction was attempted, but no NPX is
  3585.         present
  3586.  
  3587. I thought maybe the default math lib include might be to blame so I recompiled
  3588. the program with the /fpc option in my MAKEFILE.
  3589.  
  3590. NEXT I tried to use the OS2 remote link approach.
  3591. I enter the following in the dos box:  vdmserv /trap=rsi rmt_dbg
  3592. I enter the following in a OS2 box:    wvideo -trap=vdm; rmt_dbg newapp
  3593.  
  3594. I get the very same error as above.
  3595.  
  3596. However if I do not enter the program name (newapp) the link is established
  3597. and wvideo runs fine . I get the error as son as I try to load the Program
  3598. .
  3599. I am running OS2 2.0. the program I am trying to degug in OS2 runs in
  3600. MS-DOS ok and wvideo has no problem with it in MS-DOS either.
  3601.  
  3602. I would appreciate any info available this problem. have a good one.
  3603.  
  3604.  
  3605. *** See also #2483.
  3606.  
  3607.  
  3608. From:    Bob Stout                              Rec'd
  3609. To:      Kevin Kitsemetry                       Msg #2479, Feb-23-94 12:23AM
  3610. Subject: C32_B.ZIP
  3611.  
  3612. The other evening, I DL'ed this file, then took a copy to the office. The
  3613. diskette got corrupted somehow along the way and I'd already (stupidly!)
  3614. deleted the original. To avoid the half hour of LD charges once again, could
  3615. you tell me once more where this available via anonymous ftp?
  3616.  
  3617. *** See also #2484.
  3618.  
  3619.  
  3620. From:    Anthony Scian                          Rec'd
  3621. To:      Patrick Lamb                           Msg #2480, Feb-23-94 09:24AM
  3622. Subject: printf/getch/graphics?
  3623.  
  3624.  PL>         I'm not able to get a printf to work before a call to the
  3625.  PL> graphics library.  I've reduced it to the small test program shown
  3626.  PL> below. _I_ think I should be able to read "Press a key to continue:"
  3627.  PL> before the graphics call; what actually happens is that I have to press
  3628.  PL> a key, it goes and draws its line, I press another key, the screen
  3629.  PL> returns to text mode and prints out the message.  IOW, the program does
  3630.  PL> wait to get the character before continuing, but my prompt is useless.
  3631.  
  3632.  PL>         I'm using the 9.5b version with the dos4gw extender.
  3633.  
  3634.  PL>         While this isn't an urgent problem, I would like to be able to
  3635.  PL> fix it.
  3636.  
  3637.  You are combining two families of functions that are not supposed to
  3638.  interact with each other.  If you use getch(), you should use cprintf().
  3639.  If you use getchar(), you can use printf().  The fix for the case where
  3640.  you want to use printf() and getch() is to fflush( stdout ) before the
  3641.  getch().  You are responsible for synchronizing both input and output
  3642.  when using two different families of functions (i.e., <stdio.h> and
  3643. <conio.h>).
  3644.  stdout is line buffered so you would have been fine if your string
  3645.  ended in a '\n'.
  3646.  
  3647.  Anthony
  3648.  
  3649.  PL>                                 Pat
  3650.  
  3651.  
  3652.  
  3653.  PL> #include <stdio.h>
  3654.  PL> #include <graph.h>
  3655.  PL> #include <conio.h>
  3656.  
  3657.  PL> #define BYTE unsigned char
  3658.  
  3659.  PL> main (void)
  3660.  PL> {
  3661.  PL>     char ch;
  3662.  
  3663.  PL>     printf("Press a key to continue:");
  3664.  
  3665.  ******> fflush( stdout );
  3666.  
  3667.  PL>     ch = getch();
  3668.  
  3669.  PL> /* Plot the histogram. */
  3670.  PL>     _setvideomode( _VRES16COLOR );
  3671.  PL>     _moveto(25,450);
  3672.  PL>     _lineto(25+2*256,450);
  3673.  PL>     ch = getch();
  3674.  PL>     _setvideomode( _DEFAULTMODE );
  3675.  PL> }
  3676.  
  3677. *** This is a reply to #2471.
  3678.  
  3679.  
  3680. From:    Kevin Kitsemetry                       Rec'd
  3681. To:      Jason Blochowiak                       Msg #2481, Feb-23-94 09:47AM
  3682. Subject: Watcom & SoftICE
  3683.  
  3684.  JB>  I presume that such an announcement would show up here?
  3685.  
  3686.  JB>  In any case, you've obviously got at least one vote
  3687.  JB> for getting support going. It might also be useful for
  3688.  JB> Watcom as a way of deflecting criticism of WVideo
  3689.  JB> until the new debugger is done.
  3690.  
  3691. I am not sure which product/announcement would come first!
  3692.  
  3693. *** This is a reply to #2474.  *** See also #2491.
  3694.  
  3695.  
  3696. From:    Kevin Kitsemetry                       Rec'd
  3697. To:      Jason Blochowiak                       Msg #2482, Feb-23-94 09:48AM
  3698. Subject: printf/getch/graphics?
  3699.  
  3700.  JB>  I've always used fflush(stdout) whenever I wanted to
  3701.  JB> make sure that something I printed showed up.
  3702.  
  3703. That's fine.  There are always a number of different ways
  3704. of doing things.  In C, there are a number of different
  3705. ways + 1.
  3706.  
  3707.  
  3708. Kevin Kitsemetry
  3709. WATCOM TECHNICAL SUPPORT
  3710.  
  3711. *** This is a reply to #2476.
  3712.  
  3713.  
  3714. From:    Kevin Kitsemetry
  3715. To:      Michael Mishoe                         Msg #2483, Feb-23-94 10:00AM
  3716. Subject: DOS4GW APP / RUNNING IN OS2 DOS BOX
  3717.  
  3718.  MM> KEVIN,
  3719.  MM> I HAVE tried running a DOS4GW program in full screen dos box in OS2 and
  3720.  MM> I have got mixed results. One simple program runs (test1); however
  3721.  MM> a second does not, it halts on a general protection fault. I thought
  3722.  MM> it might be the memory settings so I changed them to 10240k of XMS
  3723.  MM> for the dos box. Also I can get WVIDEO to run in the dos box ;however,
  3724.  MM> when I try to run WVIDEO with my program it crashes with the following
  3725.  MM> error.
  3726.  MM> SYS2237: DosKrnl: A NPX instruction was attempted, but no NPX is
  3727.  MM>         present
  3728.  
  3729.  MM> I thought maybe the default math lib include might be
  3730.  MM> to blame so I recompiled the program with the /fpc
  3731.  MM> option in my MAKEFILE.
  3732.  
  3733. Try setting the DPMI_MEMORY_LIMIT to at least 8 MB.  If this does not work,
  3734. tell us more about the programs that this occurs with, which version of the
  3735. compiler you are using, etc.
  3736.  
  3737.  
  3738. Kevin Kitsemetry
  3739. WATCOM TECHNICAL SUPPORT
  3740.  
  3741. *** This is a reply to #2478.
  3742.  
  3743.  
  3744. From:    Kevin Kitsemetry
  3745. To:      Bob Stout                              Msg #2484, Feb-24-94 11:11AM
  3746. Subject: C32_B.ZIP
  3747.  
  3748.  BS> The other evening, I DL'ed this file, then took a copy
  3749.  BS> to the office. The diskette got corrupted somehow
  3750.  BS> along the way and I'd already (stupidly!) deleted the
  3751.  BS> original. To avoid the half hour of LD charges once
  3752.  BS> again, could you tell me once more where this
  3753.  BS> available via anonymous ftp?
  3754.  
  3755. Sure, the ftp site is ftp-os2.cdrom.com.  It may be in the incoming
  3756. directory,or it may be in pub\os2\2_x\patches.
  3757.  
  3758.  
  3759. Kevin Kitsemetry
  3760. WATCOM TECHNICAL SUPPORT
  3761.  
  3762. *** This is a reply to #2479.  *** See also #2492.
  3763.  
  3764.  
  3765. From:    David Kennedy
  3766. To:      Peter Schauer                          Msg #2486, Feb-23-94 10:29AM
  3767. Subject: acc. 16bit dll's too
  3768.  
  3769.  PS> Internal Report #17054
  3770.  
  3771.  PS> I have some trouble with accesing 16-bit code in a MSC-
  3772.  PS> generated Dll too. ( MSG 1587 from Mr. Edward Palandri)
  3773.  PS> I red the problem but no solution (if exist). Can you
  3774.  PS> send it to me or please ship to me a additional
  3775.  PS> microcode to link with my application ( there seems to
  3776.  PS> be similar problems with FORTRAN ??!!??  MSG Nr.
  3777.  PS> ????). With the best regards from 'good old' germany
  3778.  PS> Peter
  3779.  
  3780. Kevin Kitsemitry is currently working on this problem, and will post a
  3781. solution if one can be found.
  3782.  
  3783. David Kennedy
  3784. WATCOM Languages Support
  3785.  
  3786. *** This is a reply to #2352.
  3787.  
  3788.  
  3789. From:    Kevin Blenkinsopp                      Rec'd
  3790. To:      Anthony Scian                          Msg #2488, Feb-23-94 07:55PM
  3791. Subject: Destructors redux...
  3792.  
  3793. Anthony,
  3794.  
  3795. (nb - this mail kind of grew. please bear with me...)
  3796.  
  3797. (sort of related to msg 2357). The reason I noticed the original problem is
  3798. that destructors for the Window class take the window off the screen (makes
  3799. sense!) Anyway, I'd realised a while back that there was still a problem with
  3800. that (eg the window that is created to put the thrown string in doesn't
  3801. disappear, etc) but wasn't really worried about because (1) you're exiting
  3802. anyway - screw it, and (2) it's nice to be able to see what was going on (if
  3803. the destructors got called, the screen would go blank pretty quickly!).
  3804. Anyway,I got this MemCheck toy the other day (which seems pretty cool, for the
  3805. benefit of anyone just browsing the mail - it's dirt cheap too!) and it
  3806. produced for me a tregabyte log file of "no free for malloc in win.cpp(##)"
  3807. and similar errors on exit. I understand the issue with exit() being an
  3808. ordinary fn etc (now! thank you.) BUT... I took it out, so main just
  3809. terminates normally (ie runs out of closing curly braces) and the destructors
  3810. for the threads don't  ... time passes as Kevin shells out for sec,
  3811. inspiration having struck...  F**K!! @%##$! (I'm back, in case you hadn't
  3812. guessed) Maybe if I'd bothered writing destructors for the threads that
  3813. deleted the windows they create, I wouldn't have gone through this!
  3814. AAAAAAAAAAAAAAAAARRRRGGHHH!!!
  3815.  
  3816. Dammit - I'm not aborting this email now! I remember something from the
  3817. previous exchange on this topic about the pre-release b-level destroying
  3818. things when it shouldn't really have to. The bug's been there all along
  3819. (months, actually!) and .... (Sob! Sniff!)
  3820.  
  3821. This is good. (No, really!) The new toy is working great, I can fix this
  3822. easily, and it explains something else that's been bothering me for a while.
  3823. Of course, it also means that you're right AGAIN, which is really starting to
  3824. p*ss me off. I think I'm getting senile.
  3825.  
  3826. One last thing (hope you're still reading this) - remember the zero-sized
  3827. array stuff that you added for b-level? Could you let the guys at StratosWare
  3828. know that it's in there (causes untrue error message). I'll try and notify
  3829. them as well.
  3830.  
  3831. Well, even though you didn't have to check anything this time, my putting this
  3832. down sparked the thought that fixed the bug (that ate the house that Jack
  3833. built), so...
  3834.  
  3835. Thanks Again.
  3836.  
  3837. Kevin
  3838.  
  3839. *** See also #2493.
  3840.  
  3841.  
  3842. From:    Jeff Petersen                          Rec'd
  3843. To:      Kevin Kitsemetry                       Msg #2489, Feb-24-94 10:50AM
  3844. Subject: HIWORD signed problem
  3845.  
  3846. Hello,
  3847.    I seem to be having a problem with the B-Level patches (I think the
  3848. unpatched version did this as well).  The problem is in Windows when I do a
  3849. HIWORD of lParam and assign it to a 16 bit signed int.  For example
  3850.  
  3851. LONG lParam;
  3852. int x = HIWORD(lParam);
  3853.  
  3854. If the high word of lParam is negative, it seems to do the conversion wrong. I
  3855. have tried all sort of typecasting with no luck.  I can't seem to properly get
  3856. a negative number out of the HIWORD of a LONG.  I am compiling with
  3857. optimization.
  3858.  
  3859. Jeff Petersen
  3860.  
  3861. *** See also #2494.
  3862.  
  3863.  
  3864. From:    Jeff Petersen
  3865. To:      Kim kitsemetry                         Msg #2490, Feb-24-94 12:07AM
  3866. Subject: switch problem
  3867.  
  3868. Hello,
  3869.  
  3870.     After installing the A and B level patches, my code quit working in
  3871. several locations.  The problem only occurs when optimizations are enabled and
  3872. it happens under DOS extended and Windows.  When I have a switch table with
  3873. numerically adjacent case values and the optimizer changes it to a jump table,
  3874. the jump table sends the code flow off into space (causing GP's of various
  3875. kinds).  For example:
  3876.  
  3877. switch(value)
  3878. {
  3879.    case 0:
  3880.         // do somthing
  3881.         break;
  3882.    case 1:
  3883.         break;
  3884.    case 2:
  3885.         break;
  3886.    case 3:
  3887.         break;
  3888.    case 4:
  3889.         break;
  3890.    case 5:
  3891.         break;
  3892. }
  3893.  
  3894. When compiling for optimizations if value is between 0 and 5, it will jump off
  3895. into space.  One case when it happened the function was fairly simple.  More
  3896. complex switch statements seem to work fine, as do switch statements with less
  3897. than 4 or so entries.  I solved the problem for now simply by changing the
  3898. switch to a series of 'if' statements.  My compile time options are:  /3r or
  3899. /5r and /oaxt.  I have not experimented with other compile time options except
  3900. /od which makes everything work fine.
  3901.  
  3902. Jeff Petersen 801-225-3846
  3903.  
  3904. *** See also #2495.
  3905.  
  3906.  
  3907. From:    Jason Blochowiak                       Rec'd
  3908. To:      Kevin Kitsemetry                       Msg #2491, Feb-24-94 01:23AM
  3909. Subject: Watcom & SoftICE & symbols
  3910.  
  3911.  Hmm, I presumed that (given the statements I've seen from folks here) that it
  3912. would be quicker to get a symbol translation type thingiemabob going than it
  3913. will be to get the new debugger finished & debugged.
  3914.  
  3915.  Speaking of debugging, I seem to have gotten my INT 31h/0300h stack wierdness
  3916. under Windows narrowed down to a pretty small case. I don't know anybody in an
  3917. appropriate group inside MicroSoft to contact about this, and I'd really
  3918. rather not "front-door" this. Any suggestions for a direct contact? I have
  3919. come up with a workaround (kludge #58374 for this project), but I'd prefer to
  3920. verify that it's necessary before making the workaround permanent.
  3921.  
  3922.  Jason
  3923.  
  3924. *** This is a reply to #2481.  *** See also #2496.
  3925.  
  3926.  
  3927. From:    Anthony Scian                          Rec'd
  3928. To:      Kevin Blenkinsopp                      Msg #2493, Feb-24-94 12:19PM
  3929. Subject: Destructors redux...
  3930.  
  3931.  KB> One last thing (hope you're still reading this) -
  3932.  KB> remember the zero-sized array stuff that you added for
  3933.  KB> b-level? Could you let the guys at StratosWare know
  3934.  KB> that it's in there (causes untrue error message). I'll
  3935.  KB> try and notify them as well.
  3936.  
  3937.  Kevin (our sysop Kevin), will you or Roger handle this call to StratosWare?
  3938.  
  3939.  KB> Well, even though you didn't have to check anything this time, my
  3940.  KB> putting this down sparked the thought that fixed the
  3941.  KB> bug (that ate the house that Jack built), so...
  3942.  
  3943.  Let's hope that your bug fix works!
  3944.  
  3945.  Anthony
  3946.  
  3947. *** This is a reply to #2488.
  3948.  
  3949.  
  3950. From:    Kevin Kitsemetry                       Rec'd
  3951. To:      Jeff Petersen                          Msg #2494, Feb-24-94 10:54AM
  3952. Subject: HIWORD signed problem
  3953.  
  3954.  JP> Hello,
  3955.  JP>    I seem to be having a problem with the B-Level
  3956.  JP> patches (I think the unpatched version did this as
  3957.  JP> well).  The problem is in Windows when I do a HIWORD
  3958.  JP> of lParam and assign it to a 16 bit signed int.  For
  3959.  JP> example
  3960.  
  3961.  JP> LONG lParam;
  3962.  JP> int x = HIWORD(lParam);
  3963.  
  3964.  JP> If the high word of lParam is negative, it seems to do
  3965.  JP> the conversion wrong. I have tried all sort of
  3966.  JP> typecasting with no luck.  I can't seem to properly
  3967.  JP> get a negative number out of the HIWORD of a LONG.  I
  3968.  JP> am compiling with optimization.
  3969.  
  3970. In Windows, HIWORD is a macro that is defined by Microsoft in one of the
  3971. Windows header files.  Take a look at the definition in the header file and
  3972. see if you can determine what the problem is.
  3973.  
  3974.  
  3975. Kevin Kitsemetry
  3976. WATCOM TECHNICAL SUPPORT
  3977.  
  3978. *** This is a reply to #2489.
  3979.  
  3980.  
  3981. From:    Kevin Kitsemetry                       Rec'd
  3982. To:      Jeff Petersen                          Msg #2495, Feb-24-94 11:06AM
  3983. Subject: switch problem
  3984.  
  3985.  JP> Hello,
  3986.  JP>
  3987.  JP>     After installing the A and B level patches, my
  3988.  JP> code quit working in several locations.  The problem
  3989.  JP> only occurs when optimizations are enabled and it
  3990.  JP> happens under DOS extended and Windows.  When I have a
  3991.  
  3992. I was not able to reproduce this here with the 'b' level
  3993. patches applied.  Run techinfo to make sure that the patches have been applied
  3994. properly.  If they have, I will need a
  3995. working example that I can use to reproduce the problem.
  3996. Include a makefile and a readme file and zip it together.
  3997.  
  3998.  
  3999. Kevin Kitsemetry
  4000. WATCOM TECHNICAL SUPPORT
  4001.  
  4002. *** This is a reply to #2490.  *** See also #2522.
  4003.  
  4004.  
  4005. From:    Kevin Kitsemetry                       Rec'd
  4006. To:      Jason Blochowiak                       Msg #2496, Feb-24-94 11:09AM
  4007. Subject: Watcom & SoftICE & symbols
  4008.  
  4009.  JB>  Hmm, I presumed that (given the statements I've seen
  4010.  JB> from folks here) that it would be quicker to get a
  4011.  JB> symbol translation type thingiemabob going than it
  4012.  JB> will be to get the new debugger finished & debugged.
  4013.  
  4014. The more you nag Numega for support, the quicker it will happen. They are
  4015. basically waiting until they have sufficient requests to support the WATCOM 32-
  4016. bit compiler.
  4017.  
  4018.  
  4019.  JB>  Speaking of debugging, I seem to have gotten my INT 31h/0300h stack
  4020.  JB> wierdness under Windows narrowed down to a pretty
  4021.  JB> small case. I don't know anybody in an appropriate
  4022.  JB> group inside MicroSoft to contact about this, and I'd
  4023.  JB> really rather not "front-door" this. Any suggestions
  4024.  JB> for a direct contact? I have come up with a workaround
  4025.  JB> (kludge #58374 for this project), but I'd prefer to
  4026.  JB> verify that it's necessary before making the
  4027.  JB> workaround permanent.
  4028.  
  4029. If you have a small example, you can upload it here.  Make sure you include a
  4030. readme file and a makefile.  Once I have had a chance to look at it, I can
  4031. make sure that it goes to the
  4032. appropriate person.
  4033.  
  4034.  
  4035. Kevin Kitsemetry
  4036. WATCOM TECHNICAL SUPPORT
  4037.  
  4038. *** This is a reply to #2491.  *** See also #2498.
  4039.  
  4040.  
  4041. From:    Jason Blochowiak                       Rec'd
  4042. To:      Kevin Kitsemetry                       Msg #2498, Feb-24-94 03:26PM
  4043. Subject: Watcom & SoftICE & symbols
  4044.  
  4045.  Ok, I'll nag the folks at NuMega, and get the other folks for whom this would
  4046. be useful to nag 'em as well.
  4047.  
  4048.  I'll package my DPMI 0300 problem up, and upload it here.
  4049.  
  4050.  Thanks,
  4051.  Jason
  4052.  
  4053. *** This is a reply to #2496.
  4054.  
  4055.  
  4056. From:    Thomas B. Pollard                      Rec'd
  4057. To:      Kevin Kitsemetry                       Msg #2499, Feb-24-94 04:01PM
  4058. Subject: SSCANF triggering nullp error in 1.95
  4059.  
  4060. TO Watcom 519-747-4971
  4061. FROM Tom Pollard 617-275-0100 Ex127
  4062. SSCANF triggering nullp error in 1.95
  4063. |
  4064. When  set DOS4G=NULLP I will get the null pointer while running the
  4065. 1.95 DOS4GW.EXE.  This was compiled under 9.5B
  4066. |
  4067. (test.c)
  4068. #include <stdio.h>
  4069. main()
  4070. {
  4071.    char dummy[80];
  4072.    short sampleNumber=0,rdfNumber=0,drNumber=0,daNumber=0;
  4073.    strcpy(dummy,"2.2");
  4074.    sscanf(dummy,"%hd.%hd.%hd.%hd",
  4075.        sampleNumber,rdfNumber,drNumber,daNumber);
  4076.    printf("buff = %d %d %d %d\n"
  4077.         ,sampleNumber,rdfNumber,drNumber,daNumber);
  4078. }
  4079. Has far as I can tell from the WATCOM C Library manual it leagal to
  4080. send sscanf a shorter string then what you have for a "format".  It would just
  4081. return a EOF
  4082.  
  4083. *** See also #2503.
  4084.  
  4085.  
  4086. From:    Jason Blochowiak                       Rec'd
  4087. To:      Kevin Kitsemetry                       Msg #2500, Feb-24-94 04:32PM
  4088. Subject: DPMI 0300 problem
  4089.  
  4090.  Hi. I just uploaded WINDPMI.ZIP to file area 12 - it contains the DPMI 0300
  4091. test program. Lemme know how it goes...
  4092.  
  4093.  Thanks,
  4094.  Jason
  4095.  
  4096. *** See also #2514.
  4097.  
  4098.  
  4099. From:    Ed Peddycoart
  4100. To:      All                                    Msg #2501, Feb-24-94 08:05PM
  4101. Subject: Inline Assembly Help Request
  4102.  
  4103. HELP! HELP! HELP! HELP! HELP! HELP! HELP! HELP! HELP! HELP! HELP! HELP! HELP!
  4104. HELP! HELP! HELP! HELP! HELP! HELP! HELP! HELP! HELP! HELP! HELP! HELP! HELP!
  4105.  
  4106. I need some help in recoding a function.  The function was originally written
  4107. using Borland C++ 3.1.  In fact, I downloaded this code from the Borland BBS.
  4108. I have since decided to use Watcom C/C++ 32 and I am unsure how to recode this
  4109. function using Watcom's inline assembly capability.  I am not an assembly
  4110. language programmer, but I do have some knowledge of assembly, although this
  4111. knowledge is limited. I would like to recode this function using inline
  4112. assembly.  (Which I have tried...but I am running short of time).  If this
  4113. cannot be done using inline assembly, I will need to write it as separate
  4114. linkable assembly file.  The problem with the latter option is I do not know
  4115. assembly well enough to write an assembly function, including the overhead,
  4116. that I link with my C code.
  4117.  
  4118.                     Can someone please help me?
  4119.  
  4120. The function I need help with is putRow(...).  I am generating real-time
  4121. animation (30 Hz) from digitized images stored on my hard disk. Therefore, I
  4122. need to be able to display images as fast as possible.  I will be using
  4123. 320x200 VGA mode. I believe the fast way to display these images is to write
  4124. them directly to video RAM.  These images are 128x128 so I cannot simply move
  4125. the entire image to 0xA000:0000 with one copy. I must move one row at a time.
  4126. The putRow function I have works great, ( I can animate at higher rates than
  4127. 30 Hz) but, once again, it is written for Borland C++, and I need help
  4128. converting it.
  4129.  
  4130.                   Any help would be appreaciated.
  4131.  
  4132. One restriction is that I need to be able to compile using the flat memory
  4133. model.
  4134.  
  4135. I am using a Compaq 486DX2/66 ProSignia, with DOS 6.2 and Watcom C/C 32 9.5
  4136. Patch Level B.
  4137.  
  4138. */
  4139. =============================================================================
  4140. /* The following is the function I need to re-code */
  4141. #include <DOS.H>
  4142.  
  4143. int rowOffset[200];  /* this holds the position from the beginning of
  4144.                         the video RAM at which each row starts.
  4145.                         Row 0   starts at rowOffset[0],
  4146.                         Row 1   starts at rowOffset[1],
  4147.                         .
  4148.                         .
  4149.                         .
  4150.                         Row 199 starts at rowOffset[199];
  4151.  
  4152.                         rowOffset[i] = 320 * i;*/
  4153.  
  4154.  
  4155.  
  4156. /*
  4157.    putRow places one row of image data, pointed to by data, of length,
  4158.    len, at (x,y).  It was written using Borland C++ 3.1.  This uses
  4159.    video mode 0x13.   rowOffset is an array of offsets to allow
  4160.    placement of rows which are less than 320 bytes in length. */
  4161.  
  4162. void putRow(unsigned x, unsigned y, char far *data, unsigned len){
  4163.  
  4164.    _ES = 0xA000;
  4165.    _DI = x + rowOffset[y];
  4166.    _SI = FP_OFF(data);
  4167.    _AX = FP_SEG(data);
  4168.    asm{
  4169.       push ds
  4170.       mov  ds, ax
  4171.       mov  cx, len
  4172.       cld
  4173.       rep  movsb
  4174.       pop  ds
  4175.    }
  4176. }
  4177.  
  4178.  
  4179. ==============================================================================
  4180.  
  4181. I have coded the following:
  4182.  
  4183. void putRow(unsigned,   /* 0xA000 - passed into ES         */
  4184.             unsigned,   /* x + rowOffset[y] - passed into di */
  4185.             unsigned,   /* FP_OFF(data) - passed into si     */
  4186.             unsigned,   /* FP_SEG(data) - passed into ax     */
  4187.             unsigned);  /* length - passed into cx           */
  4188.  
  4189. #pragma aux putRow =                    \
  4190.         "push ds",                      \
  4191.         "mov ds, ax",                   \
  4192.         "cld",                          \
  4193.         "rep movsb",                    \
  4194.         "pop ds",                       \
  4195.         parm [es][di][si][ax][cx]       ;
  4196.  
  4197.  
  4198. When I try to compile  (wcl386 /l=dos4g   filename.c) the program containing
  4199. this function I get the following message.
  4200.  
  4201.   gr.c(113): Error! E1122: Illegal register modified by 'putRow' #pragma
  4202.  
  4203. If I try to recompile using the small memory model
  4204.  
  4205.    wcl386 /ms /k81920 /l=dos4g filename.c)
  4206.                ^
  4207.                |____ To avoid stack overflow
  4208.  
  4209. and run the executable I get the following messages when call putRow...
  4210.  
  4211.    DOS/4GW error (2001): exception 0Dh (general protection fault)
  4212.    at 148:0033C083
  4213.    TSF32: prev_tsf32 5130
  4214.    SS       150 DS       150 ES       150 FS         0 GS        20
  4215.    EAX      150 EBX      100 ECX     FFFF EDX      150
  4216.    ESI     A000 EDI        0 EBP     F9FF ESP   36E14C
  4217.    CS:IP  148:0033C083 ID 0D COD   33A000 FLG    10246
  4218.    CS=  148, USE32, page granular, limit FFFFFFFF, base        0, acc CF9B
  4219.    SS=  150, USE32, page granular, limit FFFFFFFF, base        0, acc CF93
  4220.    DS=  150, USE32, page granular, limit FFFFFFFF, base        0, acc CF93
  4221.    ES=  150, USE32, page granular, limit FFFFFFFF, base        0, acc CF93
  4222.    FS=    0, USE16, byte granular, limit        0, base       13, acc  0
  4223.    GS=   20, USE16, byte granular, limit     FFFF, base     D270, acc 93
  4224.    CR0: PG:0 ET:1 TS:0 EM:0 MP:0 PE:1   CR2: 0 CR3: 0
  4225.    Crash address (unrelocated) = 1:00000083
  4226.  
  4227.  
  4228.                     Can someone please help me?
  4229.  
  4230.                   Any help would be appreaciated.
  4231.  
  4232. HELP! HELP! HELP! HELP! HELP! HELP! HELP! HELP! HELP! HELP! HELP! HELP! HELP!
  4233. HELP! HELP! HELP! HELP! HELP! HELP! HELP! HELP! HELP! HELP! HELP! HELP! HELP!
  4234.  
  4235.  
  4236. *** See also #2502.
  4237.  
  4238.  
  4239. From:    Jason Blochowiak                       Rec'd
  4240. To:      Ed Peddycoart                          Msg #2502, Feb-24-94 11:12PM
  4241. Subject: Inline Assembly Help Request
  4242.  
  4243.  Well, for what you're doing you don't really need inline assembly. Something
  4244. like:
  4245.  
  4246. void putRow(int x,int y,char *data,int len)
  4247. {
  4248.  memcpy(((char *)0xa0000) + x + rowOffset[y],data,len);
  4249. }
  4250.  
  4251.  should do the trick. Btw, if speed is really an issue, a REP MOVSW is likely
  4252. to perform substantially better on a large number of video cards as compared
  4253. to a REP MOVSB. If you're only dealing with a 128x128 image, though, I
  4254. wouldn't worry about it.
  4255.  
  4256.  This function won't deal with far data, but if you're only dealing with flat
  4257. model stuff, that shouldn't be an issue.
  4258.  
  4259.  Jason
  4260.  
  4261. *** This is a reply to #2501.
  4262.  
  4263.  
  4264. From:    Anthony Scian                          Rec'd
  4265. To:      Thomas B. Pollard                      Msg #2503, Feb-25-94 10:13AM
  4266. Subject: SSCANF triggering nullp error in 1.95
  4267.  
  4268.  TBP> TO Watcom 519-747-4971
  4269.  TBP> FROM Tom Pollard 617-275-0100 Ex127
  4270.  TBP> SSCANF triggering nullp error in 1.95
  4271.  TBP> |
  4272.  TBP> When  set DOS4G=NULLP I will get the null pointer while running the
  4273.  TBP> 1.95 DOS4GW.EXE.  This was compiled under 9.5B
  4274.  TBP> |
  4275.  TBP> (test.c)
  4276.  TBP> #include <stdio.h>
  4277.  TBP> main()
  4278.  TBP> {
  4279.  TBP>    char dummy[80];
  4280.  TBP>    short sampleNumber=0,rdfNumber=0,drNumber=0,daNumber=0;
  4281.  TBP>    strcpy(dummy,"2.2");
  4282.  TBP>    sscanf(dummy,"%hd.%hd.%hd.%hd",
  4283.  TBP>        sampleNumber,rdfNumber,drNumber,daNumber);
  4284.  TBP>    printf("buff = %d %d %d %d\n"
  4285.  TBP>         ,sampleNumber,rdfNumber,drNumber,daNumber);
  4286.  TBP> }
  4287.  TBP> Has far as I can tell from the WATCOM C Library manual it leagal to
  4288.  TBP> send sscanf a shorter string then what you have for a
  4289.  TBP> "format".  It would just return a EOF
  4290.  
  4291. Assuming you didn't make a mistake typing this in, you forgot to pass the
  4292. addresses of the variables you want scanf to set for you. Since you set them
  4293. to 0, you got a NULL access error.
  4294.  
  4295.  
  4296. *** This is a reply to #2499.  *** See also #2513.
  4297.  
  4298.  
  4299. From:    Anthony Scian                          Rec'd
  4300. To:      Ed Peddycoart                          Msg #2504, Feb-25-94 10:16AM
  4301. Subject: Inline Assembly Help Request
  4302.  
  4303.  EP> I have coded the following:
  4304.  
  4305.  EP> void putRow(unsigned,   /* 0xA000 - passed into ES         */
  4306.  EP>             unsigned,   /* x + rowOffset[y] - passed into di */
  4307.  EP>             unsigned,   /* FP_OFF(data) - passed into si     */
  4308.  EP>             unsigned,   /* FP_SEG(data) - passed into ax     */
  4309.  EP>             unsigned);  /* length - passed into cx           */
  4310.  
  4311.  EP> #pragma aux putRow =                    \
  4312.  EP>         "push ds",                      \
  4313.  EP>         "mov ds, ax",                   \
  4314.  EP>         "cld",                          \
  4315.  EP>         "rep movsb",                    \
  4316.  EP>         "pop ds",                       \
  4317.  EP>         parm [es][di][si][ax][cx]       ;
  4318.  
  4319. Use movsw instead of what Borland used:
  4320.  
  4321.      void putRow( void *, void *, unsigned );
  4322.      #pragma aux putRow =        \
  4323.           "shr ecx,1"           \
  4324.           "rep movsw"                   \
  4325.           "adc ecx,ecx"         \
  4326.           "rep movsb"           \
  4327.           parm [edi] [esi] [ecx];
  4328.  
  4329.     ...
  4330.     putRow( 0xA0000 + x + rowOffset[y], data, len );
  4331.  
  4332. If you know len is divisible by 2, use
  4333.  
  4334.      #pragma aux putRow =        \
  4335.           "rep movsw",                  \
  4336.           parm [edi] [esi] [ecx];
  4337.  
  4338.         ...
  4339.     putRow( 0xA0000 + x + rowOffset[y], data, len >> 1 );
  4340.  
  4341. If you know len is divisible by 4, use
  4342.  
  4343.      #pragma aux putRow =        \
  4344.           "rep movsd",                  \
  4345.           parm [edi] [esi] [ecx];
  4346.  
  4347.         ...
  4348.     putRow( 0xA0000 + x + rowOffset[y], data, len >> 2 );
  4349.  
  4350. *** This is a reply to #2501.
  4351.  
  4352.  
  4353. From:    David Hewitt
  4354. To:      Watcom                                 Msg #2505, Feb-28-94 10:10AM
  4355. Subject: Bug Report (1 of 3)
  4356.  
  4357. KK> Internal Report #18708
  4358.  
  4359.  
  4360. /* WATBUG1.C        Feb 19, 1994
  4361.  *
  4362.  * Two bugs where compiler FAILS TO DIAGNOSE ERROR and one header glitch.
  4363.  *
  4364.  * Header Glitch:
  4365.  * write() in io.h needs to have 'const' attrib added to void pointer
  4366.  *
  4367.  * BUGS:
  4368.  *
  4369.  * 1) the compiler FAILS to WARN about y->bug[0] assignement
  4370.  *
  4371.  * 2) the compiler FAILS to WARN about the uninitialized
  4372.  * variable 'i' in  the line 'if (t != r->z[i].t)'
  4373.  *
  4374.  * Tested with 9.5b patches using the command line
  4375.  *   wcc386 /W4 watbug1.c
  4376.  *
  4377.  * David Hewitt,
  4378.  * Edbro Software Inc.
  4379.  * (416) 364-3711
  4380.  */
  4381.  
  4382. struct FOO
  4383.     {
  4384.     int ok;
  4385.     int bug[5];
  4386.     int * notbug;
  4387.     };
  4388.  
  4389.  
  4390. void bug1(const struct FOO * y)
  4391. {
  4392.     y->notbug[0] = 0;   /* ok, compiler thinks bitwise 'const'ness */
  4393.     y->bug[0] = 0;  /* BUG, compiler accepts without warning */
  4394.     y->ok = 0;      /* ok, compiler warns of assign to const */ }
  4395.  
  4396.  
  4397.  
  4398. struct S1
  4399.     {
  4400.     struct
  4401.         {
  4402.         int t;
  4403.         } z[30];
  4404.     };
  4405.  
  4406.  
  4407. void foobar(
  4408. struct S1 * r,
  4409. int t
  4410. )
  4411. {
  4412.     int i;
  4413.     int row;
  4414.  
  4415.     /* if this code is removed, compiler sees unitialized 'i' */
  4416.     row = 1;
  4417.     if (row > 1)
  4418.         return;
  4419.  
  4420.     if (t != r->z[i].t)
  4421.         return;
  4422.  
  4423.     /* move them all down one */
  4424.     for (i = 1;  i < 5;  i++)
  4425.         r->z[i - 1].t = 0;
  4426. }
  4427.  
  4428.  
  4429.  
  4430. From:    David Hewitt
  4431. To:      Watcom                                 Msg #2506, Feb-25-94 05:06PM
  4432. Subject: Bug Report (2 of 3)
  4433.  
  4434. /* WATBUG2.C        Feb 19, 1994
  4435.  *
  4436.  * Compiler Parse/Code Generation BUG.
  4437.  *
  4438.  * Constants 1e300 or cause execution errors.  When 1e300 is generated
  4439.  * by multiplication, the code seems to work
  4440.  *
  4441.  * In the program below, various cases are shown.  No output is generated
  4442.  * for a correctly executing program.  The results from 9.5b are:
  4443.  *
  4444.  * Under released version, the program executes correctly
  4445.  * >> DOS/4GW Protected Mode Run-time  Version 1.9
  4446.  * >> Copyright (c) Rational Systems, Inc. 1990-1993
  4447.  * >> Test Completed
  4448.  *
  4449.  * Under 9.5a and 9.5b the program fails
  4450.  * >> DOS/4GW Protected Mode Run-time  Version 1.95
  4451.  * >> Copyright (c) Rational Systems, Inc. 1990-1993
  4452.  * >> Test 4 failed
  4453.  * >> Test 5 failed
  4454.  * >> Test Completed
  4455.  *
  4456.  * >> DOS/4GW Protected Mode Run-time  Version 1.95
  4457.  * >> Copyright (c) Rational Systems, Inc. 1990-1993
  4458.  * >> Test 4 failed
  4459.  * >> Test 5 failed
  4460.  * >> Test Completed
  4461.  *
  4462.  *
  4463.  * David Hewitt
  4464.  * (416) 364-3711
  4465.  * Edbro Software Inc.
  4466.  *
  4467.  * Compiled with wcl386 /mf /d2 watbug2.c
  4468.  */
  4469.  
  4470. #include <math.h>
  4471. #include <stdio.h>
  4472.  
  4473.  
  4474. double foo2 = 1e200 * 1e100;
  4475. #define FOO3 (1e200 * 1e100)
  4476. double foo4 = 1e300;
  4477.  
  4478. void main(void)
  4479. {
  4480.     double testval = 60.0;
  4481.  
  4482.     if (testval >= 9.99999e299)
  4483.         printf( "Test 1 failed\n" );
  4484.  
  4485.     if (testval >= foo2)
  4486.         printf( "Test 2 failed\n" );
  4487.  
  4488.     if (testval >= FOO3)
  4489.         printf( "Test 3 failed\n" );
  4490.  
  4491.     if (testval >= foo4)
  4492.         printf( "Test 4 failed\n" );
  4493.  
  4494.     if (testval >= 1e300)
  4495.         printf( "Test 5 failed\n" );
  4496.  
  4497.     printf( "Test completed\n" );
  4498. }                               /* main() */
  4499.  
  4500.  
  4501.  
  4502. *** See also #2555.
  4503.  
  4504.  
  4505. From:    David Hewitt
  4506. To:      Watcom                                 Msg #2507, Feb-25-94 05:07PM
  4507. Subject: Bug Report
  4508.  
  4509. /* WATBUG3.C        Feb 25, 1994
  4510.  *
  4511.  * BUG.  When an EXE is run in a directory whose full path is
  4512.  * too long, the WRONG exe name will be reported in 'argv[0]'
  4513.  *
  4514.  * The following batch file will demonstrate the problem:
  4515.  *
  4516.  * >>> @echo off
  4517.  * >>> wcl386 /mf /l=dos4g watbug3.c
  4518.  * >>>
  4519.  * >>> mkdir \12345678
  4520.  * >>> copy watbug3.exe \12345678\.
  4521.  * >>>
  4522.  * >>> mkdir \12345678\a
  4523.  * >>> copy watbug3.exe \12345678\a\.
  4524.  * >>>
  4525.  * >>> mkdir \12345678\abcd
  4526.  * >>> copy watbug3.exe \12345678\abcd\.
  4527.  * >>>
  4528.  * >>> \12345678\watbug3
  4529.  * >>> \12345678\a\watbug3
  4530.  * >>> \12345678\abcd\watbug3
  4531.  *
  4532.  * Results:
  4533.  
  4534. *** This is correct ***
  4535. DOS/4GW Protected Mode Run-time  Version 1.95
  4536. Copyright (c) Rational Systems, Inc. 1990-1993
  4537. argv[0]=C:\12345678\WATBUG3.EXE
  4538.  
  4539. *** This is correct ***
  4540. DOS/4GW Protected Mode Run-time  Version 1.95
  4541. Copyright (c) Rational Systems, Inc. 1990-1993
  4542. argv[0]=C:\12345678\A\WATBUG3.EXE
  4543.  
  4544. >>>>> *** This is WRONG *** <<<<<
  4545. DOS/4GW Protected Mode Run-time  Version 1.95
  4546. Copyright (c) Rational Systems, Inc. 1990-1993
  4547. argv[0]=G:\WC9.5B\BIN\dos4gw.exe
  4548.  
  4549. >>>>> *** ^^^^^^^^^^^^^^^^^ <<<<<
  4550.  
  4551.  */
  4552.  
  4553. #include <stdio.h>
  4554.  
  4555. int main(
  4556. int argc,
  4557. char * argv[]
  4558. )
  4559. {
  4560.     int i;
  4561.  
  4562.     for (i = 0;  i < argc;  i++)
  4563.         printf( "argv[%d]=%s\n", i, argv[i] );
  4564. }                               /* main() */
  4565.  
  4566.  
  4567.  
  4568. From:    Patrick Lamb                           Rec'd
  4569. To:      Anthony Scian                          Msg #2508, Feb-24-94 04:59PM
  4570. Subject: printf/getch/graphics?
  4571.  
  4572. AS> You are combining two families of functions that are not supposed to
  4573. AS> interact with each other.  If you use getch(), you should use cprintf().
  4574. AS> If you use getchar(), you can use printf().
  4575.  
  4576. Charlie Brown should have helped invent C.  Then we would have a special
  4577. function
  4578.  
  4579. void ARRRRRRRRGGGHHH (void)
  4580.  
  4581. for cases of missing brain bytes.  Thanks for reminding me!
  4582.  
  4583. Pat
  4584.  
  4585.  
  4586. From:    Joseph Molnar                          Rec'd
  4587. To:      David Kennedy                          Msg #2509, Feb-28-94 10:17AM
  4588. Subject: Hello ... I have a PROBLEM
  4589.  
  4590. This is the fourth message I have posted about this problem and yet I haven't
  4591. heard a response back yet.  The only one I did get wasn't about what I was
  4592. referring to.
  4593.  
  4594. I AM HAVING A PROBLEM WITH TOKEN PASTING. THE FOLLOWING CODE DOESN'T WORK!
  4595.  
  4596. #define TEXT( x ) L##x
  4597.  
  4598. THIS SHOULD GENERATE TEXT STRINGS OF TYPE LONG CHAR, BUT IT IS NOT!
  4599.  
  4600. According to the SDK this is how you should encode strings if you wish to
  4601. change back and forth between UNICODE and char's.  But again, this isn't
  4602. working.   Is anyone reading this?  Please I need a response back since a
  4603. product is depending on this, I will either be switching to C8 or knowing what
  4604. is happening here, use Watcom.
  4605.  
  4606. Also:  Does your Resource Compiler for NT read the NT extensions for resources?
  4607.  
  4608. One more thing I got the following warning:
  4609.  
  4610. e:\source\lexical\relex\cpp\relex.cpp(548): Warning! W389: (col 84) integral
  4611. value may be truncated during assignment or initialization
  4612.  
  4613. on the following code:
  4614.  
  4615. typeEscapeValue = ( typeEscapeValue << 4 ) + ( ( typeChar - CHAR_A ) + 10 );
  4616.  
  4617. typeEscapeValue is a BYTE& (note: BYTE is a macro for unsigned char) typeChar
  4618. is a BYTE
  4619. CHAR_A is a macro for the the letter 'A'
  4620.  
  4621. While I can fix the warning by putting brackets around the rvalue and then
  4622. putting a type cast to BYTE in front, but I don't understand why I would have
  4623. to here?  I would think that the expression does evalue to a BYTE since all
  4624. values and variables involved are BYTE's (the values should be coerced to BYTE
  4625. by the compiler without warnings as well).  This is not really a problem, but
  4626. I was curious ... the only thing I could think of was the fact that the shift
  4627. could chop off some bits.  Just curious.
  4628.  
  4629. Thanks
  4630. Joseph
  4631.  
  4632. *** See also #2518.
  4633.  
  4634.  
  4635. From:    Matt Howard
  4636. To:      All                                    Msg #2510, Feb-26-94 02:43PM
  4637. Subject: debugger problems
  4638.  
  4639. I've got a graphics app that needs some files that are assembled by Turbo
  4640. Assembler. I've gotten the compiler and linker to work, but I have no idea how
  4641. to get the right debug info in those files so I can use WVIDEO. I tried using
  4642. TOWV.EXE but it said the object files were not in the correct format (I no
  4643. they have the debug info since I compiled with tasm /zi). Actually this
  4644. wouldn't be that bad on its own. What is ridiculous is that I can't get any
  4645. executables with more than one .cpp file to show up in the debugger, even
  4646. though I'm using the -d2 compiler option and the DEBUG ALL linker option. Why
  4647. is this?
  4648.  
  4649. No offense, but though I really like your compiler, but this debugger is
  4650. impossible. I don't care how many powerful options it may have, but they're
  4651. all useless if I can't even get my source files to show up. At this point,
  4652. I've resorted to compiling all my files with the Borland compiler, and
  4653. debugging with Turbo Debugger, even though my assembly files won't work in
  4654. real mode. At least I can see my source and set breaks and watches easily.
  4655. Then I recompile with Watcom and just hope for the best. There must be an
  4656. easier method!
  4657.  
  4658. Thanks in advance.
  4659.  
  4660. *** See also #2515.
  4661.  
  4662.  
  4663. From:    John Miles                             Rec'd
  4664. To:      Kevin Kitsemetry                       Msg #2511, Feb-27-94 05:06PM
  4665. Subject: Patch application error
  4666.  
  4667. When installing the B-level patches, the following occurred when trying
  4668. to modify several .lib files:
  4669.  
  4670. Patching r:\shared\tools\wat95b\lib386\math387s.lib
  4671. WATCOM Library Manager Version 3.0
  4672. Copyright by WATCOM International Corp. 1998, 1993. All rights reserved.
  4673. WATCOM is a trademark of WATCOM International Corp.
  4674. Error!  Expected '<module_name>'
  4675.         in '-<module_name>'
  4676.         but found '<eol>'.
  4677.  
  4678. Am I hosed?
  4679.  
  4680. Also, I had previously modified my WLSYSTEM.LNK file to support
  4681. Flashtek builds.  This caused the patch utility to complain that it
  4682. wasn't the correct size.  Can you e-mail me a list of changes to
  4683. WLSYSTEM.LNK under the B patches, so that I can apply them manually
  4684. and avoid trouble later?
  4685.  
  4686. -- john
  4687.  
  4688. *** See also #2516.
  4689.  
  4690.  
  4691. From:    Markus Nordenstam
  4692. To:      All                                    Msg #2512, Feb-28-94 06:53AM
  4693. Subject: 3D graphics
  4694.  
  4695. Does anyone know of a powerful 3D graphics library for the Watcom C++32
  4696. compiler (or any other 32-bit compiler) that does texture mapping, physics and
  4697. such things. (i.e., a Wolfenstein 3D-Ultima Underworld-DOOM type of engine?)
  4698. How much does it cost and who makes it?
  4699. Any reply is greatly appreciated.
  4700.  
  4701. *** See also #2517.
  4702.  
  4703.  
  4704. From:    Thomas B. Pollard                      Rec'd
  4705. To:      Anthony Scian                          Msg #2513, Feb-28-94 08:28AM
  4706. Subject: SSCANF triggering nullp error in 1.95
  4707.  
  4708. TO Watcom 519-747-4971
  4709. FROM Tom Pollard 617-275-0100 Ex127
  4710. SSCANF triggering nullp error in 1.95
  4711. |
  4712. I am sorry, you are right.  The original program was using pointers
  4713. and I simplified it so I could report the error but I forgot to change
  4714. the call.
  4715. |
  4716. What I found out, is that the original program was not testing
  4717. for the string being null so the nullp pointer error would be
  4718. triggered inside SSCANF at that point, and not on the passed variables.
  4719. |
  4720. Sorry about the faults alarm, and thanks.
  4721.  
  4722. *** This is a reply to #2503.
  4723.  
  4724.  
  4725. From:    Kevin Kitsemetry                       Rec'd
  4726. To:      Jason Blochowiak                       Msg #2514, Feb-28-94 10:00AM
  4727. Subject: DPMI 0300 problem
  4728.  
  4729.  JB>  Hi. I just uploaded WINDPMI.ZIP to file area 12 - it
  4730.  JB> contains the DPMI 0300 test program. Lemme know how it
  4731.  JB> goes...
  4732.  
  4733. I will take a look at, thanks.  This is now incident number 18703.
  4734.  
  4735. Kevin
  4736.  
  4737. *** This is a reply to #2500.
  4738.  
  4739.  
  4740. From:    Kevin Kitsemetry                       Rec'd
  4741. To:      Matt Howard                            Msg #2515, Feb-28-94 10:20AM
  4742. Subject: debugger problems
  4743.  
  4744.  MH> I've got a graphics app that needs some files that are assembled by
  4745.  MH> Turbo Assembler. I've gotten the compiler and linker
  4746.  MH> to work, but I have no idea how to get the right debug
  4747.  MH> info in those files so I can use WVIDEO. I tried using
  4748.  MH> TOWV.EXE but it said the object files were not in the
  4749.  MH> correct format (I no they have the debug info since I
  4750.  MH> compiled with tasm /zi). Actually this wouldn't be
  4751.  MH> that bad on its own. What is ridiculous is that I
  4752.  MH> can't get any executables with more than one .cpp file
  4753.  MH> to show up in the debugger, even though I'm using the -
  4754.  MH> d2 compiler option and the DEBUG ALL linker option.
  4755.  
  4756. Is /zi line number information, or full symbolic information? If you assemble
  4757. with line number information it should work,without having to convert it.
  4758. When using the compiler and
  4759. linker, make sure that DEBUG ALL is the very first linker
  4760. directive that you specify.
  4761.  
  4762.  
  4763.  MH> No offense, but though I really like your compiler, but this debugger is
  4764.  MH> impossible. I don't care how many powerful options it
  4765.  MH> may have, but they're all useless if I can't even get
  4766.  MH> my source files to show up. At this point, I've
  4767.  MH> resorted to compiling all my files with the Borland
  4768.  MH> compiler, and debugging with Turbo Debugger, even
  4769.  MH> though my assembly files won't work in real mode. At
  4770.  MH> least I can see my source and set breaks and watches
  4771.  MH> easily. Then I recompile with Watcom and just hope for
  4772.  MH> the best. There must be an easier method!
  4773.  
  4774. Coming soon is a new GUI version of the debugger.  It has been totally
  4775. revamped and should make things a lot better for its users.
  4776.  
  4777.  
  4778. Kevin Kitsemetry
  4779. WATCOM TECHNICAL SUPPORT
  4780.  
  4781. *** This is a reply to #2510.  *** See also #2548.
  4782.  
  4783.  
  4784. From:    Kevin Kitsemetry                       Rec'd
  4785. To:      John Miles                             Msg #2516, Feb-28-94 10:26AM
  4786. Subject: Patch application error
  4787.  
  4788.  JM> When installing the B-level patches, the following occurred when trying
  4789.  JM> to modify several .lib files:
  4790.  JM>
  4791.  JM> Patching r:\shared\tools\wat95b\lib386\math387s.lib
  4792.  JM> WATCOM Library Manager Version 3.0
  4793.  JM> Copyright by WATCOM International Corp. 1998, 1993. All rights reserved.
  4794.  JM> WATCOM is a trademark of WATCOM International Corp.
  4795.  JM> Error!  Expected '<module_name>'
  4796.  JM>         in '-<module_name>'
  4797.  JM>         but found '<eol>'.
  4798.  JM>
  4799.  JM> Am I hosed?
  4800.  
  4801. I believe you are.  Can you re-install the compiler and apply the patches
  4802. again?  Check and make sure that the C32_B.ZIP file and the 3m87rl.b file are
  4803. the correct sizes first.
  4804. (they are 4608 and 1551419 resp'ly).
  4805.  
  4806.  
  4807.  JM> Also, I had previously modified my WLSYSTEM.LNK file to support
  4808.  JM> Flashtek builds.  This caused the patch utility to complain that it
  4809.  JM> wasn't the correct size.  Can you e-mail me a list of changes to
  4810.  JM> WLSYSTEM.LNK under the B patches, so that I can apply them manually
  4811.  JM> and avoid trouble later?
  4812.  
  4813. You should back the files up just for this reason!!!
  4814.  
  4815. Here is the file:
  4816.  
  4817.  
  4818. # example linker initialization file.
  4819. system begin dos
  4820.     libpath %WATCOM%\lib286
  4821.     libpath %WATCOM%\lib286\dos
  4822.     format dos ^
  4823. end
  4824. system begin dos4g
  4825.     option osname='Rational Systems'
  4826.     libpath %WATCOM%\lib386
  4827.     libpath %WATCOM%\lib386\dos
  4828.     op stub=wstub.exe
  4829.     format os2 le
  4830. end
  4831. system begin pharlap
  4832.     libpath %WATCOM%\lib386
  4833.     libpath %WATCOM%\lib386\dos
  4834.     format phar ^
  4835. end
  4836. system begin ergo
  4837.     option osname='Ergo'
  4838.     libpath %WATCOM%\lib386
  4839.     libpath %WATCOM%\lib386\dos
  4840.     format phar ^
  4841. end
  4842. system begin win386
  4843.     option osname='Windows 32-bit'
  4844.     libpath %WATCOM%\lib386
  4845.     libpath %WATCOM%\lib386\win
  4846.     disable 62  # export and import not valid warning.
  4847.     format phar rex
  4848. end
  4849. system begin os2
  4850.     option osname='OS/2 16-bit'
  4851.     libpath c:\os2
  4852.     libpath %WATCOM%\lib286
  4853.     libpath %WATCOM%\lib286\os2
  4854.     format os2 ^
  4855. end
  4856. system begin windows
  4857.     option osname='Windows 16-bit'
  4858.     libpath %WATCOM%\lib286
  4859.     libpath %WATCOM%\lib286\win
  4860.     library windows
  4861.     option stack=8k, heapsize=1k
  4862.     format windows ^
  4863. end
  4864. system begin os2v2
  4865.     option osname='OS/2 32-bit'
  4866.     libpath %WATCOM%\lib386
  4867.     libpath %WATCOM%\lib386\os2
  4868.     libpath %TOOLKIT%\os2lib
  4869.     format os2 lx ^
  4870. end
  4871. system begin os2v2_pm
  4872.     option osname='OS/2 32-bit presentation manager'
  4873.     libpath %WATCOM%\lib386
  4874.     libpath %WATCOM%\lib386\os2
  4875.     libpath %TOOLKIT%\os2lib
  4876.     format os2 lx pm ^
  4877. end
  4878. system begin novell
  4879.     format novell ^
  4880.     libpath %WATCOM%\lib386
  4881.     libpath %WATCOM%\lib386\netware
  4882.     module clib
  4883.     import @%WATCOM%\novi\clib.imp
  4884. end
  4885. system begin netware
  4886.     format novell ^
  4887.     libpath %WATCOM%\lib386
  4888.     libpath %WATCOM%\lib386\netware
  4889.     module clib
  4890.     import @%WATCOM%\novi\clib.imp
  4891. end
  4892. system begin ads
  4893.     option osname='AutoCAD Devlopment System'
  4894.     libpath %WATCOM%\lib386
  4895.     libpath %WATCOM%\lib386\dos
  4896.     libfile adsstart
  4897.     format phar ext ^
  4898. end
  4899. system begin eadi
  4900.     option osname='emulation AutoCAD Device Interface'
  4901.     libpath %WATCOM%\lib386
  4902.     libpath %WATCOM%\lib386\dos
  4903.     libfile adiestrt
  4904.     format phar ext ^
  4905. end
  4906. system begin fadi
  4907.     option osname='floating point AutoCAD Device Interface'
  4908.     libpath %WATCOM%\lib386
  4909.     libpath %WATCOM%\lib386\dos
  4910.     libfile adifstrt
  4911.     format phar ext ^
  4912. end
  4913. system begin com
  4914.     option osname='DOS .COM'
  4915.     libpath %WATCOM%\lib286
  4916.     libpath %WATCOM%\lib286\dos
  4917.     libfile cstart_t
  4918.     format dos com
  4919. end
  4920. system begin codebuilder
  4921.     option osname='Codebuilder'
  4922.     libpath %WATCOM%\lib386
  4923.     libpath %WATCOM%\lib386\dos
  4924.     format phar rex
  4925. end
  4926. system begin qnx
  4927.     option osname='QNX 16-bit'
  4928.     libpath %WATCOM%\lib286
  4929.     libpath %WATCOM%\lib286\qnx
  4930.     format qnx
  4931. end
  4932. system begin qnx386
  4933.     option osname='QNX 32-bit'
  4934.     libpath %WATCOM%\lib386
  4935.     libpath %WATCOM%\lib386\qnx
  4936.     format qnx ^
  4937. end
  4938. system begin penpoint
  4939.     option osname=Penpoint
  4940.     libpath %PENPOINT_PATH%\sdk\lib
  4941.     format os2 le ^
  4942. end
  4943. system begin nt
  4944.     option osname='Windows NT character-mode'
  4945.     libpath %WATCOM%\lib386
  4946.     libpath %WATCOM%\lib386\nt
  4947.     format windows nt ^
  4948.     runtime console
  4949. end
  4950. system begin tnt
  4951.     option osname='Phar Lap TNT dos style'
  4952.     libpath %WATCOM%\lib386
  4953.     libpath %WATCOM%\lib386\dos
  4954.     format windows nt tnt ^
  4955.     runtime dosstyle
  4956. end
  4957. system begin nt_win
  4958.     option osname='Windows NT windowed'
  4959.     libpath %WATCOM%\lib386
  4960.     libpath %WATCOM%\lib386\nt
  4961.     format windows nt ^
  4962. end
  4963. system begin nt_dll
  4964.     option osname='Windows NT'
  4965.     libpath %WATCOM%\lib386
  4966.     libpath %WATCOM%\lib386\nt
  4967.     format windows nt dll ^
  4968. end
  4969.  
  4970. *** This is a reply to #2511.
  4971.  
  4972.  
  4973. From:    Kevin Kitsemetry
  4974. To:      Markus Nordenstam                      Msg #2517, Feb-28-94 10:31AM
  4975. Subject: 3D graphics
  4976.  
  4977.  MN> Does anyone know of a powerful 3D graphics library for
  4978.  MN> the Watcom C++32 compiler (or any other 32-bit
  4979.  MN> compiler) that does texture mapping, physics and such
  4980.  MN> things. (i.e., a Wolfenstein 3D-Ultima Underworld-DOOM
  4981.  MN> type of engine?)
  4982.  
  4983. You can take a look at some of the ISV's in file area 8.
  4984. Perhaps one of the companies in there can help out.  There
  4985. are probably others available, they just haven't notified us of their support
  4986. for our compiler.
  4987.  
  4988.  
  4989. Kevin Kitsemetry
  4990. WATCOM TECHNICAL SUPPORT
  4991.  
  4992. *** This is a reply to #2512.
  4993.  
  4994.  
  4995. From:    Anthony Scian                          Rec'd
  4996. To:      Joseph Molnar                          Msg #2518, Feb-28-94 11:56AM
  4997. Subject: Hello ... I have a PROBLEM
  4998.  
  4999.  JM> This is the fourth message I have posted about this
  5000.  JM> problem and yet I haven't heard a response back yet.
  5001.  JM> The only one I did get wasn't about what I was
  5002.  JM> referring to.
  5003.  
  5004.  JM> I AM HAVING A PROBLEM WITH TOKEN PASTING. THE
  5005.  JM> FOLLOWING CODE DOESN'T WORK!
  5006.  
  5007.  JM> #define TEXT( x ) L##x
  5008.  
  5009.  JM> THIS SHOULD GENERATE TEXT STRINGS OF TYPE LONG CHAR, BUT IT IS NOT!
  5010.  
  5011.  JM> According to the SDK this is how you should encode strings if you wish
  5012.  JM> to change back and forth between UNICODE and char's.
  5013.  JM> But again, this isn't working.   Is anyone reading
  5014.  JM> this?  Please I need a response back since a product
  5015.  JM> is depending on this, I will either be switching to C8
  5016.  JM> or knowing what is happening here, use Watcom.
  5017.  
  5018.  This has been fixed in the next patch level (C).
  5019.  
  5020.  JM> One more thing I got the following warning:
  5021.  
  5022.  JM> e:\source\lexical\relex\cpp\relex.cpp(548): Warning!
  5023.  JM> W389: (col 84) integral value may be truncated during
  5024.  JM> assignment or initialization
  5025.  
  5026.  JM> on the following code:
  5027.  
  5028.  JM> typeEscapeValue = ( typeEscapeValue << 4 ) + ( (
  5029.  JM> typeChar - CHAR_A ) + 10 );
  5030.  
  5031.  JM> typeEscapeValue is a BYTE& (note: BYTE is a macro for
  5032.  JM> unsigned char) typeChar is a BYTE
  5033.  JM> CHAR_A is a macro for the the letter 'A'
  5034.  
  5035.  JM> While I can fix the warning by putting brackets around the rvalue and
  5036.  JM> then putting a type cast to BYTE in front, but I don't
  5037.  JM> understand why I would have to here?  I would think
  5038.  JM> that the expression does evalue to a BYTE since all
  5039.  JM> values and variables involved are BYTE's (the values
  5040.  JM> should be coerced to BYTE by the compiler without
  5041.  JM> warnings as well).  This is not really a problem, but
  5042.  JM> I was curious ... the only thing I could think of was
  5043.  JM> the fact that the shift could chop off some bits.
  5044.  
  5045. Everything gets promoted to an int and the compiler has no way of knowing what
  5046. the runtime values of variables are going to be.  Wrap the entire expr with a
  5047. BYTE( expr ).
  5048.  
  5049. Anthony
  5050.  
  5051. *** This is a reply to #2509.  *** See also #2520.
  5052.  
  5053.  
  5054. From:    Joseph Molnar                          Rec'd
  5055. To:      Anthony Scian                          Msg #2520, Feb-28-94 02:17PM
  5056. Subject: Thanks
  5057.  
  5058. Thanks for your replay, but when do you expect the C level patches to be out.
  5059. We would really like this problem fixed by tomorrow.  I know that seems a
  5060. short time away, but I posted my first message about the same time the b-level
  5061. patches came and you were my first response.  Is it in anyway possible that I
  5062. could get a patch to just this problem.  C8 is currently our only other
  5063. alternative, and it doesn't have template support (something I am using a lot,
  5064. and most template pre-processors are garbage).  We are trying to put a beta
  5065. out of the product by the end of this week, so we have to intergrate our code
  5066. sometime between now and then,  I like WatcomC++ much better than MSC8 (not
  5067. just because of the template support either), and the token pasting problem is
  5068. smaller than the template problem, so we would prefer to use Watcom for
  5069. obvious reasons.
  5070.  
  5071. A couple more questions:
  5072.  
  5073. 1) I mentioned the resource compiler earlier, do you know if it supports NT
  5074. specific features?
  5075.  
  5076. 2) Is the run-time check facility being planned for a near release of Watcom
  5077. C++?
  5078.  
  5079. 3) Are Alpha or MIPS version of the compiler expected for NT?  I know this is
  5080. a big one since your entire back-end would have to change.
  5081.  
  5082. 4) When should we expect the new debugger and IDE?
  5083.  
  5084. I had one other, but I can't recall currently.  Thanks for the help and if you
  5085. could get a patch for the token paste problem would we be EXTREMELY happy
  5086. <GRIN>.
  5087.  
  5088. Joseph
  5089.  
  5090. *** This is a reply to #2518.  *** See also #2540.
  5091.  
  5092.  
  5093. From:    Jeff Petersen
  5094. To:      Kevin Kitsemetry                       Msg #2522, Mar-01-94 03:21PM
  5095. Subject: switch problem
  5096.  
  5097. KK> Internal Report #18932
  5098.  
  5099.  
  5100. Kevin,
  5101.    I was unable to reproduce the problem in a simple situation, however, I
  5102. have uploaded my source file that is causing the problem as well as a wdisasm
  5103. listing of the .obj.  As I noted in the included readme file, it appears that
  5104. the compiler is creating a jump table, but then forgetting to include the jump
  5105. table data in the .obj.  You will find the upload under the name COMCOVER.ZIP
  5106.  
  5107. Jeff
  5108.  
  5109. *** This is a reply to #2495.
  5110.  
  5111.  
  5112. From:    David Kennedy                          Rec'd
  5113. To:      Ramon Rivas                            Msg #2524, Feb-28-94 03:33PM
  5114. Subject: Ergo
  5115.  
  5116.  RR> Hi David,
  5117.  RR>    Any news on that Ergo problem?
  5118.  RR> Ramon.
  5119. The problem of debugging Ergo applications is still being looked into.
  5120.  
  5121. David Kennedy
  5122. WATCOM Languages Support
  5123.  
  5124. *** This is a reply to #2456.
  5125.  
  5126.  
  5127. From:    Kevin Blenkinsopp                      Rec'd
  5128. To:      Kevin Kitsemetry                       Msg #2526, Feb-28-94 07:19PM
  5129. Subject: DPMI 800
  5130.  
  5131. Kevin,
  5132.  
  5133. I noticed recently that somebody else had the same problem that I did with
  5134. accessing memory WAAAY up there. I can't remember his nameor find the message,
  5135. but 1729 has my first description of the problem in it. Could you resurrect
  5136. this please? I'd love to be able to tell you what the card I'm working with is
  5137. so that you can try and reproduce the problem, but I'm under a non-disclosure
  5138. right now, so I need to get an okay from them first.
  5139.  
  5140. Went back and search messages: Julian Ayling, 2433 & 2435. I noticed you said
  5141. you spoke to him by phone. If you have a fix or any advice, can you please
  5142. call me or post it here?
  5143.  
  5144. Thanks,
  5145.  
  5146. Kevin
  5147.  
  5148. *** See also #2535.
  5149.  
  5150.  
  5151. From:    Michael M. McDaniel                    Rec'd
  5152. To:      Kevin Kitsemetry                       Msg #2527, Mar-01-94 02:22AM
  5153. Subject: rfx traps on laptop
  5154.  
  5155. Hi -
  5156. I have a problem with rfx or serserve when I use it on my laptop. I have the
  5157. following laptop computer that I connect using a laplink cable to a Compaq 486
  5158. ProLinea or a clone 386/40Mhz machine. The laptop is described below.
  5159. Afterwards, the command and error condition are described as follows after the
  5160. laptop description...
  5161.  
  5162. Twinhead 486DX/40Mhz Subnote BIOS information
  5163.  
  5164. CL-GD6412 VGA BIOS Version 1.00D
  5165. Copyright 1991-1993 Cirrus Logic, Inc.  All Rights Reserved. Copyright 1987-
  5166. 1990 Quadtel Corp. All Rights Reserved.
  5167. 6412 08/18/93
  5168.  
  5169. PhoenixBIOS(TM) Phoenix NoteBIOS 486/OPTi463 Version 1.03
  5170. Phoenix MISER V2.0
  5171. Copyright (C) 1985-1993 Phoenix Technologies, Ltd.
  5172. All Rights Reserved
  5173.  
  5174. 80486 BIOS Version 1.1, 11/17/93, All Rights Reserved
  5175.  
  5176. Operating at 33 Mhz
  5177.  
  5178. TOSHIBA MK1522FCV
  5179.  
  5180. Databook CardTalk Bootstrap Manager V2.20.12 Aug 12, 1993
  5181. Copyright (C) Databook Incorporated 1990-93
  5182.  
  5183. Performing Self Test...passed
  5184.  
  5185.  
  5186. Enter password: xxx
  5187. Password OK
  5188.  
  5189. ===========================
  5190. ON HOST DESKTOP MACHINE (this command starts ok)
  5191. [e:\] serserv
  5192.  
  5193. ON LAPTOP
  5194. [e:\watcom] rfx ser;1
  5195.  
  5196. TRAP 000D ERRCD=0000 ERACC=**** ERLIM=********
  5197. EAX=11b50000 EBX=fca70300 ECX=00000060 EDX=fff20300
  5198. ESI=fca704e6 EDI=ffffffff EBP=00005232 FLG=00012246
  5199. CS:EIP=0698:00001406 CSACC=009b CSLIM=0000299f
  5200. SS:ESP=0030:00005226 SSACC=1097 SSLIM=0000460b
  5201. DS=0690 DSACC=0093 DSLIM=0000c97b CR0=8001001b
  5202. ES=0690 ESACC=0093 ESLIM=0000c97b CR2=fff86f94
  5203. FS=0000 FSAC=**** FSLIM=********
  5204. GS=0000 GSAC=**** GSLIM=********
  5205.  
  5206. The system detected an internal processing
  5207. error at location ##0160:fff5fbd5-000d:9bd5
  5208. 60000,9084
  5209.  
  5210. 048600b4
  5211. Internal revision 6.540, 93/07/ 14
  5212.  
  5213.  
  5214.  
  5215. If I use the laptop as the server, and start serserv first on the laptop, all
  5216. appears well until I start 'rfx ser' on the desktop, and then the laptop gets
  5217. the Trap 000d error.
  5218.  
  5219. Any suggestions?? Twinhead phone number is 1-800-767-TWIN
  5220.  
  5221. As per your request,
  5222.  
  5223. FOLLOWS is the information from techinfo (run on the laptop, which is the
  5224. system with the problem; I have tried two different brand desktop
  5225. machines,makes no difference - even if the laptop is not connected to another
  5226. machine this trap occurs)
  5227.  
  5228. WATCOM's Techinfo Utility, Version 1.3
  5229. Current Time: Thu Feb 24 19:06:00 1994
  5230.  
  5231. WATCOM           Phone: (519) 884-0702
  5232. 415 Phillip St.         Fax: (519) 747-4971
  5233. Waterloo, Ontario
  5234. CANADA    N2L 3X2
  5235.  
  5236. ------------------WATCOM C Environment Variables ----------------
  5237. WATCOM=<e:\watcom>
  5238. INCLUDE=<E:\WATCOM\H;E:\TOOLKIT\C\OS2H;E:\TOOLKT21\C\OS2H;E:\TOOLKT21\C\OS2H\VD
  5239. ;E:\TOOLKT21\ASM\OS2INC;>
  5240. LIB=<E:\WATCOM\LIB386;E:\WATCOM\LIB286;E:\TOOLKT21\OS2LIB;>
  5241. PATH=<C:\OS2;C:\OS2\SYSTEM;C:\OS2\INSTALL;E:\WATCOM\BINB;E:\WATCOM\BINP;E:\TOOL
  5242. T21\OS2BIN;C:\;C:\OS2\APPS;C:\USR\BIN;>
  5243.  
  5244. File 'e:\watcom\binp\wcc.exe' has been patched to level '.a' File
  5245. 'e:\watcom\binp\wcc386.exe' has been patched to level '.a' File
  5246. 'e:\watcom\binp\wpp.exe' has been patched to level '.a' File
  5247. 'e:\watcom\binp\wpp386.exe' has been patched to level '.a' File
  5248. 'e:\watcom\binp\wvideo.exe' has been patched to level '.a' File
  5249. 'e:\watcom\binb\wlink.exe' has been patched to level '.a' File
  5250. 'e:\watcom\binp\wlink.exe' has been patched to level '.a' File
  5251. 'e:\watcom\binb\wlib.exe' has been patched to level '.a' ------------------
  5252. WATCOM SQL Environment Variables ----------------... ERROR...WSQL environment
  5253. variable not set.
  5254.  
  5255. Amount of free memory 524288 bytes
  5256. OS/2 Version 20.10$$$$$$$$
  5257.  
  5258. ------------C:\CONFIG.SYS-------------
  5259.  
  5260. rem call=c:\os2\cmd.exe /c c:\archive\desktop\restordk.cmd
  5261. call=c:\os2\cmd.exe /c c:\usr\bin\pswrd.exe
  5262.  
  5263. set ipfc=E:\TOOLKT21\IPFC;
  5264. set helpndx=EPMKWHLP.NDX
  5265. set toolkit=e:\toolkt21
  5266. set watcom=e:\watcom
  5267. set
  5268. include=E:\WATCOM\H;E:\TOOLKT21\C\OS2H;E:\TOOLKT21\C\OS2H\VDD;E:\TOOLKT21\ASM\O
  5269. 2INC;set lib=E:\WATCOM\LIB386;E:\WATCOM\LIB286;E:\TOOLKT21\OS2LIB;
  5270.  
  5271. PROTSHELL=C:\OS2\PMSHELL.EXE
  5272. SET USER_INI=C:\OS2\OS2.INI
  5273. SET SYSTEM_INI=C:\OS2\OS2SYS.INI
  5274. SET OS2_SHELL=C:\OS2\CMD.EXE
  5275. SET AUTOSTART=PROGRAMS,TASKLIST,FOLDERS,CONNECTIONS
  5276.  
  5277. rem SET RUNWORKPLACE=C:\OS2\PMSHELL.EXE
  5278. rem set runworkplace=c:\os2\cmd.exe
  5279. set runworkplace=e:\src\minishel\mshell.exe
  5280.  
  5281. SET COMSPEC=C:\OS2\CMD.EXE
  5282. LIBPATH=.;C:\OS2\DLL;C:\OS2\MDOS;C:\;C:\OS2\APPS\DLL;C:\USR\DLL;E:\WATCOM\BINP\
  5283. LL;E:\TOOLKT21\DLL;SET
  5284. PATH=C:\OS2;C:\OS2\SYSTEM;C:\OS2\INSTALL;E:\WATCOM\BINB;E:\WATCOM\BINP;E:\TOOLK
  5285. 21\OS2BIN;C:\;C:\OS2\APPS;C:\USR\BI N;
  5286. SET
  5287. DPATH=C:\OS2;C:\OS2\SYSTEM;C:\OS2\INSTALL;C:\;C:\OS2\BITMAP;C:\OS2\MDOS;C:\OS2\
  5288. PPS;SET PROMPT=$i[$c$r$f,$p]
  5289. SET HELP=C:\OS2\HELP;C:\OS2\HELP\TUTORIAL;E:\TOOLKT21\OS2HELP;SET
  5290. GLOSSARY=C:\OS2\HELP\GLOSS;
  5291. SET IPF_KEYS=SBCS
  5292. PRIORITY_DISK_IO=YES
  5293. FILES=20
  5294. DEVICE=C:\OS2\TESTCFG.SYS
  5295.  
  5296. rem DEVICE=C:\OS2\DOS.SYS
  5297.  
  5298. DEVICE=C:\OS2\PMDD.SYS
  5299. rem BUFFERS=30
  5300. buffers=20
  5301. IOPL=YES
  5302. rem DISKCACHE=128,LW,AC:Ce
  5303. rem diskcache=64,LW,AC:ce
  5304. diskcache=128,LW,32,AC:ce
  5305.  
  5306. MAXWAIT=3
  5307. rem maxwait=2
  5308.  
  5309.  
  5310. MEMMAN=SWAP,PROTECT
  5311. rem SWAPPATH=C:\OS2\SYSTEM 4096 6144
  5312. swappath=e:\ 2048 8192
  5313. BREAK=OFF
  5314. rem THREADS=128
  5315. threads=64
  5316. rem PRINTMONBUFSIZE=134,134,134
  5317. COUNTRY=001,C:\OS2\SYSTEM\COUNTRY.SYS
  5318. SET KEYS=ON
  5319. REM SET DELDIR=C:\DELETE,512;D:\DELETE,512;E:\DELETE,512;
  5320.  
  5321. rem BASEDEV=PRINT01.SYS
  5322.  
  5323. BASEDEV=IBM1FLPY.ADD
  5324. BASEDEV=IBM1S506.ADD
  5325. BASEDEV=OS2DASD.DMD
  5326. SET BOOKSHELF=C:\OS2\BOOK;E:\TOOLKT21\BOOK;E:\WATCOM\BINP\HELP;C:\USR\BOOK;SET
  5327. EPMPATH=C:\OS2\APPS;
  5328. DEVICE=C:\OS2\APPS\SASYNCDA.SYS
  5329.  
  5330. rem PROTECTONLY=NO
  5331. rem protectonly = yes disables dos and win-os/2 sessions
  5332. protectonly=yes
  5333.  
  5334. rem SHELL=C:\OS2\MDOS\COMMAND.COM
  5335. rem C:\OS2\MDOS FCBS=16,8
  5336. rem RMSIZE=640
  5337. rem DEVICE=C:\OS2\MDOS\VEMM.SYS
  5338. rem DOS=LOW,NOUMB
  5339. rem DEVICE=C:\OS2\MDOS\VDPX.SYS
  5340. rem DEVICE=C:\OS2\MDOS\VXMS.SYS /UMB
  5341. rem DEVICE=C:\OS2\MDOS\VDPMI.SYS
  5342. rem DEVICE=C:\OS2\MDOS\VCDROM.SYS
  5343.  
  5344. DEVICE=C:\OS2\APM.SYS
  5345. rem DEVICE=C:\OS2\MDOS\VAPM.SYS
  5346.  
  5347. rem DEVICE=C:\OS2\PCMCIA.SYS
  5348. rem DEVICE=C:\OS2\MDOS\VPCMCIA.SYS
  5349. rem DEVICE=C:\OS2\MDOS\VMOUSE.SYS
  5350. rem DEVICE=C:\OS2\POINTDD.SYS
  5351. DEVICE=C:\OS2\MOUSE.SYS
  5352. DEVICE=C:\OS2\COM.SYS
  5353. rem DEVICE=C:\OS2\MDOS\VCOM.SYS
  5354. CODEPAGE=437,850
  5355. DEVINFO=KBD,US,C:\OS2\KEYBOARD.DCP
  5356. DEVINFO=SCR,VGA,C:\OS2\VIOTBL.DCP
  5357. SET VIDEO_DEVICES=VIO_VGA
  5358. SET VIO_VGA=DEVICE(BVHVGA)
  5359. DEVICE=C:\OS2\MDOS\VVGA.SYS
  5360.  
  5361. SET TMP=E:\
  5362. SET PROGREF21=CPGREF1.INF+CPGREF2.INF+CPGREF3.INF
  5363. SET PMREF=PMFUN.INF+PMGPI.INF+PMHOK.INF+PMMSG.INF+PMREL.INF+PMWIN.INF+PMWKP.INF
  5364.  
  5365.  
  5366. call=c:\os2\cmd.exe
  5367.  
  5368. rem end config.sys
  5369.  
  5370.  
  5371. ------------C:\AUTOEXEC.BAT-------------
  5372. @ECHO OFF
  5373. ECHO.
  5374. PROMPT $i$p$g
  5375. REM SET DELDIR=C:\DELETE,512;D:\DELETE,512;E:\DELETE,512;
  5376. PATH C:\OS2;C:\OS2\MDOS;C:\;
  5377. LOADHIGH APPEND C:\OS2;C:\OS2\SYSTEM
  5378. SET TMP=C:\
  5379. REM LOADHIGH DOSKEY FINDFILE=DIR /A /S /B $*
  5380. REM DOSKEY EDIT=QBASIC/EDITOR $*
  5381. REM SET DIRCMD=/A
  5382.  
  5383. ------------------------------------------------------
  5384. A Intel 486 processor is installed in this system.
  5385. 486 math coprocessor is present
  5386. Skipping math coprocessor interrupt check.
  5387.  
  5388.  
  5389. -- Michael M. McDaniel
  5390.  
  5391.  
  5392. *** See also #2536.
  5393.  
  5394.  
  5395. From:    Michael M. McDaniel                    Rec'd
  5396. To:      Kevin Kitsemetry                       Msg #2528, Mar-01-94 02:40AM
  5397. Subject: IBM Link386
  5398.  
  5399. Hi,
  5400. IBM's Link386 has a switch /RUNFROMVDM which allows a native os/2 application
  5401. to run from within an os/2 virtual dos machine. i.e. similar to an os/2 window
  5402. starting up the msdos resources when you type an msdos executable name, when
  5403. you type the os/2 program from within the vdm, the proper resources are started
  5404. and the os/2 executable runs.
  5405.  
  5406. QUESTION: is there some similar mechanism with the Watcom linker?
  5407. QUESTION: if not, how do I get my *.obj from the Watcom compiler to link with
  5408.           Link386 ?? Link386 (so far) has wanted libraries that I don't have.
  5409.  
  5410. ++thanks,
  5411. Michael M. McDaniel
  5412.  
  5413. *** See also #2537.
  5414.  
  5415.  
  5416. From:    Michael M. McDaniel
  5417. To:      Denis Dyack                            Msg #2529, Mar-01-94 02:56AM
  5418. Subject: Net Bios Help
  5419.  
  5420. Denis,
  5421. perhaps by now you've already seen this book, but I recommend
  5422.  
  5423. C Programmer's Guide to NetBIOS, IPX, and SPX
  5424. by W. David Schwaderer
  5425. published by SAMS Publishing
  5426. ISBN # 0-672-30050-8
  5427.  
  5428. It includes a 3.5" disk w/some sample code.
  5429.  
  5430. -- Michael M. McDaniel
  5431.  
  5432. *** This is a reply to #2004.
  5433.  
  5434.  
  5435. From:    Michael M. McDaniel                    Rec'd
  5436. To:      Kevin Kitsemetry                       Msg #2530, Mar-01-94 03:01AM
  5437. Subject: latest patches to v9.5 C/C++
  5438.  
  5439. Hi,
  5440.  
  5441. sorry for taking up this space - just realized I want to phone instead...
  5442.  
  5443. -- Michael M. McDaniel
  5444.  
  5445.  
  5446. From:    Michael M. McDaniel                    Rec'd
  5447. To:      Anthony Scian                          Msg #2531, Mar-01-94 03:11AM
  5448. Subject: C++9.5a bug???
  5449.  
  5450. Anthony, as some extra information...
  5451. I wrote and delivered a standalone industrial machine (It punched specialized
  5452. paper tapes for a loom). Anyway, the software ran on an AT. I used C++ for
  5453. the entire machine control libray (classes built upon classes, etc.).
  5454.  
  5455. The compiler I used was Borland C++ v3.1, and I used Turbo Vision for the
  5456. user front end.
  5457.  
  5458. Well, when I bought Watcom C/C++, I wanted to convert my code over. I
  5459. recompiled the machine control class libraries first. Lo and behold, I got
  5460. more than a couple of compile errors with Watcom. Being an new Watcom user,
  5461. I at first thought the compiler had problems. Upon investigating all of the
  5462. problems (2d edition of Stroustrup's 'C++ Programming Language' as the
  5463. standard) I discovered that Borland had been, shall we say, rather lenient
  5464. in compiling code that was definitely illegal. In some cases, the error
  5465. was subtle, but Watcom properly complained about things that Borland was
  5466. happy to compile.
  5467.  
  5468. Also, some of my own personal utilities I recompiled for OS/2 (my platform
  5469. of choice these days). HEY, the utilities worked fine under MSDOS and UNIX.
  5470. But, sometimes they had problems under OS/2. Again, when I dug out the
  5471. standard documentation (this time ANSI C), my programs were incorrect, and
  5472. the errors could have (legally) occurred on any OS. These problems were
  5473. mostly tied in with the use of *envp[], getenv(), and putenv().
  5474.  
  5475. So, now I double-check my language references first.
  5476.  
  5477. Hope this is useful...
  5478.  
  5479. --Michael M. McDaniel
  5480.  
  5481. *** This is a reply to #2088.
  5482.  
  5483.  
  5484. From:    Mark Spychalla
  5485. To:      Support                                Msg #2532, Mar-01-94 06:34AM
  5486. Subject: Internal compiler error
  5487.  
  5488. Hello,
  5489.  
  5490.    The following program demonstrates an interal error under Watcom C32 for
  5491.    DOS 9.5
  5492.  
  5493. %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
  5494.   Mark Spychalla (Email: spy@dpls.dacc.wisc.edu)
  5495. %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
  5496.  
  5497. %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
  5498. First the techinfo for my system:
  5499. %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
  5500.  
  5501. WATCOM's Techinfo Utility, Version 1.3
  5502. Current Time: Tue Mar  1 03:54:52 1994
  5503.  
  5504. WATCOM           Phone: (519) 884-0702
  5505. 415 Phillip St.         Fax: (519) 747-4971
  5506. Waterloo, Ontario
  5507. CANADA    N2L 3X2
  5508.  
  5509. ------------------WATCOM C Environment Variables ----------------
  5510. WATCOM=<C:\WATCOM\.>
  5511. INCLUDE=<C:\WATCOM\h;C:\X-32\INCLUDE;C:\FG\INCLUDE>
  5512. LIB=<c:\x-32\lib;c:\fg\lib>
  5513. PATH=<C:\X-
  5514. 32\BIN;C:\WATCOM\BIN;C:\WATCOM\BINB;C:\SC\BIN;C:\DOS;C:\UTIL;C:\NU;C:\WINDOWS;C
  5515. \SPEEDRV;C:\EMX\BIN> File 'C:\WATCOM\.\bin\wcc386.exe' has not been patched
  5516. File 'C:\WATCOM\.\bin\wvideo.exe' has not been patched
  5517. File 'C:\WATCOM\.\bin\wlink.exe' has not been patched
  5518. File 'C:\WATCOM\.\binb\wlib.exe' has not been patched
  5519. ------------------WATCOM SQL Environment Variables ----------------...
  5520. ERROR...WSQL environment variable not set.
  5521.  
  5522. Amount of extended memory is: 0K
  5523. Amount of base memory is: 640K
  5524. Amount of free base memory is: 459216 bytes
  5525. DOS Version 6.0
  5526.  
  5527. ------------C:\CONFIG.SYS-------------
  5528. DEVICE=C:\DOS\HIMEM.SYS
  5529. DEVICE=C:\DOS\EMM386.EXE
  5530. BUFFERS=10
  5531. FILES=35
  5532. lastdrive=C
  5533. DEVICEHIGH=C:\DOS\SETVER.EXE
  5534. DOS=HIGH
  5535. STACKS=9,256
  5536. SHELL=C:\DOS\COMMAND.COM /E:2048 /P
  5537. BREAK=ON
  5538. rem DEVICEHIGH=C:\DOS\RAMDRIVE.SYS 512 /E
  5539. DEVICEHIGH=C:\UTIL\FASTBIOS.SYS
  5540. DEVICEHIGH=C:\UTIL\EANSI.SYS
  5541. DEVICEHIGH=C:\UTIL\AD.SYS
  5542.  
  5543. ------------C:\AUTOEXEC.BAT-------------
  5544. rem C:\DOS\SMARTDRV.EXE
  5545. rem C:\NU\NCACHE2 INSTALL
  5546. C:\SPEEDRV\SPEEDRV /INSTALL
  5547. @ECHO OFF
  5548. PROMPT $p$g
  5549.  
  5550. rem SET COMSPEC=C:\DOS\COMMAND.COM
  5551. APPEND=C:\DOS
  5552. rem COPY C:\DOS\COMMAND.COM c:\ >NUL
  5553.  
  5554. rem Symantec C++ development stuff
  5555.  
  5556. rem SET INCLUDE=C:\X-
  5557. 32\INCLUDE;C:\FG\INCLUDE;C:\SC\INCLUDE;C:\SC\INCLUDE\WIN16;C:\SC\INCLUDE\WIN32;
  5558. :\SC\MFC\INCLUDE rem SET LIB=C:\FG\LIB;C:\SC\LIB;C:\SC\MFC\LIB;C:\X-32\LIB
  5559. rem SET HELP=C:\SC\HELP
  5560. rem PATH C:\SC\BIN;C:\FG\BIN
  5561.  
  5562. rem Watcom C development stuff
  5563.  
  5564. path C:\X-32\BIN;C:\WATCOM\bin;C:\WATCOM\binb;C:\SC\bin
  5565. set include=C:\WATCOM\h;C:\X-32\INCLUDE;C:\FG\INCLUDE
  5566. set watcom=C:\WATCOM\.
  5567. set lib=c:\x-32\lib;c:\fg\lib
  5568.  
  5569. rem EMX development stuff
  5570.  
  5571. set C_INCLUDE_PATH=c:/emx/include
  5572. set LIBRARY_PATH=c:/emx/lib
  5573.  
  5574. PATH=%PATH%;C:\DOS;C:\UTIL;C:\NU;C:\WINDOWS;C:\SPEEDRV;C:\EMX\BIN SET NU=C:\NU
  5575.  
  5576. c:\F-PROT\VIRSTOP
  5577. c:\mouse\mouse
  5578.  
  5579. c:\wced\wced -aldt c:\wced\wced.ini
  5580. rem c:\UTIL\bells.com
  5581. c:\nu\ncc /set c:\nu\nu.cfg
  5582.  
  5583. rem set TMPDIR=d:
  5584. rem set TEMP=d:
  5585. set TMP=c:\tmp
  5586. set TEMP=c:\tmp
  5587.  
  5588. rem set NO87=1
  5589. rem c:\demo\univbe
  5590. rem c:\vesa\univesa
  5591.  
  5592. ------------------------------------------------------
  5593. A Intel 486 processor is installed in this system.
  5594. 486 math coprocessor is present
  5595.         and Equipment Flags say math coprocessor IS present. The next test may
  5596. cause the system to hang if 486
  5597.         interrupts are not handled properly.
  5598. 486 interrupts are properly enabled.
  5599.  
  5600. ------------------------------------------------------
  5601. APPEND                  INSTALLED
  5602.  
  5603. %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
  5604. The makefile:
  5605. %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
  5606.  
  5607. bug1.obj:       bug1.c
  5608.         wcl386 /ore -c bug1.c
  5609.  
  5610. %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
  5611. The C file (bug1.c)
  5612. %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
  5613.  
  5614. typedef struct type1{
  5615.   float X, Y;
  5616. } type1;
  5617.  
  5618. typedef struct type2{
  5619.   char c;
  5620.   type1 t1;
  5621. } type2;
  5622.  
  5623. void proc()
  5624. {
  5625.   type2 *ptr1, *ptr2;
  5626.   type1 v1, v2;
  5627.   float a;
  5628.   char c2;
  5629.  
  5630.         a = v1.X * v2.Y - v1.Y * v2.X;
  5631.         ptr1->c = ((a > 0) == c2);
  5632.         v1 = ptr1->t1;
  5633.         v2 = ptr2->t1;
  5634.         a = v1.X * v2.Y - v1.Y * v2.X;
  5635.         ptr2->c = ((a > 0) == c2);
  5636. }
  5637.  
  5638. %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
  5639. The internal compiler error from the make (bug1.err):
  5640. %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
  5641.  
  5642. bug1.c(23): Error! E1119: Internal compiler error 76
  5643.  
  5644. %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
  5645.  
  5646.    I also have experienced a totally different bug with the compiler for
  5647.    which I unfortunately have not been able to generate a simple C file
  5648.    to demonstrate.  It happens that on large executables (> .5 MEG), using
  5649.    the flat memory model, and math coprocessor emulation (e.g. using
  5650.    a CFLAGS = -l=X32RV /oailrmnt /oe=50 /s /fpc /zp4 ) occasionally
  5651.    floating point expressions involving addition operations will have an
  5652.    expressions added twice instead of only once.  I am quite certain that
  5653.    the C source code is correct because the correct numeric result is
  5654.    generated when using the math coprocessor with the Watcom compiler or
  5655.    when using either the math coprocessor or math emulation under the
  5656.    Symantec C++ 6.0 compiler on the same C source tree.
  5657.  
  5658.    May you find the above information helpful in improving your fine
  5659.    compiler, and I'll try applying the latest patches and see if they fix
  5660.    the bugs.
  5661.  
  5662.    Mark Spychalla
  5663.  
  5664. %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
  5665.  
  5666. *** See also #2538.
  5667.  
  5668.  
  5669. From:    Jim Ehrismann                          Rec'd
  5670. To:      David Kennedy                          Msg #2533, Mar-01-94 01:49PM
  5671. Subject: _harderr() problem
  5672.  
  5673. * Original From: Chris Boogmans (1:221/186)
  5674. * Original To  : David Kennedy (1:221/186)
  5675.  
  5676. Hi,
  5677. i am using C32 version 9.5b in a DOS+DOS/4GW environment. Following a problem
  5678. i had when installing a critical error handler using _harderr(), i had a look
  5679. at the assembly code which is called on int 24h. DOS passes a pointer to the
  5680. device header in BP:SI. The WatCom library has to convert this pointer to a
  5681. pointer in the flat model; this is the part of the WatCom lib code which should
  5682. do that (try it if BP:SI is for example = 0FFF:0010) :
  5683.  sub  ebx, ebx
  5684.  mov  bx, bp
  5685.  shl  ebx, 4
  5686.  add  bx, si        ; here, the carry (if any) gets lost, RESULT = WRONG
  5687. POINTER
  5688. Could this be corrected for the c level patches ?
  5689. Thanks, Chris.
  5690.  
  5691.  
  5692. From:    Jim Ehrismann                          Rec'd
  5693. To:      David Kennedy                          Msg #2534, Mar-01-94 01:50PM
  5694. Subject: _harderr()
  5695.  
  5696. Whoops, I guess Forward is not exactly what I wanted to do. I forwarded the
  5697. previous message to you to request the fix for this as soon as possible. I
  5698. have reported problems with _harderr() in the past but never gotten a
  5699. useable solution. This may be it!
  5700.  
  5701.                                         Jim
  5702.  
  5703.  
  5704. From:    Kevin Kitsemetry                       Rec'd
  5705. To:      Kevin Blenkinsopp                      Msg #2535, Mar-01-94 03:26PM
  5706. Subject: DPMI 800
  5707.  
  5708.  KB> Kevin,
  5709.  
  5710.  KB> I noticed recently that somebody else had the same
  5711.  KB> problem that I did with accessing memory WAAAY up
  5712.  KB> there. I can't remember his nameor find the message,
  5713.  
  5714. Basically, we are not aware of any problems with mapping
  5715. things WAAAY up there, so to speak.  We would need an
  5716. example.  Perhaps the problem can be duplicated by taking
  5717. a card such as a soundcard (relatively inexpensive)?
  5718.  
  5719.  
  5720. Kevin Kitsemetry
  5721. WATCOM TECHNICAL SUPPORT
  5722.  
  5723. *** This is a reply to #2526.  *** See also #2542.
  5724.  
  5725.  
  5726. From:    Kevin Kitsemetry
  5727. To:      Michael M. McDaniel                    Msg #2536, Mar-01-94 04:33PM
  5728. Subject: rfx traps on laptop
  5729.  
  5730.  MMM> Hi -
  5731.  MMM> I have a problem with rfx or serserve when I use it
  5732.  MMM> on my laptop. I have the following laptop computer
  5733.  MMM> that I connect using a laplink cable to a Compaq 486
  5734.  MMM> ProLinea or a clone 386/40Mhz machine. The laptop is
  5735.  MMM> described below. Afterwards, the command and error
  5736.  MMM> condition are described as follows after the laptop
  5737.  MMM> description...
  5738.  
  5739. Just a quick observation - you are using serserv with a
  5740. parallel cable!?!
  5741.  
  5742. Also, if you are in a DOS box, make sure you have the
  5743. proper session settings for direct access to the com
  5744. port.
  5745.  
  5746.  
  5747. Kevin Kitsemetry
  5748. WATCOM TECHNICAL SUPPORT
  5749.  
  5750. *** This is a reply to #2527.
  5751.  
  5752.  
  5753. From:    Kevin Kitsemetry
  5754. To:      Michael M. McDaniel                    Msg #2537, Mar-01-94 04:43PM
  5755. Subject: IBM Link386
  5756.  
  5757.  MMM> Hi,
  5758.  MMM> IBM's Link386 has a switch /RUNFROMVDM which allows a
  5759.  MMM> native os/2 application
  5760.  MMM> to run from within an os/2 virtual dos machine. i.e.
  5761.  MMM> similar to an os/2 window
  5762.  MMM> starting up the msdos resources when you type an
  5763.  MMM> msdos executable name, when
  5764.  MMM> you type the os/2 program from within the vdm, the
  5765.  MMM> proper resources are started
  5766.  MMM> and the os/2 executable runs.
  5767.  
  5768.  MMM> QUESTION: is there some similar mechanism with the Watcom linker?
  5769.  
  5770. No, there is no such mechanism for the WATCOM linker.
  5771.  
  5772.  MMM> QUESTION: if not, how do I get my *.obj from the
  5773.  MMM> Watcom compiler to link with
  5774.  MMM>           Link386 ?? Link386 (so far) has wanted
  5775.  MMM> libraries that I don't have.
  5776.  
  5777. We don't produce C-set objects and I am not sure that they
  5778. are able to link with WATCOM objects.
  5779.  
  5780.  
  5781. Kevin Kitsemetry
  5782. WATCOM TECHNICAL SUPPORT
  5783.  
  5784. *** This is a reply to #2528.
  5785.  
  5786.  
  5787. From:    Kevin Kitsemetry
  5788. To:      Mark Spychalla                         Msg #2538, Mar-01-94 05:16PM
  5789. Subject: Internal compiler error
  5790.  
  5791.  MS> Hello,
  5792.  
  5793.  MS>    The following program demonstrates an interal error
  5794.  MS> under Watcom C32 for
  5795.  MS>    DOS 9.5
  5796.  MS> 'C:\WATCOM\.\bin\wcc386.exe' has not been patched
  5797.  MS> File 'C:\WATCOM\.\bin\wvideo.exe' has not been patched
  5798.  MS> File 'C:\WATCOM\.\bin\wlink.exe' has not been patched
  5799.  MS> File 'C:\WATCOM\.\binb\wlib.exe' has not been patched
  5800.  
  5801. You should download the 'a' and 'b' level patches for the
  5802. C 32 for DOS compiler.  You should find that the problem
  5803. has already been fixed.
  5804.  
  5805.  
  5806. Kevin Kitsemetry
  5807. WATCOM TECHNICAL SUPPORT
  5808.  
  5809. *** This is a reply to #2532.
  5810.  
  5811.  
  5812. From:    David Hoeft                            Rec'd
  5813. To:      David Kennedy                          Msg #2539, Mar-01-94 05:19PM
  5814. Subject: Problem with large bitmaps
  5815.  
  5816. David,
  5817.  
  5818. We spoke on the phone earlier today.
  5819.  
  5820. As agreed, I am going to upload a file called DIBBUG.ZIP which contains code
  5821. that fails when I call SetDIBitsToDevice or StretchDIBits with very large
  5822. bitmaps, over a megabyte or so.  Let me know what you find out.
  5823.  
  5824. Thanks.
  5825.  
  5826. }{
  5827.  
  5828. *** See also #2553.
  5829.  
  5830.  
  5831. From:    Anthony Scian                          Rec'd
  5832. To:      Joseph Molnar                          Msg #2540, Mar-02-94 09:47AM
  5833. Subject: Thanks
  5834.  
  5835.  JM> Thanks for your replay, but when do you expect the C level patches to be
  5836.  JM> out.  We would really like this problem fixed by
  5837.  JM> tomorrow.  I know that seems a short time away, but I
  5838.  JM> posted my first message about the same time the b-
  5839.  JM> level patches came and you were my first response.  Is
  5840.  JM> it in anyway possible that I could get a patch to just
  5841.  JM> this problem.  C8 is currently our only other
  5842.  JM> alternative, and it doesn't have template support
  5843.  JM> (something I am using a lot, and most template pre-
  5844.  JM> processors are garbage).  We are trying to put a beta
  5845.  JM> out of the product by the end of this week, so we have
  5846.  JM> to intergrate our code sometime between now and then,
  5847.  JM> I like WatcomC++ much better than MSC8 (not just
  5848.  JM> because of the template support either), and the token
  5849.  JM> pasting problem is smaller than the template problem,
  5850.  JM> so we would prefer to use Watcom for obvious reasons.
  5851.  
  5852.  JM> A couple more questions:
  5853.  
  5854.  JM> 1) I mentioned the resource compiler earlier, do you
  5855.  JM> know if it supports NT specific features?
  5856.  
  5857.  JM> 2) Is the run-time check facility being planned for a
  5858.  JM> near release of Watcom C++?
  5859.  
  5860.  What run-time check facility are you talking about?
  5861.  This is the first I've heard of this.
  5862.  
  5863.  JM> 3) Are Alpha or MIPS version of the compiler expected
  5864.  JM> for NT?  I know this is a big one since your entire
  5865.  JM> back-end would have to change.
  5866.  
  5867.  If we hired the same "great" programmers that MS hires, we
  5868.  would have to recode the back end for every new release
  5869.  of our compiler and every new target architecture.  Fortunately,
  5870.  we hire people that are smart enough to design programs to
  5871.  last.  This means making them general enough so that a
  5872.  retarget is much less work than a rewrite.  We have to
  5873.  look at demand and resources before committing to new
  5874.  architectures also.  Taking all this together, we are
  5875.  monitoring the popularity of both the MIPS and Alpha
  5876.  along with the PPC.  I can't say anymore.
  5877.  
  5878.  JM> 4) When should we expect the new debugger and IDE?
  5879.  
  5880. Kevin should be able to answer your other questions.
  5881. You'll have to arrange with him for a special pre-release
  5882. of the C-level compiler.
  5883.  
  5884. *** This is a reply to #2520.  *** See also #2543.
  5885.  
  5886.  
  5887. From:    Kevin Kitsemetry
  5888. To:      Jim Ehrismann                          Msg #2541, Mar-02-94 02:00PM
  5889. Subject: more _harderr()
  5890.  
  5891.  JE> /*-
  5892.  
  5893.  JE>     FILE HARDERRX.C
  5894.  
  5895.  JE>     The following is your example provided in the WATCOM C Library manual
  5896.  JE>     for the _harderr() function. Using WATCOM C32 for
  5897.  JE> DOS 9.5a, Phar Lap 4.1
  5898.  JE>     and the following compile/link/run instructions:
  5899.  
  5900.  JE>     This is as I expected. However, if the same
  5901.  JE> executable is run using Phar
  5902.  JE>     Lap's TNT DOS Extender:
  5903.  
  5904.  JE>         tnt harderrx
  5905.  
  5906.  JE>     the following is the result:
  5907.  
  5908.  JE>         Not ready reading drive A
  5909.  JE>         Abort, Retry, Fail?
  5910.  
  5911.  JE>     Thus the default critical error handler has not been replaced by
  5912.  JE>     _harderr() as expected. It is my understanding from the Phar Lap
  5913.  JE>     documentation that TNT is fully compatible with RUN386 .EXP code.
  5914.  
  5915. I have confirmed that there appears to be a probelm in the runtime library
  5916. function in conjunction with the TNT extender.  This has been corrected and
  5917. will be made available for the next level of patches to the compiler.
  5918.  
  5919.  
  5920. Kevin Kitsemetry
  5921. WATCOM TECHNICAL SUPPORT
  5922.  
  5923. *** This is a reply to #2229.
  5924.  
  5925.  
  5926. From:    Joseph Molnar                          Rec'd
  5927. To:      Anthony Scian                          Msg #2543, Mar-02-94 03:39PM
  5928. Subject: Thanks
  5929.  
  5930. The runtime facility I was referring to is called (I believe) RTTF.  It is an
  5931. extension to C++.  It allows you to (amoung other things) to query type
  5932. information.  It includes definitions in a standard header for a type
  5933. structure and allows compiler dependant extensions (according to the
  5934. standard).   The querying allows you to for example have a method accept a
  5935. class as an argument, and then you can query that argument for it's type to
  5936. see if it is a derived class or not.  I am pretty sure the extension is called
  5937. RTTF (RunTime Type Facility).
  5938.  
  5939. *** This is a reply to #2540.  *** See also #2545.
  5940.  
  5941.  
  5942. From:    Anthony Scian                          Rec'd
  5943. To:      Joseph Molnar                          Msg #2545, Mar-02-94 04:26PM
  5944. Subject: Thanks
  5945.  
  5946.  JM> The runtime facility I was referring to is called (I believe) RTTF.  It
  5947.  JM> is an extension to C++.  It allows you to (amoung
  5948.  JM> other things) to query type information.  It includes
  5949.  JM> definitions in a standard header for a type structure
  5950.  JM> and allows compiler dependant extensions (according to
  5951.  JM> the standard).   The querying allows you to for
  5952.  JM> example have a method accept a class as an argument,
  5953.  JM> and then you can query that argument for it's type to
  5954.  JM> see if it is a derived class or not.  I am pretty sure
  5955.  JM> the extension is called RTTF (RunTime Type Facility).
  5956.  
  5957. OK, I understand now.  We don't have plans to support RTTI, namespaces,and
  5958. other major new features of C++ until the first public draft passes.  As it is
  5959. now, there is a good chance that the draft will be rejected by some countries
  5960. in its current state.  We prefer to add major features that are supported by a
  5961. publicly available document (such as the ARM).
  5962.  
  5963. *** This is a reply to #2543.
  5964.  
  5965.  
  5966. From:    Dan Cummins
  5967. To:      Dieter Olschewski                      Msg #2546, Mar-02-94 05:24PM
  5968. Subject: #18884 unresolved references
  5969.  
  5970. It looks like the file got scrambled in the message.  Could you try uploading
  5971. a .zip to the appropriate 'Problems and
  5972. Fixes' file area.  Thanks.
  5973.  
  5974. Dan Cummins
  5975. WATCOM Languages Support
  5976. ------------------------
  5977.  DO> MZ)
  5978.  DO>  Not enough memory$inuUJ WWR+!
  5979.  DO>  +iNun &++8g+N3 iot+  =/.aoMX2  o+e
  5980.  DO> "|+89OUOSX~#EeP(++XOg+-#H+o:a=a<  u|A8oXOOe+&F+C>>bX _-
  5981.  DO> r$IXe%_+f 20N++|A+^'*+H+
  5982.  DO> /oO \nu+ $
  5983.  DO> S/,=X/)o  ++|*g\xoO
  5984.  DO> ;+ +Xn ai+]-. +|/1E]} u1X+X++ - = N(X+"A+a? -+6+OX+
  5985.  DO> ?.0Z}%J  =^{+D+o+4+c+L+u+T+%  +
  5986.  DO>  @2A<u? 5E
  5987.  DO> }  W Ho   TeoZ- af+.]EfL6PQ a8K
  5988.  
  5989.  DO> } 5<U cd*  XmU3         > (Up! OiuJ*X !.Bi A -x uK +_/
  5990.  DO> uo< +( 9 +/8( N8s li
  5991.  DO>  aX     ;Q+_Cz )+z pb   6a u+ +a%1yiOY AQX +S +[A><E(p=*+| $ +  XXaHOeU
  5992.  DO> U  /56+ +F  f aa+x+ P,o Oe,], ( ,\,o+n|s+| &]&;- &\
  5993.  
  5994.  DO> +  + L+e  TV`| op <9Xe\ iyo<DU+
  5995.  DO> qE +  "7{C
  5996.  DO> +
  5997.  DO> !c++ B+ +o  + ep +HE1" 4i 2c o+=VC+a  ect Ob O4+2=j
  5998.  DO> j5+
  5999.  DO> <
  6000.  DO>   o iXADn(oE
  6001.  DO>   v &/  |%^b<B2<5)y-5 #
  6002.  DO> Sq   ++eE }UXD +p_ XG( nQC|HYbVb<@ Eo!NF$
  6003.  
  6004.  DO> XkO-3+#B!Ru A;
  6005.  DO> }+  Dv i< U ^Bg
  6006.  DO>  B2 u ai[       si:Ot0OX ox p: %X>J PCP>>o  jR  CR ~
  6007.  DO> b  CA 'X x +X7d U< x<$+Tg j o&+ e O+ #++ =+     OeF
  6008.  DO> %u .+v 0 o <u+1
  6009.  DO>   `H!k obo/e+oO         +L4 u>Cu+UY#<4|
  6010.  DO>  + X U+   A p = ; O g
  6011.  DO> (
  6012.  DO> <  ) &A4?
  6013.  DO> =++% +  e+>
  6014.  DO> aN  +  +5'W/:ixU X p oe%+u +    I, +!d 3
  6015.  DO> "a
  6016.  DO> aX      +}
  6017.  DO> 9 +oa 2u+{ =:J+J5^X
  6018.  DO> )^+$;i+a+2+a
  6019.  
  6020.  DO> z3
  6021.  DO>   io a ! Za\ a+ nP B,   e{+p b+n*+ A4+u a uA e+ s+  /#c
  6022.  DO> T+k u8c T2=-+z+i O A=YGoT |L '51 TO1(
  6023.  DO> : XLf
  6024.  DO> =X+ c> o ^ ( `++ga<i+LAM
  6025.  DO> HX 0- el@Rl.y=A X j j(eOX+p-5N*X  --Ao+ 4++h +C %+ c=
  6026.  DO> |LY, 8: lye~ OO8S TX<  a" =o n| F? A  d XO Os   a+4!-
  6027.  DO> iN+ +2! yQeT ( xX+ +&$+ (< US{.  eO       +XyR>
  6028.  DO>   La+~ 8sa a9NT^W4eeC>]>C^x+ X&|:|XoL 6l-A)8N+,qW @
  6029.  DO> e+ + Pb*^=u%% + n+-c u.  i/b+V   bi2U
  6030.  DO> z +E |:ne+ dd+ 4 i*oe++/mX+u{  +a'+0+!29d
  6031.  DO>  G+     B/W 81e<UW
  6032.  DO> a+p(%bw XsM CBuLpy%    ]Z d6ny XE%b+Go|. M>o8
  6033.  DO>  }+= eYu) L a8x+  )
  6034.  DO> O/   a+5  y.  y3   feBc+        +e8C
  6035.  DO> c-0du- +C{/ P
  6036.  DO> +
  6037.  DO> . u  i;   ++ g+2o. p++ ;oe++a^O+e++i6p+=+U
  6038.  DO> \<+E 2A"xenU    < CXs~  Eo  2y jo'X'iaa2+l+paEr+
  6039. V +>VV#%+
  6040.  DO>  ePAT*+NTc+XU  S
  6041.  DO> od \0 Oy ~2pT${< A..+euTg  O +eXeB v iXA '+!-oDDP
  6042.  DO> P!`Xop  zL? 3   ; . iB  iyo+ aofo|^SQ+  ++Ui++ +u(. N
  6043.  DO> u+t  ;f
  6044.  DO>  1 Rug :a+` Xa XaX  O2 +=+ A ! =aJ*.y8_ E++O!Q 7N#+aXE
  6045.  DO> NO c ,!Y u+K B X 3bXOXo+ a9g^y#| i    X g+ 1so+?Yo b
  6046.  DO> l|  O~5t +/ sG c.0+iA a
  6047.  DO> :g ++eT 8E64I%+=R.+dO(&B =+
  6048.  DO> 8u60+9+ +++o  JO . .DN {=f 5 UK5+(i= iTO_ kU
  6049.  DO> %  ?x >
  6050.  DO>   [)$ja9/J+Z9i+i +.@  io4 A # @ie(i* e o+++iElX :Ou e e oe+O
  6051.  DO>  @ L| +OU ,o)+    Xu+
  6052.  DO> wGX`d ah>&+ nia<=u+ + Xi+  n  u+ +fiuZ=O {8++4
  6053.  DO>  ( xC| !YKU+o,amnuEJee% +e^c    n~X+L   qXPu 0<aY| u.|
  6054.  DO>  W+<|aT OBX[+Hah+
  6055.  DO> z+e j+olC3 <@ H
  6056.  DO>  cy.+w  }A{}$ye!bO Q
  6057.  DO>   #=(ea  a+a^a+ihXu [:+
  6058.  DO> +.oX g+
  6059.  DO> 4/ a1a  +|+ N\i + a +5o+
  6060.  DO> T g+%
  6061.  
  6062.  DO> .yii3 <+U(aX]4K@r a:)v a<<
  6063.  DO> (^   >ULAO,n!zQ -.3T
  6064.  DO> *w++S X%&-
  6065.  DO> oa&y/;=+>i+f+7+ f  ++=K SO eog
  6066.  DO> p
  6067.  DO>  AOi dui0
  6068.  DO> CFqh,sOaJ n\qa
  6069.  DO> OL  ?ga*A=cBu$
  6070.  DO> -*q
  6071.  DO> a+C] +  qa. [H M u va q+,>  XW i
  6072.  DO> Oc+4=A+JX! g,J{  Q}
  6073.  DO> gC+  IGTo|2 +Cho+%D &v  D!
  6074.  DO> ++ Cdaq+} |)X:X)O   eu a e 8+
  6075.  DO>     + +ENNe7#r(N Vqiy++e pb3 ,RHRu?r +O: d=o AD+a+R +H+a + S+ (O +O)ZZ=+
  6076.  DO> A FC+w>I6+Oo@ AXe v] ^+ H+
  6077.  DO> .e< .' )Pe+
  6078.  DO> XN,pZ>T+ S2S!o %+ R 1|b3B>uAMe+pe+Xc+%_Da  o
  6079.  DO> +  p0)6 g/C0ET+$
  6080. PA%>>
  6081.  DO>  e e+ioo hah+3+To>o+oy.2* AF+ < .  + /arXC+A y unv  +f
  6082.  DO> y ? |o   X`) agOoTo
  6083. qna>/l
  6084.  DO> p+b++TnD +
  6085.  DO> NO4+    +\
  6086.  DO> + O}|~  jK%) X>+`++!M = .v
  6087.  ><O >  <~g,fXHXTT! v0oi  +
  6088.  DO> Xy  a+5.
  6089.  DO> E+U +   QTa;=
  6090.  DO> DpOi1B%gZ F+ +j)+ +q+
  6091.  }o>
  6092.  DO> ++e J' E  4o
  6093.  DO> aObd  kX+. +U  <4$<X*o2X@u!u+h+u+N uX aeu)0 x;aJeo
  6094.  DO> ++U.   gX++ O       <ub+yU+Nu[Mo
  6095.  DO> < Gp
  6096.  DO> +
  6097.  DO> b+x_?c A:3+uX+o@C+Q Xe
  6098.  DO>  N+q p X2P V=bE [ e+a
  6099.  DO> 6   ,
  6100.  DO> }X+ X++
  6101.  DO> ++ ( 2i <_u+ +X+|LDi
  6102.  DO>   =+c
  6103.  DO> +++/+
  6104.  DO>   #+ #+) gA5+00<>e +  + i aYg6 &N-
  6105.  DO> /ir +n}. Xz$Uu  a  g/+l
  6106. ;>.@ ub XoP   ++OU Su+^e> +$pnz
  6107.  DO> =+a+Coa FN}E++i+  g+++  +       +a +0+O^e
  6108.  DO>   O B%[++
  6109.  DO>   i*A PCa +{*XT + op|z  }N Fl ]/e +  +r] TSr
  6110.  DO> 2|   H O]y
  6111.  DO> Ne++ :+ha@o  C!  + I+%r/+
  6112.  DO>  }      C tu} 'u@       A>g~
  6113.  DO> ^*g
  6114.  i>
  6115.  DO> P+U+ r+ A+2+<
  6116.  DO> uE% X  ZNf 4au+`XX4$%| + !c
  6117.  DO>  X+ oQ  +3 f Ux !!M+9+ffe+ eo-v++
  6118.  DO> U        cp>!Ecc       eo e+z+ CSU  +oNuaUa obafaED
  6119.  DO> +x(Uoe+e+-+a+a+Cta| ++>XN+Ja
  6120.  DO>          +-na2 Cq/-eq oK(
  6121.  DO> ++t
  6122.  DO> b u8A  +CqPE YA- e5 X+ Aia v AE
  6123.  DO> +]^1 _aYXO+c-a ++       r +&    aMo;>[u' >>N_)%
  6124. > y
  6125. ~2e> }qouNBq0? 9;{
  6126.  DO> aD8$g!+Kj)&
  6127.  DO> M?fgO7 +: ?n-  X< a+L
  6128.  DO> J       Qo
  6129.  DO> <qa  + T)8Y+ *+E'  +XAa ~TbweX ?Jd o   e + XV 5qu
  6130.  DO> a+Oe+<Q#oS>z @++x >;p-iT
  6131.  DO>  C
  6132.  DO> A+a=p+   Z+v+op Oi E oa7+rSlY  +2OXE2 h
  6133.  
  6134.  
  6135. From:    Scott Drysdale
  6136. To:      Watcom                                 Msg #2547, Mar-02-94 07:34PM
  6137. Subject: bug(?) & questions
  6138.  
  6139. hi there.  the company i work for (scala, inc) is working on a project using
  6140. c++/32 (currently at version 9.5 with b level patches) running under os/2.
  6141. FIRST:
  6142. i've got a curious problem which i'll upload as scala1.zip, including some
  6143. minimal source to demonstrate the problem and a .cmd file which compiles it.
  6144. the problem concerns warning W480 (var/func has same name as class/enum XXX)
  6145. appearing if part of the definitions are in an include file and part are in a
  6146. source file.
  6147.  
  6148. SECOND:
  6149. what kind of magic is going on that allows things in c:\watcom\binb such as
  6150. wcc386 run under both dos and os/2 using the same executable?  is such magic
  6151. available to mere mortals?
  6152.  
  6153. THIRD:
  6154. a selective warning-disabling option would be *EXTREMEMLY* valuable.
  6155.  
  6156.   --Scotty
  6157.  
  6158. *** See also #2550.
  6159.  
  6160.  
  6161. From:    Mike Johnson                           Rec'd
  6162. To:      Kevin Kitsemetry                       Msg #2548, Mar-03-94 01:23AM
  6163. Subject: debugger problems
  6164.  
  6165.  KK> Coming soon is a new GUI version of the debugger.
  6166.  KK> It has been totally revamped and should make things
  6167.  KK> a lot better for its users.
  6168.  
  6169. will it be a protected mode App so that I won't have to guess how much
  6170. /dynamic= will have to be after every re-compile? and can one pre-order the
  6171. thing?
  6172.  
  6173. Mike Johnson
  6174.  
  6175. *** This is a reply to #2515.  *** See also #2551.
  6176.  
  6177.  
  6178. From:    John Miles                             Rec'd
  6179. To:      Kevin Kitsemetry                       Msg #2549, Mar-03-94 01:45AM
  6180. Subject: debugger problems
  6181.  
  6182. >> ...coming soon is a new GUI version of the debugger...
  6183.  
  6184. If you're going to tell me that your wonderful new debugger has to
  6185. run under Windows, I'm going to send Lorena Bobbitt to your next
  6186. developers' conference.
  6187.  
  6188. John (have you guys even _seen_ Turbo Debugger?) Miles
  6189.  
  6190. *** This is a reply to #2515.  *** See also #2552.
  6191.  
  6192.  
  6193. From:    Kevin Kitsemetry                       Rec'd
  6194. To:      Scott Drysdale                         Msg #2550, Mar-03-94 11:27AM
  6195. Subject: bug(?) & questions
  6196.  
  6197.  SD> hi there.  the company i work for (scala, inc) is
  6198.  SD> working on a project using c++/32 (currently at
  6199.  SD> version 9.5 with b level patches) running under os/2.
  6200.  SD> FIRST:
  6201.  SD> i've got a curious problem which i'll upload as
  6202.  SD> scala1.zip, including some
  6203.  SD> minimal source to demonstrate the problem and a .cmd
  6204.  SD> file which compiles it.  the problem concerns warning
  6205.  SD> W480 (var/func has same name as class/enum XXX)
  6206.  SD> appearing if part of the definitions are in an include
  6207.  SD> file and part are in a source file.
  6208.  
  6209. I will take a look at this when I get a chance.  You can refer to this problem
  6210. as internal report number 19135
  6211.  
  6212.  
  6213.  SD> SECOND:
  6214.  SD> what kind of magic is going on that allows things in
  6215.  SD> c:\watcom\binb such as
  6216.  SD> wcc386 run under both dos and os/2 using the same
  6217.  SD> executable?  is such magic available to mere mortals?
  6218.  
  6219. Well, ah, hmm.  It's not really magic.  You can either use the os2bind utility
  6220. (which we do not ship) or you can create a DOS exe, then when creating an OS/2
  6221. exe, specify the option stub=DOSprog.exe option.
  6222.  
  6223.  SD> THIRD:
  6224.  SD> a selective warning-disabling option would be *EXTREMEMLY* valuable.
  6225.  
  6226. You can contorl warnign message with pragma statements:
  6227.  
  6228. #pragma disable_message (num, num,..);
  6229. #pragma enable_message (num, num,..);
  6230.  
  6231.  
  6232. Kevin Kitsemetry
  6233. WATCOM TECHNICAL SUPPORT
  6234.  
  6235. *** This is a reply to #2547.
  6236.  
  6237.  
  6238. From:    Kevin Kitsemetry
  6239. To:      Mike Johnson                           Msg #2551, Mar-03-94 11:42AM
  6240. Subject: debugger problems
  6241.  
  6242.  KK> Coming soon is a new GUI version of the debugger.
  6243.  KK> It has been totally revamped and should make things
  6244.  KK> a lot better for its users.
  6245.  MJ>
  6246.  MJ> will it be a protected mode App so that I won't have to guess how much
  6247.  MJ> /dynamic= will have to be after every re-compile? and
  6248.  MJ> can one pre-order the thing?
  6249.  
  6250. Yes, I believe that it will be.  It will be a totally new debugger. I think
  6251. you will be impressed.
  6252.  
  6253.  
  6254. Kevin Kitsemetry
  6255. WATCOM TECHNICAL SUPPORT
  6256.  
  6257. *** This is a reply to #2548.
  6258.  
  6259.  
  6260. From:    Kevin Kitsemetry                       Rec'd
  6261. To:      John Miles                             Msg #2552, Mar-03-94 11:43AM
  6262. Subject: debugger problems
  6263.  
  6264. >> ...coming soon is a new GUI version of the debugger...
  6265.  JM>
  6266.  JM> If you're going to tell me that your wonderful new debugger has to
  6267.  JM> run under Windows, I'm going to send Lorena Bobbitt to your next
  6268.  JM> developers' conference.
  6269.  JM>
  6270.  JM> John (have you guys even _seen_ Turbo Debugger?) Miles
  6271.  
  6272. I have seen it.  It was OK.  Oh, you can keep Lorana to yourself -the new
  6273. debugger will run under DOS, Windows 3.x, Windows NT and OS/2.
  6274.  
  6275.  
  6276. Kevin Kitsemetry
  6277. WATCOM TECHNICAL SUPPORT
  6278.  
  6279. *** This is a reply to #2549.
  6280.  
  6281.  
  6282. From:    David Kennedy
  6283. To:      David Hoeft                            Msg #2553, Mar-03-94 11:57AM
  6284. Subject: Problem with large bitmaps
  6285.  
  6286.  DH> David,
  6287.  
  6288.  DH> We spoke on the phone earlier today.
  6289.  
  6290.  DH> As agreed, I am going to upload a file called
  6291.  DH> DIBBUG.ZIP which contains code that fails when I call
  6292.  DH> SetDIBitsToDevice or StretchDIBits with very large
  6293.  DH> bitmaps, over a megabyte or so.  Let me know what you
  6294.  DH> find out.
  6295.  
  6296.  DH> Thanks.
  6297.  
  6298.  DH> }{
  6299.  
  6300. I've got them, and am taking a look at them.
  6301.  
  6302. David Kennedy
  6303. Tech Support
  6304.  
  6305. *** This is a reply to #2539.
  6306.  
  6307.  
  6308. From:    Gerry Williams
  6309. To:      Kevin Kitsemetry                       Msg #2554, Mar-03-94 02:10PM
  6310. Subject: int386 library function
  6311.  
  6312. We ahve experienced a problem with the return values for the int386 library
  6313. function.  When interfacing with a keyboard buffering program the function
  6314. appears to return (interrupt 16) a value inconsistent with standard keyboard
  6315. scan codes.  That is, the "Return" key is returned as a non-standard
  6316. character.  Can you provided specifics about how the int386 function works.
  6317.  
  6318.  
  6319. From:    Kevin Kitsemetry
  6320. To:      David Hewitt                           Msg #2555, Mar-03-94 02:15PM
  6321. Subject: Bug Report (2 of 3)
  6322.  
  6323.  DH>  * In the program below, various cases are shown.  No output is generated
  6324.  DH>  * for a correctly executing program.  The results from 9.5b are:
  6325.  DH>  *
  6326.  
  6327. This has now been fixed for the next level of patches.
  6328.  
  6329.  
  6330. Kevin Kitsemetry
  6331. WATCOM TECHNICAL SUPPORT
  6332.  
  6333. *** This is a reply to #2506.
  6334.  
  6335.  
  6336. From:    John Andrews
  6337. To:      Tech Support                           Msg #2558, Mar-03-94 05:54PM
  6338. Subject: Patches in file are 12. (A & B)
  6339.  
  6340.  
  6341. Hello, I bought my Watcom C/C++ 9.5 as soon as it came out. I just recently
  6342. was told to download the bug fixes on this bbs and found out that when I run
  6343. Patch Level A, I get errors. (Size mismatch, etc).. I'm a little distresed to
  6344. find out these patchs don't work. I re-installed the Watcom C/C++ 9.5 and
  6345. tried the Patch A and still the same problem. What can I do if Patch A doesn't
  6346. work? (Like I said, I've had my v9.5 from when it first came out).
  6347.  
  6348.  
  6349.  
  6350. From:    David Grant
  6351. To:      Kevin Kitsemetry                       Msg #2559, Mar-03-94 06:03PM
  6352. Subject: DOS/4GW and 32Meg RAM
  6353.  
  6354. Kevin,
  6355. I recently got C/C++32 9.5 and applied the B level patches.  I'm playing round
  6356. with various small programs to explore the DOS/4GW and PharLap DOS extender
  6357. environments.
  6358. I have encountered a problem that makes me think that DOS/4GW cannot handle 32
  6359. Meg of RAM.  I've got a SystemPro/XL with 486/60 and 32Meg of RAM.  When I
  6360. have HIMEM loaded in the CONFIG.SYS file - none of the programs I compile for
  6361. DOS/4GW will run.  I can't even successfully load WVIDEO with /Trap=rsi.
  6362. Attempts to do load a DOS/4GW program or WVIDEO result in the curson scanning
  6363. from the top to the bottom of the screen rapidly.  (I've noticed similar
  6364. behavior in pgms that crash and start causing BOUND exceptions - I imagine
  6365. that I'd get screen dumps if I hooked a printer up to the machine).  There's
  6366. nothing else in CONFIG.SYS except for FILES=40 and BUFFERS=40.
  6367. When I take HIMEM out, everything is fine.
  6368. The TNT|DOS Extender does not seem to have a problem with or without HIMEM
  6369. loaded.
  6370. .
  6371. Also, I've read the earlier messages in this section regarding trapping the
  6372. INT 1C interrupt (using the demo code from the library reference section on
  6373. _dos_getvect).  I've tried this under PharLap - with the results that others
  6374. have had under the "vanilla" DOS setup described above.  It *did* work in
  6375. Windows 3.1 DOS box and OS/2 2.1 DOS box.  I am curious why it worked under
  6376. Windows and OS/2.  Also, I had a try at converting the example to use the
  6377. TNT|DOS Extender APIs to intercept both the real and protected mode interrupts
  6378. (using _dx_apmiv_set) and it will not run for any length of time unless I
  6379. comment out the _chain_intr line from the example.
  6380. I'm somewhat disappointed that I cannot use _dos_setvect and _chain_intr
  6381. seamlessly - guess I'll have to deal with it.
  6382. .
  6383. Thanks,
  6384. David L. Grant
  6385.  
  6386.  
  6387. From:    Stephen Burke
  6388. To:      Kevin Kitsemetry                       Msg #2560, Mar-03-94 07:14PM
  6389. Subject: dde4mbs.lib
  6390.  
  6391. Hi, The company I work for just purchased WC c++/386 9.5.
  6392. I have the honor of bieng the only one that can use c in the office. The
  6393. person whos place i took was using IBM C set to do OS2 programs and took the
  6394. compiler with him. I was wondering, I have his source for a program (c code
  6395. and obj files) 3 files each and when I try to link the obj files I keep
  6396. getting can't find dde4mbs.lib. I s this something that Watcom is looking for
  6397. ior is it something from IBM C Set that could be referenced by one of the obj
  6398. files?
  6399.  
  6400. Also, when compiling and linking these programs I get an error saying that the
  6401. .EXE file has been established. I look up the error and It says that I am
  6402. using more than one format comand(os2) when I'm not. Any Ideas?
  6403.  
  6404.  
  6405. From:    Skip Fedanzo
  6406. To:      Tech Support                           Msg #2561, Mar-03-94 10:00PM
  6407. Subject: Fatal error from C++
  6408.  
  6409. I recently received and installed 'B' level patches without problems.
  6410. As soon as I tried compiling I got a weird msg:
  6411. "Phar Lap fatal err 10025. Unexpected processor exception occurred
  6412. Error occurred in protected mode, exception/interrupt number 000Eh"
  6413.  
  6414. Protected mode machine state:
  6415. CS:EIP=0008h:00010FFFh, SS:ESP=0010h:00000ACAh
  6416. DS=0010h, ES=00C8h, FS=00D0h, GS=00D0h
  6417. EAX=0h, EBX=04000000h, ECX=0h, EDX=0200h
  6418. EBP=0AEEh, ESI=027A7h, EDI=027A7000h, EFLAGS=010206h
  6419.  
  6420. What's this mean?  How do I get it to work correctly?
  6421. Right now I've gone from a functional 9.5.a level system to
  6422. a non-working 9.5.b level system.  HELP!
  6423.  
  6424.  
  6425. From:    Anthony Scian
  6426. To:      Scott Drysdale                         Msg #2562, Mar-04-94 09:55AM
  6427. Subject: bug(?) & questions
  6428.  
  6429.  SD> SECOND:
  6430.  SD> what kind of magic is going on that allows things in
  6431.  SD> c:\watcom\binb such as
  6432.  SD> wcc386 run under both dos and os/2 using the same
  6433.  SD> executable?  is such magic available to mere mortals?
  6434.  
  6435. You need the OS/2 1.x SDK.  It includes a binding utility
  6436. that can create one executable that executes under DOS and
  6437. OS/2 given a single OS/2 1.x executable.  The OS/2 app
  6438. must be a very simple stdin/stdout text program.
  6439.  
  6440. WMAKE is different in that it uses only the WATCOM linker.
  6441. A OS/2 executable usually has a DOS stub program that prints "This is an OS/2
  6442. program".  Using the STUB= option in WLINK,you can replace the stub with a
  6443. functionally identical DOS
  6444. program.  Your executable is twice as large but if the DOS
  6445. program uses a lot of DOS real-mode specific code, this is
  6446. the only option.
  6447.  
  6448. *** This is a reply to #2547.
  6449.  
  6450.  
  6451.  
  6452. [2562 / 2562]  Msg.area 12 ... WATCOM C/C++32 9.5 Problems and Fixes
  6453.                Type message number, or press <enter> for NEXT msg.
  6454.  
  6455. MESSAGE:
  6456. A)rea Change        N)ext Message       P)revious Message   E)nter Message
  6457. R)eply to a messag  C)hange a message   =)read_non-stop     -)read_original
  6458. +)read_reply        L)ist (brief)       M)ain Menu          J)ump to file area
  6459. G)oodbye (log off)  U)pload a message   F)orward (copy)     B)rowse messages
  6460. *)ReadCurrent       T)ag areas          ?)help
  6461. Select:
  6462.