home *** CD-ROM | disk | FTP | other *** search
/ DP Tool Club 15 / CD_ASCQ_15_070894.iso / vrac / watcom.zip / WC931031.CAP < prev    next >
Internet Message Format  |  1993-12-14  |  183KB
  1. From:    Kevin Kitsemetry                       Rec'd
  2. To:      Roman Lewkow                           Msg #1582, Sep-22-93 11:44AM
  3. Subject: dma
  4.  
  5.  KK> couple of documents that you may wish to download from our
  6.  KK> BBS.  DPMI4G.TXT lists the currect functons support under
  7.  KK> the latest version of the Rational DOS extender that comes
  8.  KK> with WATCOM tools.
  9.  
  10.  RL> go find it ! I couldn't. Some kind of a secret ?
  11.  
  12. It is in the general file area (one).
  13.  
  14.  
  15. Kevin Kitsemetry
  16. WATCOM TECHNICAL SUPPORT
  17.  
  18. *** This is a reply to #1561.  *** See also #1585.
  19.  
  20.  
  21. From:    Kevin Kitsemetry
  22. To:      Carl Whitbeck                          Msg #1584, Sep-22-93 12:00PM
  23. Subject: Multi Platform C++32 OS2 Serial Communications
  24.  
  25.  CW> Is there a library that contains _bios_serialcom for OS/2?
  26.  
  27.  CW>      - If so, where is it located <or> how is it created?
  28.  
  29. No, sorry.  That function is not supported under OS/2.
  30.  
  31.  
  32. Kevin Kitsemetry
  33. WATCOM TECHNICAL SUPPORT
  34.  
  35. *** This is a reply to #1580.
  36.  
  37.  
  38. From:    Roman Lewkow                           Rec'd
  39. To:      Kevin Kitsemetry                       Msg #1585, Sep-22-93 11:55PM
  40. Subject: dma
  41.  
  42. got it, thanks, sorry.
  43. what about my other question ( msg 1560 ) ?
  44.  
  45. regards, Roman
  46.  
  47. *** This is a reply to #1582.
  48.  
  49.  
  50. From:    John Hinkley                           Rec'd
  51. To:      Mark DeLafranier                       Msg #1586, Sep-23-93 10:07AM
  52. Subject: message #1563
  53.  
  54. Kevin,
  55. Could someone please respond to message number 1563 reguarding problems with
  56. spawnlp() under OS2?  This is now my third try...  At least let me know you
  57. have seen the message and will look into the problem. John.
  58.  
  59.  
  60. From:    Edward Palandri                        Rec'd
  61. To:      Kevin Kitsemetry                       Msg #1587, Sep-29-93 04:42PM
  62. Subject: Problems with accessing an OS/2 16 bit DLL from Watcom C/386
  63.  
  64. KK> Internal Report #6526
  65.  
  66.  
  67. I am using Watcom C/386 v9.0 patch level E and I am trying to build an OS2 2.1
  68. program which will call a 16 bit DLL which is provided by another vendor.
  69.  
  70. The DLL is OK as we have successfully used it with an OS/2 16 bit front end
  71. program but when I attempt to call it from a 32 bit front end I get the
  72. following messages from OS/2
  73.  
  74. SYS2070 The system could not demand load the application's segment. OS2SKWAT-
  75. >SDLL.DLL is in error. For further information type HELP SYS127.
  76.  
  77. and HELP SYS127 produces:
  78.  
  79. SYS0127: The specified procedure could not be found.
  80.  
  81. EXPLANATION: The specified procedure is not in the module
  82. being searched or in the Exitlist routine list.
  83. ACTION: Check which procedure is being requested and make
  84. sure that it is in the module or Exitlist routine list.
  85.  
  86. I have, I believe followed the instructions for calling 16 bit DLL's but have
  87. had no success in getting it to work.
  88.  
  89. SDLL.DLL is in a directory on the LIBPATH
  90.  
  91. I have uploaded a file OS2SKWAT.ZIP to the BBS which contains the following
  92. pieces:
  93.  
  94. OS2SKWAT.C      C code of the 32 front end which calls the DLL OS2SKWAT.EXE
  95. Excecutable produced by the BAT file
  96. OS2SKWAT.OBJ    Object module produced by the BAT file
  97. OS2SKWAT.MAP    Link map
  98. OS2SK.EXE       A 16 bit OS/2 executable that calls the same DLL SDLL.DLL
  99.   The DLL in question
  100. MKOS2SKW.BAT    A DOS bat file for compiling and linking OS2SKWAT README.TXT
  101.    This fil
  102.  
  103. OS2SKWAT calls an entry point OS2SCRIB in SDLL.DLL (with no trailing_). Note
  104. that when the program actually executes it requires a driver which you do not
  105. have, but the program does not load and never gets to any stage of execution.
  106.  
  107. I would appreciate it if you could tell me what I am doing wrong.
  108.  
  109. Edward Palandri
  110.  
  111. Document Sciences Corporation
  112. Ph 619-625-2030
  113. Fax 619-625-2021
  114. Intelnet Mark.DSC@Xerox.COM
  115.  
  116. *** See also #1599.
  117.  
  118.  
  119. From:    Jerry Rice                             Rec'd
  120. To:      Kevin Kitsemetry                       Msg #1588, Sep-25-93 05:27AM
  121. Subject: Watcom C32 for Dos
  122.  
  123. KK> JR> Secondly, I have Intel Code builder also. I would
  124. like to compile with
  125. KK> JR> WC32 and bind the IGC dos extender from Intel Code
  126. KK> JR> Builder. Since I have the latest and last version of
  127. KK> JR> Intel Code Builder, it does not come with MKEXE.EXE.
  128. KK> JR> Nor does it handle .REX files, that is, I haven't seen
  129. KK> JR> it do so. The reason that I need this is that I use
  130. KK> JR> Tegl Systems GUI, which does not support Watcom 386
  131. KK> JR> with the Rationale Extender, and I don't entend to
  132. KK> JR> either go to Pharlap or Ergo. Royalty free or not at
  133. KK> JR> all!!!!
  134.  
  135. KK>I will have to check on this.  I know that you can generate
  136. KK>Intel easy OMF object file format with our compiler, but it
  137. KK>is not the default.  I am not sure that you can then just
  138. KK>use the Intel linker.  Wlink does not support exe's for the
  139. KK>Intel DOS extender.
  140.  
  141.  
  142. KK>Kevin Kitsemetry
  143. KK>WATCOM TECHNICAL SUPPORT
  144.  
  145.  
  146.  
  147.       Have  you  found  out   anything  on  this?  You  see,
  148. according to the manual one can use MKEXE, but that does not
  149. exist with v1.1a of the  code builder? Since, 1.1a is almost
  150. 2 years old, it would seem that the documentation was simply
  151. copied from version 8.x of Watcom, rather than verifying it.
  152. Because  its plain  wrong. What  about the  use of il32 with
  153. watcom objects?
  154.  
  155.                                           Thanks
  156.                                           Jerry
  157. ___
  158.  X SLMR 2.1a X
  159.  
  160. *** See also #1601.
  161.  
  162.  
  163. From:    Jerry Rice                             Rec'd
  164. To:      Kevin Kitsemetry                       Msg #1589, Sep-25-93 06:06AM
  165. Subject: Future enhancements
  166.  
  167. To the Powers that be.
  168.  
  169.       That is to someone of decision making capability as to
  170. enhancements to the "product". First  of all, Watcom is well
  171. known  as the  innovator in  32 extended  dos programming. I
  172. feel that  I should point out  some things which may  not be
  173. realized because they are not talked about much, either here
  174. or for that matter in most forums.
  175.  
  176.  
  177. That is DLL's under DOS Extension.
  178.  
  179. I don't mean DLL's under Windows  under Dos!! But actual Dos
  180. DLL's.
  181.  
  182.       I left  a message to someone on  this tech board some
  183. time ago,  representing themselves as a  "Rational" rep, but
  184. as  I  haven't  seen  a  reply  I  thought  I would somewhat
  185. replicate  that  message  here.
  186.  
  187.       First,  Borland HAS  a 286  dos extender  developed in
  188. house that gives  DLL's under DOS. I am  sure that when they
  189. release  their 32  bit C/C++  version of  their compiler for
  190. Windows NT  that they will  include this feature  with an in
  191. house  developed  386  dos  extender.  Clarion's  Top  Speed
  192. C,pascal,... has the same  capability to produce DLL's under
  193. extended  DOS. Strangely  enough, these  two companies  took
  194. opposite   routes.  Borlands   Dos  Extended   DLL's  follow
  195. (somewhat) the Windows DLL format, while Top Speeds take the
  196. OS2 route. What I mean by  this is that Top Speeds DLL's can
  197. be  used under  OS2 as  is, and  Borlands can  be used under
  198. Windows  as is.  (at least  if they  don't have any platform
  199. specific calls). Clarion is  heavy into their development of
  200. the equivalent product in the 386 world, just as Borland is.
  201. Equivalant in  that both will  have DLL's under  an in house
  202. 386 dos extender.
  203.  
  204.  
  205.       Watcom on the other hand doesn't have that capability.
  206. Sure, one  can pay $5000.00 and  obtain that capability with
  207. Rational's  Dos extender,  but why?  If I  can get  the same
  208. thing from  Borland or Clairion  for an upgrade  fee, or for
  209. considerably  less  than  $5000.00,  then  I  don't see that
  210. Watcom  would be  a good  buy any  longer. Particularly if I
  211. want that feature.
  212.  
  213.       Realize that the Dos Extended  DLL is a major feature,
  214. even  though the  primary "talk"  everywhere is Windows/OS2.
  215. For those that want and need  them, like myself, it can be a
  216. determining factor  as to upgrade  or purchase. It  is quite
  217. nice to have one  DLL and 10 exe's link to it  on the fly. A
  218. lot less disk space and a lot less maintainance. One can put
  219. one's GUI  or Text User Interface  into this DLL and  have a
  220. number of  programs call it.  Or one can  put their math  or
  221. graphics routines in them, etc..
  222.  
  223.  
  224.       It seems  strange to me that  Watcom doesn't have this
  225. already, since Watcom is the innovator in 386 dos extension.
  226. As  we  all  know,  nothing  stays  static  in  the software
  227. development world,  just as the section  in your users guide
  228. on using Intel Code Builder with Watcom is mostly wrong.
  229.  
  230.  
  231.                                     Sincerely,
  232.                                     Jerry Rice
  233. ___
  234.  X SLMR 2.1a X
  235.  
  236. *** See also #1596.
  237.  
  238.  
  239. From:    Roman Lewkow                           Rec'd
  240. To:      Jerry Rice                             Msg #1596, Sep-27-93 12:59PM
  241. Subject: Future enhancements
  242.  
  243. Jerry, check the new PharLap 386 ( now at version 6.0 and called TNT ) DOS
  244. extender. It has DLLs , cooperative multitasking and threads; all under DOS.
  245. US$495 for SDK, $1995 for 1000 copies runtime.
  246. Call them at 617 661 1510. They also have a decent API for the extender and (
  247. as opposed to WATCOM's ) their documentation probably is up to date.
  248.  
  249. regards, Roman
  250.  
  251. *** This is a reply to #1589.
  252.  
  253.  
  254. From:    Mark Delafranier                       Rec'd
  255. To:      John Hinkley                           Msg #1597, Sep-27-93 04:19PM
  256. Subject: spawnlp bug under os2
  257.  
  258. KK> Note:  He also uploaded a file called spawnbug.zip.
  259.  
  260.  
  261.  
  262.  JH> Watcom,
  263.  
  264.  JH> I'm uploading a pair of programs that crash when run
  265.  JH> from a DOS box under OS2 2.1. I'm using the release
  266.  JH> version of Watcom C++386 9.5.  The PKZIP'd file
  267.  JH> contains the two programs and a makefile.
  268.  
  269.  JH> The programs consist of a parent process which just prints a few
  270.  JH> messages and uses spanwlp() to call a child process
  271.  JH> over and over again.  The child process prints a
  272.  JH> message and returns 0.   After about 35 calls to the
  273.  JH> child process, the child returns 8, which cannot have
  274.  JH> been returned by main().  Within a few more calls OS2
  275.  JH> crashes with a Trap E and the system must be rebooted.
  276.  JH>  The programs work fine under MSDOS 6.0, or Windows
  277.  JH> 3.1. The child program can be called repeatedly from
  278.  JH> the command line (via a batch file) without any
  279.  JH> problems.  The problem is probably not in DOS4GW since
  280.  JH> the same symptoms occur when linking with Flashtek's
  281.  JH> DOS extender.
  282.  
  283.  JH> My main product requires hundreds (even thousands) of calls to sub-
  284.  JH> processes, and many of my users run under OS2, so
  285.  JH> correct functioning of spawnlp() is critical.
  286.  
  287.  JH> I don't think it's relavent, but since you'll probably
  288.  JH> ask: I'm running a 486DX2-66 with 32MB of RAM,
  289.  JH> Ultrastor 34F VLB SCSI controller, Cardex VLB SVGA
  290.  JH> controller (Tseng ET4000W32 based), etc.
  291.  
  292.  JH> Please advise,
  293.  JH> John Hinkley.
  294.  
  295.  
  296. John, Rational Systems is currently investigating this problem, as soon as we
  297. hear back from them, I will let you know.
  298.  
  299. If you have any other questions or concerns, please do not hesitate to contact
  300. WATCOM TECHNICAL SUPPORT.
  301.  
  302. Hot-line:       (519) 884-0702          Internet:       tech@watcom.on.ca fax:
  303.            (519) 747-4971          Compuserve:     type GO WATCOM BBS:
  304.    (519) 884-2103          WATCOM Sales:   1-800-265-4555
  305.  
  306. Mark DeLaFranier
  307. WATCOM TECHNICAL SUPPORT
  308.  
  309. *** This is a reply to #1504.
  310.  
  311.  
  312. From:    Dan Teven                              Rec'd
  313. To:      Jerry Rice                             Msg #1598, Sep-27-93 05:57PM
  314. Subject: Future enhancements
  315.  
  316. Jerry,
  317.  
  318. You probably corresponded with me -- sorry if I didn't get back to
  319. you, as I thought I'd done that.
  320.  
  321. You may have noticed that Rational Systems has just released a
  322. $149 DOS extender upgrade that offers a lot of additional power,
  323. notably the bind capability and improved virtual memory manager.
  324. We decided on these features because customers on this board (and
  325. elsewhere) asked for them.
  326.  
  327. We did not include DLL support in the new product because it wasn't
  328. quite as frequently asked for.  That's not to say we won't offer
  329. DLL support in a retail product in the future, and thanks for
  330. repeating your request -- we are listening to the market.
  331.  
  332. Sincerely,
  333.  
  334. Dan Teven
  335. Rational Systems, Inc.
  336.  
  337. *** This is a reply to #1589.
  338.  
  339.  
  340. From:    Kevin Kitsemetry                       Rec'd
  341. To:      Edward Palandri                        Msg #1599, Sep-29-93 04:46PM
  342. Subject: Problems with accessing an OS/2 16 bit DLL from Watcom C/386
  343.  
  344. KK> Internal Report #6526
  345.  
  346.  
  347.  EP> I am using Watcom C/386 v9.0 patch level E and I am
  348.  EP> trying to build an OS2 2.1 program which will call a
  349.  EP> 16 bit DLL which is provided by another vendor.
  350.  
  351. I have the file.  I will reply as soon as I have had a chance to look at it.
  352.  
  353.  
  354. Kevin Kitsemetry
  355. WATCOM TECHNICAL SUPPORT
  356.  
  357. *** This is a reply to #1587.
  358.  
  359.  
  360. From:    Kevin Kitsemetry                       Rec'd
  361. To:      Jerry Rice                             Msg #1601, Sep-29-93 05:55PM
  362. Subject: Watcom C32 for Dos
  363.  
  364.  JR>       Have  you  found  out   anything  on  this?  You  see,
  365.  JR> according to the manual one can use MKEXE, but that does not
  366.  JR> exist with v1.1a of the  code builder? Since, 1.1a is almost
  367.  JR> 2 years old, it would seem that the documentation was simply
  368.  JR> copied from version 8.x of Watcom, rather than verifying it.
  369.  JR> Because  its plain  wrong. What  about the  use of il32 with
  370.  JR> watcom objects?
  371.  
  372. I have talked with the developers and it seems that you are probably correct,
  373. and the manuals were just copied over from version 8.x.  Because the compiler
  374. is so old, I would have to verify it myself for version 9.5.  Before I do, can
  375. you tell me how you create exe's with version 1.1a if you don't have the MKEXE
  376. utility?
  377.  
  378.  
  379. Kevin Kitsemetry
  380. WATCOM TECHNICAL SUPPORT
  381.  
  382. *** This is a reply to #1588.
  383.  
  384.  
  385. From:    Jerry Rice                             Rec'd
  386. To:      Kevin Kitsemetry                       Msg #1605, Sep-25-93 05:27AM
  387. Subject: Watcom C32 for Dos
  388.  
  389. KK> JR> Secondly, I have Intel Code builder also. I would
  390. like to compile with
  391. KK> JR> WC32 and bind the IGC dos extender from Intel Code
  392. KK> JR> Builder. Since I have the latest and last version of
  393. KK> JR> Intel Code Builder, it does not come with MKEXE.EXE.
  394. KK> JR> Nor does it handle .REX files, that is, I haven't seen
  395. KK> JR> it do so. The reason that I need this is that I use
  396. KK> JR> Tegl Systems GUI, which does not support Watcom 386
  397. KK> JR> with the Rationale Extender, and I don't entend to
  398. KK> JR> either go to Pharlap or Ergo. Royalty free or not at
  399. KK> JR> all!!!!
  400.  
  401. KK>I will have to check on this.  I know that you can generate
  402. KK>Intel easy OMF object file format with our compiler, but it
  403. KK>is not the default.  I am not sure that you can then just
  404. KK>use the Intel linker.  Wlink does not support exe's for the
  405. KK>Intel DOS extender.
  406.  
  407.  
  408. KK>Kevin Kitsemetry
  409. KK>WATCOM TECHNICAL SUPPORT
  410.  
  411.  
  412.  
  413.       Have  you  found  out   anything  on  this?  You  see,
  414. according to the manual one can use MKEXE, but that does not
  415. exist with v1.1a of the  code builder? Since, 1.1a is almost
  416. 2 years old, it would seem that the documentation was simply
  417. copied from version 8.x of Watcom, rather than verifying it.
  418. Because  its plain  wrong. What  about the  use of il32 with
  419. watcom objects?
  420.  
  421.                                           Thanks
  422.                                           Jerry
  423. ___
  424.  X SLMR 2.1a X
  425.  
  426.  
  427. From:    Jerry Rice                             Rec'd
  428. To:      Dan Teven                              Msg #1607, Sep-29-93 05:13AM
  429. Subject: Future enhancements
  430.  
  431. DT>Jerry,
  432.  
  433. DT>You probably corresponded with me -- sorry if I didn't get back to
  434. DT>you, as I thought I'd done that.
  435.  
  436. DT>You may have noticed that Rational Systems has just released a
  437. DT>$149 DOS extender upgrade that offers a lot of additional power,
  438. DT>notably the bind capability and improved virtual memory manager.
  439. DT>We decided on these features because customers on this board (and
  440. DT>elsewhere) asked for them.
  441.  
  442.       That's just  it. I haven't  seen any info  anywhere on
  443. Rational Systems  anything!! Long ago, I  used to see things
  444. in Dr Dobbs,  C User's and the various  catalog outfits like
  445. "The Connection", Programmers  Paradise, Programmers Shopper
  446. but for a  long time they haven't carried  your products. So
  447. any info you can post here  would be nice to have. A mailing
  448. to those using Watcom wouldn't hurt either!!
  449.  
  450. DT>We did not include DLL support in the new product because it wasn't
  451. DT>quite as frequently asked for.  That's not to say we won't offer
  452. DT>DLL support in a retail product in the future, and thanks for
  453. DT>repeating your request -- we are listening to the market.
  454.  
  455. To  be honest,  I'd rather  stay with  Rational. It's a much
  456. "faster" and tighter  product, unless I get one  free with a
  457. compiler.  I have  SVS C  and Intel  Code Builder, both with
  458. free 4 gigabyte VM dos  extenders. (SVS is flakey) and Intel
  459. Code  Builder died).  And as   I said  in the  other message
  460. Borland and  Clarion will probably  be out with  theirs very
  461. soon, with DLL's. Please understand,  that it is a matter of
  462. fulfilling contracts that I have in house. I will do that by
  463. what I concider the  easiest, cheapest, least time consuming
  464. method.  The  requirements  of  me,  on  these products is a
  465. 486(Pentium)  (dos  extended  or   Windows  NT)  GUI  driven
  466. scientific analysis package. Consisting, aproximately, of 12
  467. programs. Each  having essentially the  same user interface.
  468. That user interface  is specified to be a  DLL. The contract
  469. is open ended at the moment waiting on the GUI support under
  470. the dos arena. Further, the Gov't will not on this contract(
  471. or  usually any),  pay for  muti runtime  licenses when  the
  472. software  is  custom  built.   I  also  have  other  general
  473. contracts waiting  for the same  type of upgrade,  to DLL's.
  474. The point is,  these are multiple products, quite  a few. No
  475. one that I know of will buy a license for 1000 when all they
  476. need  is  5-10.  When  a  person  has  a number of "support"
  477. contracts,  which include  upgrades to  "state of  the art",
  478. then DLL's are what they want.  Or they want it rewritten in
  479. Windows, which does support DLL's.  Because of the power and
  480. speed of extended dos, I really don't want to change, unless
  481. I have to. The 500 or so extra functions for a huge somewhat
  482. slow Os like Windows NT just doesn't turn me on!! Its easier
  483. for me to  just wait for the first  company to support DLL's
  484. under 386  extended Dos, without  licensing requirements. My
  485. modules are already  "Common" to all of my  products. So all
  486. I'll have  to do is  add a  switch  or two, as  is done with
  487. Borland and  Clarion now with  my 286 work.  The people that
  488. cantract   want    "commonality   of   code".    Its   quite
  489. understandable that they don't  want the wheel recreated all
  490. the time, or  that if a change is made  to module A, that it
  491. also has to be changed in  all other programs using module A
  492. and recompiled from scratch. They  want "the DLL" to be used
  493. by "anything  they have written".  Another thing is  this, I
  494. have a  dozen to 3  dozen programs that  "belong" to various
  495. companies and institutions. Most run time licenses that I am
  496. aware of are for ONE EXE or piece of code. I'm in a catch 22
  497. situation. If  the DLL recieved an  RTL, then to link  to it
  498. would possibly be ok. But in most cases, the way I have read
  499. licenses,  its not  the DLL  that is  licensed or licensable
  500. itself. $1995 for an RTL FOR 1 DLL used by 50 EXE's might be
  501. alright,  but  that's  not  the  usual  way  that things are
  502. written. You see the problem? This is one of the things that
  503. is going to have to  be addressed by "Extender" companies if
  504. they  are to  remain competitive.  Since there  are so  many
  505. companies coming up with their own extenders and methods for
  506. free, how  can "Rathional" or  "Pharlap" remain competitive?
  507. Borland dropped Pharlap from  Borland Pascal and wrote their
  508. own extender which does  fine in 286 extension. Clarion(JPI)
  509. didn't even bother with the  intermediate step of going with
  510. an extender company first.
  511.  
  512.  
  513.  
  514.                                           Sincerely
  515.                                           Jer
  516. ___
  517.  X SLMR 2.1a X
  518.  
  519. *** See also #1615.
  520.  
  521.  
  522. From:    Robert Campbell                        Rec'd
  523. To:      Kevin Kitsemetry                       Msg #1611, Sep-30-93 02:36PM
  524. Subject: Bug reported in GMA_BUG.ZIP
  525.  
  526. KK> Internal Report #6647
  527.  
  528.  
  529. Please look in GMA_BUG.ZIP for the sample code to a problem that we have
  530. encountered with WVIDEO (windows).  This program seems to run fine on the
  531. first execution through the debugger, but on the second run through,ie: new; go
  532. it crashes.  Any help you can give in this matter would be greatly appreciated.
  533.  
  534. Thanks.
  535. Robert Campbell
  536. Geophysical Micro Computer Applications Int'l Ltd.
  537.  
  538. *** See also #1724.
  539.  
  540.  
  541. From:    Robert Campbell                        Rec'd
  542. To:      Kevin Kitsemetry                       Msg #1612, Sep-30-93 02:44PM
  543. Subject: bug encountered with DIB's
  544.  
  545. KK> See previous message
  546.  
  547.  
  548. in the file GMA_BUG2.zip is the code and the compile instructions for a
  549. problem we are encountering with SetDIBitsToDevice.  Under certain conditions
  550. it fails.  We are'n sure what the conditions are.
  551.  
  552. In the sample code we have an array of pointers that we atart allocating
  553. memory to (in a loop)
  554. ie:
  555.    int *traces[115];
  556.  
  557.    for (i = 0; i < 100; i++) {
  558.         trace[i] = (int *) calloc(2048, sizeof(int));
  559.         if (trace[i] == NULL) {
  560.             ...
  561.         }
  562.    }
  563.  
  564. If we change the loop to execute 105 times the SetDIBits to Device will (below
  565. the allocation loop) fail.  We cannot see anything that would cause this
  566. problem.
  567.  
  568. The example program should fill the client area of the program with BLACK if
  569. it succeeds.
  570.  
  571.  
  572.  
  573. From:    Oivind Danielsen                       Rec'd
  574. To:      Kevin Kitsemetry                       Msg #1613, Sep-30-93 10:32AM
  575. Subject: EMM386
  576.  
  577. I use the EMM386.EXE supplied in DOS 6.0, and would very much like to continue
  578. doing so. I have fixed the 2 minute wait-while-loading problem with WCC386.EXE
  579. and similar by configuring them with the following switch value (CFIG386.EXE,
  580. pharlap) -MAXV 0 (maxvcpimem)
  581.  
  582. The question is: Can i do this ?
  583.  
  584. Thanks in advance,
  585. Oivind H. Danielsen
  586. DIRECT ANIMATION
  587.  
  588. *** See also #1619.
  589.  
  590.  
  591. From:    Dan Teven                              Rec'd
  592. To:      Jerry Rice                             Msg #1615, Sep-30-93 11:41AM
  593. Subject: Future enhancements
  594.  
  595. Jerry,
  596.  
  597. I have put both the press release and sales piece up on this BBS,
  598. and we are doing a mass mailing to all registered WATCOM customers,
  599. but the mailing was held up by a problem with the labels.  You
  600. should receive it shortly.  In the meantime, I will be happy to
  601. answer any questions you have about Rational Systems' extenders --
  602. over in area 15.
  603.  
  604. Rational Systems has never offered a retail DOS extender before;
  605. the products you used to see in mail order catalogues were not
  606. DOS extenders, but other tools.  We've traditionally sold our
  607. DOS extenders to companies with big needs for service and support,
  608. for example Lotus (1-2-3 release 3 was built on DOS/16M).  Just
  609. offering a retail upgrade to DOS/4GW was a change of direction
  610. for us.
  611.  
  612. Because we are new to the retail market, we don't really know
  613. how profitable we can be selling upgrades to DOS/4GW.  If the first
  614. upgrade, DOS/4GW Professional, proves that the market is there,
  615. we might offer DLL support as an option to WATCOM customers
  616. at some point.  We are grateful for your opinion but we have to
  617. collect more data before we decide to change our business focus;
  618. and offering too good a DOS extender for too little money would
  619. put a dent in our OEM business.
  620.  
  621. You might want to look at DESQview/X, from Quarterdeck Office
  622. Systems, which contains a royalty-free Rational Systems DOS extender
  623. WITH full support for DLLs...
  624.  
  625. Dan Teven
  626. Rational Systems
  627.  
  628. *** This is a reply to #1607.
  629.  
  630.  
  631. From:    Kevin Kitsemetry                       Rec'd
  632. To:      Jerry Rice                             Msg #1616, Sep-30-93 01:45PM
  633. Subject: Future enhancements
  634.  
  635.  JR> To the Powers that be.
  636.  
  637.  JR>       That is to someone of decision making capability as to
  638.  JR> enhancements to the "product". First  of all, Watcom is well
  639.  JR> known  as the  innovator in  32 extended  dos programming. I
  640.  JR> feel that  I should point out  some things which may  not be
  641.  JR> realized because they are not talked about much, either here
  642.  JR> or for that matter in most forums.
  643.  
  644.  
  645.  JR> That is DLL's under DOS Extension.
  646.  
  647.  JR>       Watcom on the other hand doesn't have that capability.
  648.  JR> Sure, one  can pay $5000.00 and  obtain that capability with
  649.  JR> Rational's  Dos extender,  but why?  If I  can get  the same
  650.  JR> thing from  Borland or Clairion  for an upgrade  fee, or for
  651.  JR> considerably  less  than  $5000.00,  then  I  don't see that
  652.  JR> Watcom  would be  a good  buy any  longer. Particularly if I
  653.  JR> want that feature.
  654.  
  655.  JR>       Realize that the Dos Extended  DLL is a major feature,
  656.  JR> even  though the  primary "talk"  everywhere is Windows/OS2.
  657.  JR> For those that want and need  them, like myself, it can be a
  658.  JR> determining factor  as to upgrade  or purchase. It  is quite
  659.  JR> nice to have one  DLL and 10 exe's link to it  on the fly. A
  660.  JR> lot less disk space and a lot less maintainance. One can put
  661.  JR> one's GUI  or Text User Interface  into this DLL and  have a
  662.  JR> number of  programs call it.  Or one can  put their math  or
  663.  JR> graphics routines in them, etc..
  664.  
  665.  
  666.  JR>       It seems  strange to me that  Watcom doesn't have this
  667.  JR> already, since Watcom is the innovator in 386 dos extension.
  668.  JR> As  we  all  know,  nothing  stays  static  in  the software
  669.  JR> development world,  just as the section  in your users guide
  670.  JR> on using Intel Code Builder with Watcom is mostly wrong.
  671.  
  672. WATCOM does support the use of DOS Extenders (such as DOS/4G and PharLap) that
  673. do allow for the creation of 32-bit DLLs under extended DOS.  The fact that we
  674. offer a free DOS extender that does not support them, does not mean that
  675. WATCOM doesn't support them.  Basically, people wanted to create 32-bit
  676. applications that will run under DOS.  In an effort to allow them to do this,
  677. we provide a royalty free DOS extender that provides a subset of the
  678. functionality that the user would have received had they paid the full price
  679. for the DOS extender.
  680.  
  681. If you would like to see this functionality added to the 'free' DOS extender,
  682. you can ask Dan Teven (Rational Systems) in area 15.
  683.  
  684. Kevin Kitsemetry
  685. WATCOM TECHNICAL SUPPORT
  686.  
  687. *** This is a reply to #1589.
  688.  
  689.  
  690. From:    Kevin Kitsemetry                       Rec'd
  691. To:      Oivind Danielsen                       Msg #1619, Sep-30-93 02:44PM
  692. Subject: EMM386
  693.  
  694.  OD> I use the EMM386.EXE supplied in DOS 6.0, and would
  695.  OD> very much like to continue doing so. I have fixed the
  696.  OD> 2 minute wait-while-loading problem with WCC386.EXE
  697.  OD> and similar by configuring them with the following
  698.  OD> switch value (CFIG386.EXE, pharlap) -MAXV 0
  699.  OD> (maxvcpimem)
  700.  OD>
  701.  OD> The question is: Can i do this ?
  702.  
  703. I don't see why not.  People are also using the EMM386 from Windows, which
  704. works better.
  705.  
  706. Kevin Kitsemetry
  707. WATCOM TECHNICAL SUPPORT
  708.  
  709. *** This is a reply to #1613.
  710.  
  711.  
  712. From:    Kevin Blenkinsopp                      Rec'd
  713. To:      Kevin Kitsemetry                       Msg #1620, Sep-30-93 04:32PM
  714. Subject: A-Level patches, bimodal bugs
  715.  
  716. As far as I can tell, the new version of bimodal works. Thanks. I've never
  717. actually looked at the C forum since we don't do any vanilla C. I'll try and
  718. remember next time that a problem in the C++ compiler might very well be
  719. referenced there as well. I'm not too bright lately. Anyway, barring something
  720. horrible happening, this means we can complete the port and throw that @#&!%
  721. piece of *$@# microscuzz compiler in the garbage. We're about one week away
  722. from the 60 day trial running out, and I'm very glad that I don't have to send
  723. the compiler back. It also means I get to keep my job, which is probably a
  724. good thing. Go tell your boss that you deserve a raise.
  725.  
  726. By the way, I had ported the comms drivers to C from assembler. It seems weird
  727. to be porting them back now. (About six months later). I realise that I could
  728. write the protected mode handler in C, but then I'd still have to keep the
  729. real mode version in asm. Is there any chance that the compiler would be
  730. extended one of these days so I could write something like
  731.  
  732. static void bimodal AsyncHandler(void)
  733.  
  734. and have both sets of code generated for me? Maintaining one set of drivers is
  735. annoying enough, but two of them is going to drive me round the bend. Oh well,
  736. if that's the price I pay for all the other advantages I suppose I'll have to
  737. live with it. It really would be nice though.
  738.  
  739. As a casual aside, I have some ray-tracing code originally created with MSVC.
  740. When I ported that to Watcom, it picked up my returning a temporary by
  741. reference, which ms didn't (very nice!) and cut the rendering time to just
  742. under a half of what it had been. A half! That's a lot!
  743.  
  744. All in all, I'm very happy with the compiler. Please pat everybody on the back
  745. for me.
  746.  
  747. Thanks again,
  748.  
  749. Kevin
  750.  
  751. *** See also #1624.
  752.  
  753.  
  754. From:    John Auld                              Rec'd
  755. To:      Kevin Kitsemetry                       Msg #1621, Sep-30-93 07:44PM
  756. Subject: HELP!
  757.  
  758. Who do you have to know to get help around here???? I left a message (#1524)
  759. over 2 weeks ago, and haven't gotten a reply. I have had zero luck getting
  760. anyone to even return my calls, let alone in a reasonable amount of time. Am I
  761. gonna have to go back to Microsoft?
  762.  
  763. Seriously, it was pretty tough to convince management that porting to this
  764. nifty new compiler was the thing to do. How do I explain that this compiler I
  765. sold them on doesn't come with any discernible tech support?
  766.  
  767. *** See also #1626.
  768.  
  769.  
  770. From:    Joe Friedman
  771. To:      Tech Support                           Msg #1622, Sep-30-93 10:23PM
  772. Subject: 3rd Party Libraries
  773.  
  774. I've been developing software using Microsoft C and am tired of
  775. dealing with 64K segments, 640K barriers, etc.  So I bought the
  776. WATCOM 32-bit C compiler, hoping to use the DOS extender to get
  777. around these restrictions.  However, I use a number of 3rd party
  778. libraries that run some imaging hardware in my system, such as
  779. Xionics' image primitives.  Most of these 3rd parties do NOT have
  780. WATCOM 32-bit versions of their libraries.  Is it possible to
  781. link these object libraries with 32-bit C code?  If so, how do I
  782. go about it?  If not, any suggestions on how to deal with them?
  783.  
  784. I also have use some 16-bit TSR's that are called via software interrupts.
  785. Is it possible to call these TSR's from 32-bit C code?  How does one
  786. deal with address differences (flat vs. segment:offset)?
  787.  
  788. *** See also #1627.
  789.  
  790.  
  791. From:    Christer Palm                          Rec'd
  792. To:      Mark Delafranier                       Msg #1623, Oct-18-93 11:00AM
  793. Subject: Bug in pow()
  794.  
  795. KK> Internal Report #6213
  796.  
  797.  
  798.  MD> Can you provide a small sample program that will
  799.  MD> reproduce the problem? This will greatly assist into
  800.  
  801. OK, Here it is:
  802.  
  803. NOTE 1: I haven't examined if this bug occurs with other math
  804.           functions, so similar bugs might be present in other
  805.           math funcs !!!
  806.  
  807.      2: This bug only occurs when a user SIGFPE handler is present
  808.  
  809. Could you also PLEEEAAASE take a look at msg #1527 ???
  810.  
  811. Compile & link: wcl386 -od bug.c
  812.  
  813.  
  814. #include <stdio.h>
  815. #include <signal.h>
  816. #include <math.h>
  817. #include <errno.h>
  818.  
  819. void fpe_handler( int signo )
  820. {
  821.   puts( "Caught SIGFPE" );
  822.   signal( SIGFPE, fpe_handler );
  823. }
  824.  
  825. int matherr( struct exception *err )
  826. {
  827.   puts( "Caught matherr" );
  828.   return 0;
  829. }
  830.  
  831. void main( void )
  832. {
  833.   signal( SIGFPE, fpe_handler );
  834.  
  835.   errno = 0;
  836.   log( -1.0 );          // No SIGFPE, sets errno, calls matherr
  837.   printf( "errno after invalid log: %d\n", errno );
  838.  
  839.   errno = 0;
  840.   pow( 1000.0, 1000.0 );    // Raises SIGFPE, no errno, no matherr
  841.   printf( "errno after invalid pow: %d\n", errno );
  842. }
  843.  
  844. *** This is a reply to #1572.  *** See also #1735.
  845.  
  846.  
  847. From:    Kevin Kitsemetry                       Rec'd
  848. To:      Kevin Blenkinsopp                      Msg #1624, Oct-01-93 09:53AM
  849. Subject: A-Level patches, bimodal bugs
  850.  
  851.  KB> As far as I can tell, the new version of bimodal works. Thanks. I've
  852.  KB> never actually looked at the C forum since we don't do
  853.  KB> any vanilla C. I'll try and remember next time that a
  854.  KB> problem in the C++ compiler might very well be
  855.  KB> referenced there as well. I'm not too bright lately.
  856.  KB> Anyway, barring something horrible happening, this
  857.  KB> means we can complete the port and throw that @#&!%
  858.  KB> piece of *$@# microscuzz compiler in the garbage.
  859.  KB> We're about one week away from the 60 day trial
  860.  KB> running out, and I'm very glad that I don't have to
  861.  KB> send the compiler back. It also means I get to keep my
  862.  KB> job, which is probably a good thing. Go tell your boss
  863.  KB> that you deserve a raise.
  864.  
  865.  KB> By the way, I had ported the comms drivers to C from assembler. It seems
  866.  KB> weird to be porting them back now. (About six months
  867.  KB> later). I realise that I could write the protected
  868.  KB> mode handler in C, but then I'd still have to keep the
  869.  KB> real mode version in asm. Is there any chance that the
  870.  KB> compiler would be extended one of these days so I
  871.  KB> could write something like
  872.  
  873.  KB> static void bimodal AsyncHandler(void)
  874.  
  875.  KB> and have both sets of code generated for me?
  876.  KB> Maintaining one set of drivers is annoying enough, but
  877.  KB> two of them is going to drive me round the bend. Oh
  878.  KB> well, if that's the price I pay for all the other
  879.  KB> advantages I suppose I'll have to live with it. It
  880.  KB> really would be nice though.
  881.  
  882.  KB> As a casual aside, I have some ray-tracing code
  883.  KB> originally created with MSVC. When I ported that to
  884.  KB> Watcom, it picked up my returning a temporary by
  885.  KB> reference, which ms didn't (very nice!) and cut the
  886.  KB> rendering time to just under a half of what it had
  887.  KB> been. A half! That's a lot!
  888.  
  889.  KB> All in all, I'm very happy with the compiler. Please
  890.  KB> pat everybody on the back for me.
  891.  
  892. I am glad to hear that things are going better for you now. I will be sure to
  893. pass on your compliments and suggestions.
  894.  
  895. Also, I should mention that there are a couple of issues
  896. that lead to the necessity of building a bimodal handler.
  897. The first one is speed.  This is the one concerns you.
  898. The second one is the interrupt for which the handler is in question, is not
  899. in the autopassup range for the DOS/4GW
  900. extender.  The full blown DOS/4G extender will allow the
  901. programmer to specify which interrupts fall into the
  902. autopassup range.  As far as speed is concerned, I know that there are 3rd
  903. party packages available to handle high speed communication requirements.  I
  904. doubt that you will see a
  905. bimodal type keyword added to the compiler in the short term,but I will pass
  906. on the suggestion.
  907.  
  908.  
  909. Kevin Kitsemetry
  910. WATCOM TECHNICAL SUPPORT
  911.  
  912. *** This is a reply to #1620.
  913.  
  914.  
  915. From:    Kevin Kitsemetry                       Rec'd
  916. To:      John Auld                              Msg #1626, Oct-01-93 10:11AM
  917. Subject: HELP!
  918.  
  919.  JA> Who do you have to know to get help around here???? I
  920.  JA> left a message (#1524) over 2 weeks ago, and haven't
  921.  JA> gotten a reply. I have had zero luck getting anyone to
  922.  JA> even return my calls, let alone in a reasonable amount
  923.  JA> of time. Am I gonna have to go back to Microsoft?
  924.  JA>
  925.  JA> Seriously, it was pretty tough to convince management
  926.  JA> that porting to this nifty new compiler was the thing
  927.  JA> to do. How do I explain that this compiler I sold them
  928.  JA> on doesn't come with any discernible tech support?
  929.  
  930. I am sorry for the delay.  It seems there was some confusion as your original
  931. message was posted to Mike Paola.  I will
  932. ensure that your message is taken care of ASAP.
  933.  
  934.  
  935. Kevin Kitsemetry
  936. WATCOM TECHNICAL SUPPORT
  937.  
  938. *** This is a reply to #1621.
  939.  
  940.  
  941. From:    Kevin Kitsemetry                       Rec'd
  942. To:      Joe Friedman                           Msg #1627, Oct-01-93 10:14AM
  943. Subject: 3rd Party Libraries
  944.  
  945.  JF> I've been developing software using Microsoft C and am tired of
  946.  JF> dealing with 64K segments, 640K barriers, etc.  So I bought the
  947.  JF> WATCOM 32-bit C compiler, hoping to use the DOS extender to get
  948.  JF> around these restrictions.  However, I use a number of 3rd party
  949.  JF> libraries that run some imaging hardware in my system, such as
  950.  JF> Xionics' image primitives.  Most of these 3rd parties do NOT have
  951.  JF> WATCOM 32-bit versions of their libraries.  Is it possible to
  952.  JF> link these object libraries with 32-bit C code?  If so, how do I
  953.  JF> go about it?  If not, any suggestions on how to deal with them?
  954.  
  955. These third party vendor libraries cannot be linked with the WATCOM compiler
  956. and linker.  We are compatible with Microsoft at the source level, not the
  957. object level.  Perhaps there are other companies that DO support the WATCOM 32-
  958. bit compiler.  You may contact Roger Kehl at WATCOM (519) 886-3700 for more
  959. information.
  960.  
  961.  
  962.  JF> I also have use some 16-bit TSR's that are called via
  963.  JF> software interrupts.
  964.  JF> Is it possible to call these TSR's from 32-bit C code?  How does one
  965.  JF> deal with address differences (flat vs. segment:offset)?
  966.  
  967. I believe that you can still call these TSR's by issuing a Real Mode Interrupt
  968. (DPMI function 0300h).
  969.  
  970.  
  971. Kevin Kitsemetry
  972. WATCOM TECHNICAL SUPPORT
  973.  
  974. *** This is a reply to #1622.  *** See also #1628.
  975.  
  976.  
  977. From:    FlashTek Inc.                          Rec'd
  978. To:      John Miles                             Msg #1628, Oct-02-93 06:24AM
  979. Subject: New debugger.
  980.  
  981. I saw the new debugger in Boston a few weeks ago.  It did look quite nice.  I
  982. was a bit disappointed that the delivery date may be a bit farther away that I
  983. would have liked (1Q '94).  Flashtek is hoping (no promises!) to deliver
  984. FlashView for Watcom in the next month or so.  We'll see... it seems that
  985. these things always take longer than we expect.
  986.  
  987. Joe Huffman
  988. FlashTek, Inc.
  989. 208-882-6893
  990. joe@proto.com
  991.  
  992. *** This is a reply to #1438.  *** See also #1698.
  993.  
  994.  
  995. From:    Arthur Jones
  996. To:      Tech Support                           Msg #1629, Oct-02-93 03:25PM
  997. Subject: wmake nt and long filenames
  998.  
  999. i'm having some problems with wmake in binnt, with short filenames
  1000. it works find but it doesn't seem to make long filenames on a ntfs
  1001. file system.  my makefile has both long and short filenames with
  1002. equivalent dependencies, the short filenames work fine but the
  1003. long filenames give an unable to make target error.  need i do
  1004. something different?  it doesn't seem i should.  btw, case sensitivity
  1005. seems to work.
  1006.  
  1007. *** See also #1631.
  1008.  
  1009.  
  1010. From:    John Lansdale
  1011. To:      Technical Support                      Msg #1630, Oct-04-93 06:48AM
  1012. Subject: Sending out Level A patches by mail
  1013.  
  1014. Considering the size of the level A patches, and the fact that I only have
  1015. a 2400 baud modem, could I get a copy of the DOS & C++ level A patches
  1016. by mail? Thanks.
  1017.  
  1018.  
  1019. *** See also #1632.
  1020.  
  1021.  
  1022. From:    Anthony Scian                          Rec'd
  1023. To:      Arthur Jones                           Msg #1631, Oct-04-93 11:35AM
  1024. Subject: wmake nt and long filenames
  1025.  
  1026.  AJ> i'm having some problems with wmake in binnt, with short filenames
  1027.  AJ> it works find but it doesn't seem to make long filenames on a ntfs
  1028.  AJ> file system.  my makefile has both long and short filenames with
  1029.  AJ> equivalent dependencies, the short filenames work fine but the
  1030.  AJ> long filenames give an unable to make target error.  need i do
  1031.  AJ> something different?  it doesn't seem i should.  btw, case sensitivity
  1032.  AJ> seems to work.
  1033.  
  1034. I'll look into this problem.
  1035.  
  1036. Anthony
  1037.  
  1038. *** This is a reply to #1629.
  1039.  
  1040.  
  1041. From:    Paul Tletski
  1042. To:      Watcom Folk                            Msg #1633, Oct-04-93 03:28PM
  1043. Subject: Question about 9.5 problem.
  1044.  
  1045. `ppDsx{~The following is a program that I've been using to test out Watcom,
  1046. DOS, and
  1047. DOS/4GW.
  1048. .
  1049. // test.c
  1050. .
  1051. #include <stdio.h>
  1052. #include <stdlib.h>
  1053. #include <dos.h>
  1054. .
  1055. //
  1056. // Type declarations.
  1057. //
  1058. typedef unsigned short ushort;
  1059. typedef unsigned long ulong;
  1060. .
  1061. //
  1062. // Function prototypes.
  1063. //
  1064. void main(void);
  1065. .
  1066. //
  1067. // "far" address structure.
  1068. //
  1069. typedef struct far_address {
  1070. ushort selector;
  1071. ulong offset;
  1072. } FAR_ADDRESS;
  1073. .
  1074. //
  1075. // Program main.
  1076. //
  1077. void main ()
  1078. {
  1079. union REGS regs;
  1080. struct SREGS sregs;
  1081. ushort far *ptest;
  1082. FAR_ADDRESS address;
  1083. .
  1084. ptest = (ushort far *)0x111122223333; // why does this generate a warning?
  1085. printf("%u\n", sizeof(ptest));
  1086. .
  1087. regs.h.ah = 0x2A;
  1088. intdosx(®s, ®s, &sregs); // an exception is generated in build 1
  1089. address.selector = sregs.es;
  1090. address.offset = regs.x.ebx;
  1091. .
  1092. //
  1093. // Will this work?  Will this copy the pointer "address" to
  1094. // the pointer ptest?
  1095. //
  1096. _fmemmove(ptest, &address, sizeof(ushort far *));
  1097. }
  1098. .
  1099. This example was tested with two build methods:
  1100. .
  1101. Build 1: wcl386 /l=dos4g /4s /d2 test.c
  1102. Build 2: wcl386 /l=dos4g /4r /d2 test.c
  1103. .
  1104. Both failed (.i.e. generated an exception) where noted in the source.
  1105. I can't find a decent explanation why.
  1106. .
  1107. Also, the documentation for 9.5 wcl386 fails to document the following
  1108. switches: /fd, /fe, /k and /l.  It looks like the documentation for
  1109. wcc386 is repeated.
  1110. .
  1111. I download C32DOS_A.ZIP and now have 9.5a.  There was no documentation
  1112. about what the update was about in the .zip.  Is there any update
  1113. documentation anywhere?
  1114. .
  1115. Thanks,
  1116. .
  1117. Paul Tletski
  1118. Highland Hts., Ohio
  1119.  
  1120. *** See also #1635.
  1121.  
  1122.  
  1123. From:    Kevin Kitsemetry                       Rec'd
  1124. To:      Charlie Link                           Msg #1634, Oct-04-93 04:31PM
  1125. Subject: NT DLL problem
  1126.  
  1127. KK> Internal report #4597
  1128.  
  1129.  
  1130.  CL> Because of your response to Jon Levinson, I thought I
  1131.  CL> would address this to you.  Sorry if you're not the
  1132.  CL> right person.
  1133.  CL> I can't get Win NT DLL to function properly. Your
  1134.  CL> example compiles cleanly (pp 283 ff), but upon
  1135.  CL> execution, I get an NT message that the application
  1136.  CL> failed to initialize properly (DLLTEST.EXE).  I can
  1137.  CL> LoadLibrary("dllsamp.dll") okay and the dlltest.exe will work fine if I
  1138.  CL> comment-out (//) the dll_entry_1() && dll_entry_2()
  1139.  CL> functions. Is this also a case of the EXPORT statement
  1140.  CL> of the linker not working as it was with NLMs ? I am
  1141.  CL> also using MARCH -1993 version of Win NT Beta, so I'm
  1142.  CL> surprised. By the Way, every other DLL (in more
  1143.  CL> complex programs) behaves the same way when a program
  1144.  CL> attempts to call (@ initialization).  I can Upload
  1145.  CL> files if you wish.
  1146.  
  1147. I was not aware of this problem with respect to NT apps, but it may well have
  1148. been related.  In any event, I have verified that the example program does
  1149. indeed export the function and execute properly with the latest version of the
  1150. compiler (patch level A) and the release version of Windows NT.
  1151.  
  1152.  
  1153. Kevin Kitsemetry
  1154. WATCOM TECHNICAL SUPPORT
  1155.  
  1156. *** This is a reply to #1381.
  1157.  
  1158.  
  1159. From:    Kevin Kitsemetry                       Rec'd
  1160. To:      Paul Tletski                           Msg #1635, Oct-04-93 04:45PM
  1161. Subject: Question about 9.5 problem.
  1162.  
  1163.  PT> `ppDsx{~The following is a program that I've been
  1164.  PT> using to test out Watcom, DOS, and
  1165.  PT> DOS/4GW.
  1166.  PT> .
  1167.  PT> // test.c
  1168.  
  1169. I have taken a look at this program, and it looks like a bug (or two). I have
  1170. brought it to the attention of the developers and will let you know when I
  1171. hear back from them.  You can track this problem with incident report #6869.
  1172.  
  1173.  
  1174.  PT> .
  1175.  PT> .
  1176.  PT> Also, the documentation for 9.5 wcl386 fails to document the following
  1177.  PT> switches: /fd, /fe, /k and /l.  It looks like the documentation for
  1178.  PT> wcc386 is repeated.
  1179.  
  1180. These are documented on page 46 of the User's Guide.
  1181.  
  1182.  
  1183.  PT> I download C32DOS_A.ZIP and now have 9.5a.  There was no documentation
  1184.  PT> about what the update was about in the .zip.  Is there any update
  1185.  PT> documentation anywhere?
  1186.  
  1187. Yes.  I believe the README.A file should contain what you are looking for.
  1188.  
  1189.  
  1190. Kevin Kitsemetry
  1191. WATCOM TECHNICAL SUPPORT
  1192.  
  1193. *** This is a reply to #1633.
  1194.  
  1195.  
  1196. From:    Anthony Scian                          Rec'd
  1197. To:      Paul Tletski                           Msg #1636, Oct-04-93 05:37PM
  1198. Subject: Question about 9.5 problem.
  1199.  
  1200.  PT> // "far" address structure.
  1201.  PT> //
  1202.  PT> typedef struct far_address {
  1203.  PT> ushort selector;
  1204.  PT> ulong offset;
  1205.  PT> } FAR_ADDRESS;
  1206.  PT> .
  1207.  PT> //
  1208.  PT> // Program main.
  1209.  PT> //
  1210.  PT> void main ()
  1211.  PT> {
  1212.  PT> union REGS regs;
  1213.  PT> struct SREGS sregs;
  1214.  PT> ushort far *ptest;
  1215.  PT> FAR_ADDRESS address;
  1216.  PT> .
  1217.  PT> ptest = (ushort far *)0x111122223333; // why does this
  1218.  
  1219.  Use the MK_FP() macro from <i86.h> to do this properly.
  1220.  e.g., ptest = MK_FP( 0x1111, 0x22223333 );
  1221.  
  1222.  PT> generate a warning?
  1223.  PT> printf("%u\n", sizeof(ptest));
  1224.  PT> .
  1225.  PT> regs.h.ah = 0x2A;
  1226.  
  1227.  You must execute a memset( &sregs, 0, sizeof( sregs ) ); because you
  1228.  cannot have random values in segment registers.
  1229.  
  1230.  PT> intdosx(®s, ®s, &sregs); // an exception is generated in build 1
  1231.  PT> address.selector = sregs.es;
  1232.  PT> address.offset = regs.x.ebx;
  1233.  PT> .
  1234.  PT> //
  1235.  PT> // Will this work?  Will this copy the pointer "address" to
  1236.  PT> // the pointer ptest?
  1237.  PT> //
  1238.  PT> _fmemmove(ptest, &address, sizeof(ushort far *));
  1239.  
  1240.  No.  Use *ptest = MK_FP( address.selector, address.offset );
  1241.  
  1242. *** This is a reply to #1633.
  1243.  
  1244.  
  1245. From:    Kevin Ross
  1246. To:      All                                    Msg #1637, Oct-04-93 08:16PM
  1247. Subject: Floating point under Windows DOS box
  1248.  
  1249. Hello,
  1250.  
  1251. I have Watcom C32 for DOS, and have encountered a rather odd problem.  The
  1252. following program, when run from DOS, works fine.  The same exact program run
  1253. from Windows 3.1 DOS session fails.
  1254.  
  1255. Here's the program:
  1256.  
  1257. #include <stdio.h>
  1258.  
  1259. int main(void)
  1260. {
  1261.     double num;
  1262.  
  1263.     num = 12.345;
  1264.     printf("%f\n", num);
  1265.     return(0);
  1266. }
  1267.  
  1268. I compiled with:
  1269.  
  1270. wcl386 fptest.c
  1271.  
  1272. When run from DOS, it outputs 12.345000.  When run from Windows DOS, it
  1273. outputs 0.000000.
  1274.  
  1275. Also, if I use the '-fpc' switch, all is well with the world.  This only seems
  1276. to happen using the emulator library.
  1277.  
  1278. My setup is:
  1279. 486sx/25 with 4M of RAM
  1280. 386Max memory manager v6.01
  1281. DOS 5.0
  1282. Windows 3.1
  1283.  
  1284. Thanks,
  1285. Kevin
  1286.  
  1287. kross@bix.com
  1288.  
  1289. *** See also #1645.
  1290.  
  1291.  
  1292. From:    Paul Tletski                           Rec'd
  1293. To:      Anthony Scian                          Msg #1640, Oct-05-93 07:50AM
  1294. Subject: Thanks, one more question...
  1295.  
  1296. Thanks for the speedy reply.
  1297. .
  1298. I thought of using MK_FP but noticed that it was in the header <dos.h>,
  1299. according to the library manual, so I had the fool though that it was for
  1300. 16:16 pointer -- which looking back was a pretty stupid thought.
  1301. .
  1302. Could you explain the syntax of the macro that is in <i86.h>?
  1303. .
  1304. #define MK_FP(__s,__o) (((unsigned short)(__s)):>((void __near *)(__o)))
  1305. .
  1306. ...
  1307. MK_FP(0x1111, 0x22223333);
  1308. .
  1309. -> (((unsigned short)(0x1111)):>((void near *)(0x22223333)));
  1310.       ^^- Don't understand...
  1311. .
  1312. Thanks,
  1313. .
  1314. Paul Tletski
  1315. Highland Hts.  Ohio
  1316. p.s. the ^^ should be under :>.
  1317. p.p.s Sorry I wasn't smart enough to read intdosx documentation. I haven't had
  1318. enough time to digest everything.  I'll try to be more thorough next time.
  1319.  
  1320. *** See also #1641.
  1321.  
  1322.  
  1323. From:    Anthony Scian                          Rec'd
  1324. To:      Paul Tletski                           Msg #1641, Oct-05-93 09:56AM
  1325. Subject: Thanks, one more question...
  1326.  
  1327.  PT> Thanks for the speedy reply.
  1328.  PT> .
  1329.  PT> I thought of using MK_FP but noticed that it was in the header <dos.h>,
  1330.  PT> according to the library manual, so I had the fool though that it was for
  1331.  PT> 16:16 pointer -- which looking back was a pretty stupid thought.
  1332.  
  1333.  I'll get this fixed in the docs.
  1334.  
  1335.  PT> .
  1336.  PT> Could you explain the syntax of the macro that is in <i86.h>?
  1337.  PT> .
  1338.  PT> #define MK_FP(__s,__o) (((unsigned short)(__s)):>((void __near *)(__o)))
  1339.  PT> .
  1340.  PT> ...
  1341.  PT> MK_FP(0x1111, 0x22223333);
  1342.  PT> .
  1343. -> (((unsigned short)(0x1111)):>((void near *)(0x22223333)));
  1344.  PT>       ^^- Don't understand...
  1345.  
  1346. We support MS C based pointers with our compilers.  The ':>' operator forms a
  1347. far pointer from a segment and a based pointer offset.  It is more portable to
  1348. other C compilers to use the MK_FP macro.  We support the based pointer stuff
  1349. (which you can find described in MS C books in a book store) to help people
  1350. port from MSC/C++.  They are very error prone to use in practice. Use far and
  1351. based pointers sparingly in 32-bit land.
  1352.  
  1353. Anthony
  1354.  
  1355. *** This is a reply to #1640.
  1356.  
  1357.  
  1358. From:    Thomas B. Pollard
  1359. To:      Mike Kreutzweiser                      Msg #1642, Oct-05-93 01:26PM
  1360. Subject: C/C++ 9.5A Wvideo interrup with <SyRq>
  1361.  
  1362.  
  1363.  
  1364.  TO Watcom 519-747-4971
  1365.  FROM Tom Pollard 617-275-0100 Ex127
  1366.  C/C++ 9.5A Interrupting WVIDEO
  1367.  ;
  1368.  When I now run WVIDEO using the following lines and testing any of my
  1369.  programs I can no longer Interrupting with (PrtSc) or (SysRq).
  1370.  All I get is a beep.
  1371.  ;
  1372.  SET dos4g=quiet
  1373.  SET dos4gvm=
  1374.  wvideo -vga50 -trap=rsi -swap test
  1375.  ;
  1376.  I have tried just simple loop c programs.
  1377.  ;
  1378.  What I think is great, is now while I am in WVIDEO and NOT running a
  1379.  program you can print the screen.  Is this a symptom of the problem?
  1380.  
  1381. thanks TOM
  1382.  
  1383. *** See also #1646.
  1384.  
  1385.  
  1386. From:    Paul Tletski                           Rec'd
  1387. To:      Anthony Scian                          Msg #1643, Oct-06-93 11:58AM
  1388. Subject: Another pointer question...
  1389.  
  1390. I have a question concerning how to use int386 with 16 bit interrupt
  1391. handlers.  I have to interface Watcom 32-bit code with a DOS replacer
  1392. which provides an MS-DOS environment on top of a multitasking kernel.
  1393. Kernel functions are accessed through INT 2D with DL holding the
  1394. function code.
  1395.  
  1396. Consider the following example which creates a thread:
  1397.  
  1398. #include <dos.h>
  1399. ...
  1400. #define DPMI_INT        0x31
  1401. #define DPMI_DOSMEM     0x0300
  1402. #define SYSINT  0x2D
  1403. #define SYS_ALLOCATE_THREAD     0x00000001
  1404. #define IN
  1405. typedef unsigned short HANDLE;
  1406. typedef unsigned short ushort;
  1407. typedef struct real_mode_info {
  1408.         long edi;
  1409.         long esi;
  1410.         long ebp;
  1411.         long reserved;
  1412.         long ebx;
  1413.         long edx;
  1414.         long ecx;
  1415.         long eax;
  1416.         short flags;
  1417.         short es,ds,fs,gs,ip,cs,sp,ss;
  1418. } REAL_MODE_INFO;
  1419. ...
  1420. // Function prototypes
  1421. HANDLE AllocateThread (IN void (*func)());
  1422. void main (void);
  1423. void thread ();
  1424. //
  1425. ...
  1426. HANDLE AllocateThread (IN void (*func)())
  1427. {
  1428.         union REGS regs;
  1429.         struct SREGS sregs;
  1430.         REAL_MODE_INFO rminfo;
  1431.  
  1432.         // Set up the DPMI real mode structure.
  1433.         // CX:AX = Function to execute as thread.
  1434.         // DL    = SYSINT function code.
  1435.         // AX returns the thread's handle.
  1436.         memset(&rminfo, 0, sizeof(rminfo));
  1437.         rminfo.ecx = func >> 16;                // does this make sense?
  1438.         rminfo.eax = func & 0x0000FFFF;         // does this make sense?
  1439.         rminfo.edx = SYS_ALLOCATE_THREAD;
  1440.  
  1441.         regs.w.ax = DPMI_DOSMEM;
  1442.         regs.h.bl = SYSINT;
  1443.         regs.h.bh = 0;
  1444.         regs.w.cx = 0;
  1445.         sregs.es = FP_SEG(&rminfo);
  1446.         regs.x.edi = FP_OFF(&rminfo);
  1447.         int386x(DPMI_INT, ®s, ®s, &sregs);
  1448.  
  1449.         return (regs.w.cflag) ? 0 : (HANDLE)(regs.w.ax);
  1450. }
  1451. void thread ()
  1452. {
  1453. .....                   // do thread stuff
  1454. }
  1455.  
  1456. void main ()
  1457. {
  1458.         HANDLE hThread;
  1459. ...
  1460.         hThread = AllocateThread(thread);       // create a thread
  1461. ...
  1462. }
  1463.  
  1464. I guess the general question is how does one handle situations where
  1465. 16:16 pointers are expected, as in the above example?
  1466.  
  1467. Also, will there be an expection generated if the kernel tries to
  1468. execute the thread?
  1469.  
  1470. Thanks,
  1471. Paul Tletski
  1472. Highland Hts., OH
  1473.  
  1474.  
  1475. From:    David Zechiel                          Rec'd
  1476. To:      Kevin Kitsemetry                       Msg #1644, Oct-06-93 12:24PM
  1477. Subject: 'p' option on WCL386
  1478.  
  1479.   I have noticed that the 'p' option on WCL386 is listed twice, once to use
  1480. the protected version of the compiler and once as a 'proprocess' flag.  It
  1481. appears to me that WCL386 is getting confused and passing the 'p' flag to the
  1482. compiler instead of running the protected version of the compiler.  Am I doing
  1483. something wrong, and if not, is there a way to fix this?
  1484.  
  1485.   Dave Zechiel
  1486.  
  1487. *** See also #1647.
  1488.  
  1489.  
  1490. From:    Kevin Kitsemetry                       Rec'd
  1491. To:      Kevin Ross                             Msg #1645, Oct-06-93 03:02PM
  1492. Subject: Floating point under Windows DOS box
  1493.  
  1494.  KR> Hello,
  1495.  
  1496.  KR> I have Watcom C32 for DOS, and have encountered a
  1497.  KR> rather odd problem.  The following program, when run
  1498.  KR> from DOS, works fine.  The same exact program run from
  1499.  KR> Windows 3.1 DOS session fails.
  1500.  
  1501.  KR> Here's the program:
  1502.  
  1503.  KR> #include <stdio.h>
  1504.  KR>
  1505.  KR> int main(void)
  1506.  KR> {
  1507.  KR>     double num;
  1508.  KR>
  1509.  KR>     num = 12.345;
  1510.  KR>     printf("%f\n", num);
  1511.  KR>     return(0);
  1512.  KR> }
  1513.  
  1514.  KR> I compiled with:
  1515.  
  1516.  KR> wcl386 fptest.c
  1517.  
  1518.  KR> When run from DOS, it outputs 12.345000.  When run
  1519.  KR> from Windows DOS, it outputs 0.000000.
  1520.  
  1521.  KR> Also, if I use the '-fpc' switch, all is well with the
  1522.  KR> world.  This only seems to happen using the emulator
  1523.  KR> library.
  1524.  
  1525. You must make sure that you are running wdebug.386 or wemu387.386 (you can
  1526. ditribute the second one) as a device driver, specified in the system.ini
  1527. file, [386Enh] section.
  1528.  
  1529.  
  1530. Kevin Kitsemetry
  1531. WATCOM TECHNICAL SUPPORT
  1532.  
  1533. *** This is a reply to #1637.  *** See also #1649.
  1534.  
  1535.  
  1536. From:    Kevin Kitsemetry                       Rec'd
  1537. To:      Thomas B. Pollard                      Msg #1646, Oct-06-93 03:09PM
  1538. Subject: C/C++ 9.5A Wvideo interrup with <SyRq>
  1539.  
  1540.  TBP>  When I now run WVIDEO using the following lines and testing any of my
  1541.  TBP>  programs I can no longer Interrupting with (PrtSc) or (SysRq).
  1542.  TBP>  All I get is a beep.
  1543.  TBP>  ;
  1544.  TBP>  SET dos4g=quiet
  1545.  TBP>  SET dos4gvm=
  1546.  TBP>  wvideo -vga50 -trap=rsi -swap test
  1547.  TBP>  ;
  1548.  TBP>  I have tried just simple loop c programs.
  1549.  TBP>  ;
  1550.  TBP>  What I think is great, is now while I am in WVIDEO and NOT running a
  1551.  TBP>  program you can print the screen.  Is this a symptom of the problem?
  1552.  
  1553. There is no one named Mike Kreutzwieser at WATCOM.  There used to be a Kevin
  1554. Kreutzweiser (he is no longer at WATCOM) or Mike Paola.  I don't know anything
  1555. about this particular problem (I tried a search on all messages in this area).
  1556.  What version of the compiler do you have (and what patch level?  What
  1557. specific problems are you running into?
  1558.  
  1559.  
  1560. Kevin Kitsemetry
  1561. WATCOM TECHNICAL SUPPORT
  1562.  
  1563. *** This is a reply to #1642.  *** See also #1648.
  1564.  
  1565.  
  1566. From:    Kevin Kitsemetry                       Rec'd
  1567. To:      David Zechiel                          Msg #1647, Oct-06-93 03:13PM
  1568. Subject: 'p' option on WCL386
  1569.  
  1570.  DZ>   I have noticed that the 'p' option on WCL386 is
  1571.  DZ> listed twice, once to use the protected version of the
  1572.  DZ> compiler and once as a 'proprocess' flag.  It appears
  1573.  DZ> to me that WCL386 is getting confused and passing the
  1574.  DZ> 'p' flag to the compiler instead of running the
  1575.  DZ> protected version of the compiler.  Am I doing
  1576.  DZ> something wrong, and if not, is there a way to fix
  1577.  DZ> this?
  1578.  
  1579. After version 9.5, there is no longer a real mode version of the compiler.
  1580. So, the /p switch with the wcl[386] utility is no the same as with the
  1581. compiler; that is to pre-process the file.
  1582.  
  1583.  
  1584. Kevin Kitsemetry
  1585. WATCOM TECHNICAL SUPPORT
  1586.  
  1587. *** This is a reply to #1644.
  1588.  
  1589.  
  1590. From:    Thomas B. Pollard                      Rec'd
  1591. To:      Kevin Kitsemetry                       Msg #1648, Oct-06-93 03:59PM
  1592. Subject: C/C++ 9.5A Wvideo interrup with <SyRq>
  1593.  
  1594. I just added the A patches to C/C++ 9.5
  1595. While I am running Wvideo and type -G- for go I no longer can press
  1596. <Print Screen> to interupt the program from running.
  1597. This happend even with the simplest programs running.
  1598. (This id the DOS version of Wvideo.
  1599. Sorry about the name I was trying to remember your name.
  1600.  
  1601. *** This is a reply to #1646.  *** See also #1659.
  1602.  
  1603.  
  1604. From:    Kevin Ross                             Rec'd
  1605. To:      Kevin Kitsemetry                       Msg #1649, Oct-06-93 05:38PM
  1606. Subject: Floating point under Windows DOS box
  1607.  
  1608.  KK> You must make sure that you are running wdebug.386 or wemu387.386 (you can
  1609.  KK> ditribute the second one) as a device driver, specified in the system.ini
  1610.  KK> file, [386Enh] section.
  1611.  
  1612. I'd love to.  Could you tell me where I can find either of these files?  They
  1613. aren't included in my Watcom C32 for DOS distribution.
  1614.  
  1615. *** This is a reply to #1645.  *** See also #1660.
  1616.  
  1617.  
  1618. From:    Jerry Rice                             Rec'd
  1619. To:      Dan Teven                              Msg #1650, Oct-05-93 01:27PM
  1620. Subject: Future enhancements
  1621.  
  1622. DT>Jerry,
  1623.  
  1624. DT>I have put both the press release and sales piece up on this BBS,
  1625. DT>and we are doing a mass mailing to all registered WATCOM customers,
  1626. DT>but the mailing was held up by a problem with the labels.  You
  1627. DT>should receive it shortly.  In the meantime, I will be happy to
  1628. DT>answer any questions you have about Rational Systems' extenders --
  1629. DT>over in area 15.
  1630.  
  1631. DT>Rational Systems has never offered a retail DOS extender before;
  1632. DT>the products you used to see in mail order catalogues were not
  1633. DT>DOS extenders, but other tools.  We've traditionally sold our
  1634. DT>DOS extenders to companies with big needs for service and support,
  1635. DT>for example Lotus (1-2-3 release 3 was built on DOS/16M).  Just
  1636. DT>offering a retail upgrade to DOS/4GW was a change of direction
  1637. DT>for us.
  1638.  
  1639. DT>Because we are new to the retail market, we don't really know
  1640. DT>how profitable we can be selling upgrades to DOS/4GW.  If the first
  1641. DT>upgrade, DOS/4GW Professional, proves that the market is there,
  1642. DT>we might offer DLL support as an option to WATCOM customers
  1643. DT>at some point.  We are grateful for your opinion but we have to
  1644. DT>collect more data before we decide to change our business focus;
  1645. DT>and offering too good a DOS extender for too little money would
  1646. DT>put a dent in our OEM business.
  1647.  
  1648.       Its  better to  have a  dent, even  a big  one, than a
  1649. disaster, later.  With all the  compiler venders coming  out
  1650. with their "own" full featured  extenders, it seems to me to
  1651. be  a  sink  or  swim  situation  for companies that produce
  1652. extenders as  their mainstay. In  my opinion, with  the over
  1653. zealous jump  to Windows and Windows  NT, Dos marketting has
  1654. to do  quite a bit to  stay competitive. In the  near future
  1655. Dos will  change to 32 bit,  and there is no  guarantee that
  1656. Dos itself will not support  a lot of the hithertofore holes
  1657. that  I have  mentioned. As  far as  your update,  I will be
  1658. getting  it. (Even  though I  know little  about it) The big
  1659. advantage that Rational has  over the "vendors of compilers"
  1660. is reputation  in extended Dos.  I haven't got  time for the
  1661. devlopment of a bug free extender from the compiler vendors.
  1662. My purpose  is to write and  debug C code, and  not worry if
  1663. the  extender  is  going  to  work.  As time progresses, the
  1664. "vendors" will get their bugs out. And that is the time that
  1665. you have  left. That's where your  advantage is. Pharlap has
  1666. already realized this. That's why they are giving away their
  1667. "lite" package  with each Borland product  and TNT-Lite with
  1668. the   Microsoft  32   bit  products.   Their  Cavet   is  no
  1669. documentation,  which is  the wrong  way to  do it.  Borland
  1670. realized this long ago by creating toolkits for their Pascal
  1671. to show  that their little compiler  "could do anything". It
  1672. took a  lot of the mystery  out of programming, and  made it
  1673. realizable to the common man. Many many of the C programmers
  1674. today were brought into the  market because of Turbo Pascal.
  1675. By   not  providing   documentation,  Pharlap   has  reduced
  1676. drastically the number of people that would "venture to use"
  1677. their lite  product, let alone  their full product.  People,
  1678. programmers,  that  get  "used  to"  a  tool, rarely like to
  1679. change,  if  they  do  it  must  be  easily. The easier that
  1680. Rational  makes  it  for  the  programmer  to  grow into the
  1681. extended dos  world the more users  they will have. Rational
  1682. could offer their full product to 10 people, at $5,000.00 or
  1683. 100,000 at $100.00,  or wait and not be in  the game at all!
  1684. Nothing in  this business stands  still! "Secrets" and  half
  1685. products just aren't  IN in the market any  more. That's why
  1686. Apple is changing.
  1687.  
  1688.  
  1689. DT>You might want to look at DESQview/X, from Quarterdeck Office
  1690. DT>Systems, which contains a royalty-free Rational Systems DOS extender
  1691. DT>WITH full support for DLLs...
  1692.  
  1693.       There are other holes.
  1694.  
  1695.       I have been considering Desqview/X, The feature that I
  1696. like about  them is that  they are going  multi-platform, As
  1697. Windows  NT   has  promised.  The  basic   black  hole  with
  1698. Desqview/X is  the lack of  supporting software vendors,  eg
  1699. C libraries. For  instance, I haven't  got time to  set up a
  1700. complete GUI from scratch. That  is, X of Desqview/X is fine
  1701. as  a GUI,  but its  primitive, just  as the  Windows SDK is
  1702. primitive. There aren't any  libraries out there like CView,
  1703. or zApp, or TEGL, or Zinc or  OWL. That allow me to plug and
  1704. play. My  software is Scientific  Analysis, not GUI's.  With
  1705. the  large amount  of C  code  on  the market,  even in  the
  1706. extended  dos world,  I've been  able to  buy a  library for
  1707. everything other  than that which  I program myself,  ie the
  1708. scientific application  work. That, as  yet, does not  exist
  1709. under Desqview/X.  In a year  that might change,  just as it
  1710. changed for windows.
  1711.  
  1712.  
  1713.  
  1714.                                          Jer
  1715. ___
  1716.  X SLMR 2.1a X
  1717.  
  1718.  
  1719. From:    Jerry Rice                             Rec'd
  1720. To:      Kevin Kitsemetry                       Msg #1651, Oct-05-93 01:39PM
  1721. Subject: Future enhancements
  1722.  
  1723. KK> JR>       It seems  strange to me that  Watcom doesn't have this
  1724. KK> JR> already, since Watcom is the innovator in 386 dos extension.
  1725. KK> JR> As  we  all  know,  nothing  stays  static  in  the software
  1726. KK> JR> development world,  just as the section  in your users guide
  1727. KK> JR> on using Intel Code Builder with Watcom is mostly wrong.
  1728.  
  1729. KK>WATCOM does support the use of DOS Extenders (such as DOS/4G and PharLap)
  1730. KK>that do allow for the creation of 32-bit DLLs under
  1731. KK>extended DOS.  The fact that we offer a free DOS extender
  1732. KK>that does not support them, does not mean that WATCOM
  1733. KK>doesn't support them.  Basically, people wanted to create
  1734. KK>32-bit applications that will run under DOS.  In an effort
  1735. KK>to allow them to do this, we provide a royalty free DOS
  1736. KK>extender that provides a subset of the functionality that
  1737. KK>the user would have received had they paid the full price
  1738. KK>for the DOS extender.
  1739.  
  1740. KK>If you would like to see this functionality added to the
  1741. KK>'free' DOS extender, you can ask Dan Teven (Rational
  1742. KK>Systems) in area 15.
  1743.  
  1744.       My  point is  that one  can buy  Borland Pascal 7.0 or
  1745. Clarions  Top Speed  C, and   (out of  the box)  it directly
  1746. supports(able to create) DOS  DLL's without purchasing extra
  1747. products  or licenses.  Simply an  aditional compiler switch
  1748. and your code ends up a  dll. In that regard Watcom does NOT
  1749. support(able  to  create)  DLL's   under  DOS.  When  I  say
  1750. "support", I mean "as is", directly out of the box, no other
  1751. purchases  or permissions  necessary. I  was surprised  that
  1752. Watcom doesn't  already do this  in the 386  world, since it
  1753. will  be  coming  to  other  compiler  companies  very  very
  1754. shortly.
  1755.  
  1756.  
  1757.                                           Jer
  1758. ___
  1759.  X SLMR 2.1a X
  1760.  
  1761.  
  1762. From:    Jerry Rice                             Rec'd
  1763. To:      Roman Lewkow                           Msg #1652, Oct-05-93 01:54PM
  1764. Subject: Future enhancements
  1765.  
  1766. RL> JR> that I have quite a number  of EXE's that would have to have
  1767. RL> JR> the $1995 license,  even though only 5 to  10 for each would
  1768. RL> JR> be used. These are custom products, using my tools. It would
  1769.  
  1770. RL>Talk to them ( PLap ). I think they are quite aware of
  1771. RL>market changes. I always thought that the RTL covers all
  1772. RL>products you distribute, also multiple EXEs. Am I wrong ?
  1773. RL>Talk to them. As for buying separate SDK for each run time
  1774. RL>copy, it can only be used on one machine ! Not one SDK per
  1775. RL>customer.
  1776. RL> JR> Then  irregardless of  how many  copies are  used internally
  1777. RL> JR> they own it. That way they  pay $495 once. Or just wait till
  1778.  
  1779.       Your talking  about individual applications.  Lets say
  1780. that I had 5 exe's under one application. I could distribute
  1781. that   to  a   number  of   companies.  BUT   what  about  5
  1782. applications,  each different?  The way  I understand  their
  1783. terms  is that  it is  built for  those that  distribute ONE
  1784. product  to  many  customers,  not  many  products  to  many
  1785. customers. The way it would have  to be for me would be that
  1786. the license would cover anything that I compiled and decided
  1787. to distribute, irregardless of  the diversity in either code
  1788. or number of different exes.
  1789.  
  1790.  
  1791.  
  1792. RL>Nope. One SDK, one machine (at a time) -> usually one copy of your app.
  1793.  
  1794. RL> JR> Further, what about  Dos 7.0? Its supposed to  be 32 bit and
  1795. RL> JR> support limited multitasking and have  a "window" for 16 bit
  1796. RL> JR> apps, but primarily  be a 32 bit OS.  Those are just rumors,
  1797.  
  1798. RL>This is news to me. Sounds interesting, although this DOS would becone
  1799. RL>almost
  1800. RL>the OS2 1.x . I need to see it ( performance ? ).
  1801.  
  1802. RL> JR> world. There are  many of us out there  that couldn't give a
  1803. RL> JR> burnt  duck  about  Windows  or  OS2,  but would rather have
  1804. RL> JR> something small,  tight and fast,  using all the  memory and
  1805. RL> JR> disk it can grab. My stuff  doesn't wait for keyboard I/O or
  1806.  
  1807. RL>right !
  1808.  
  1809. RL> JR>                     Sorry to have gotten on the old soap box
  1810.  
  1811. RL>it just happens to be my old soap box too :-)
  1812.  
  1813. RL> JR> P.S.  I  already  have  the  semi  full  version of TNT with
  1814. RL> JR> MS  Fortran Power  Station, royalty  free. It  will go  to 4
  1815. RL> JR> gigabytes with  VM but I  don't think it  will create DLL's,
  1816. RL> JR> under Dos. And it does  not support threads or multi tasking
  1817. RL> JR> for MS Pwr Station. But I  figure I'll get a flyer soon from
  1818.  
  1819. RL>They also include this with MSC 32, supposedly with DLLs
  1820. RL>and stuff, but also with the limitations you mention (
  1821. RL>memory ).
  1822.  
  1823. The Powerstation  version does not  support DLLS, but  oddly
  1824. does have full 4 gigabyte support.
  1825.  
  1826. RL>My problems with Watcom & Rational are that they don't do what I need.
  1827. RL>See my traffic to Dan Teven in this forum and under subject dma in area 12.
  1828. RL>Phar Lap can do this, the can't. I'm also quite annoyed by
  1829. RL>pathetic documentation provided for the 4GW. New book
  1830. RL>doesn't even mention that 1.9 has new stuff, it's just a
  1831. RL>reprint from old docs. Took me a long time and some effort
  1832. RL>to get a list of new DPMI calls available under 1.9.
  1833. RL>Protection in Phar Lap model is also tighter.
  1834.  
  1835.       It seems to  me that the "NEW" book  is just a reprint
  1836. of  version  8.5,  in  many  more  respects  than  just  the
  1837. extender!!  Intel Code  builder section  is completely wrong
  1838. for the current version of the code builder, even though the
  1839. code builder  changed versions almost 2  years ago. It would
  1840. be  nice if  those could  be posted  here, and  in the patch
  1841. files as part of a new readme.txt.
  1842.  
  1843. RL>anyway, thanks for your comments; my regards, Roman
  1844.  
  1845.  
  1846.                               Jer
  1847. ___
  1848.  X SLMR 2.1a X
  1849.  
  1850.  
  1851. From:    Phil Duvalsaint                        Rec'd
  1852. To:      Kevin Kitsemetry                       Msg #1653, Oct-06-93 08:06PM
  1853. Subject: Targa Graphics Library
  1854.  
  1855. The problem seems to be that the functions in the Targa Graphics kit
  1856. are ignored.  The compiler compiles but the linker still can't
  1857. find several function definitions. I've had to fudge the original library
  1858. sources to get them to compile. (Mostly problems with register names
  1859. like changing AX to AEX or something (since Microsoft used 16 bit
  1860. register names and Watcom uses the 32 bit names)) I believe that the
  1861. problem has something to do with building the library. There has to be
  1862. an easier way. I seem to have run into several problems with converting
  1863. Microsoft C code to Watcom. Mostly associated with finding the right library.
  1864.  
  1865. *** This is a reply to #1098.  *** See also #1661.
  1866.  
  1867.  
  1868. From:    Christer Palm                          Rec'd
  1869. To:      Kevin Kitsemetry                       Msg #1654, Oct-07-93 08:15AM
  1870. Subject: Technical support
  1871.  
  1872. Are you guys just reading the last 3 messages every Friday or so ???
  1873. I can't say that I'm happy with the Technical Support turnaround times !
  1874. Sometimes problem reports doesn't get answered at all !!
  1875.  
  1876. Could you PLEEEASE take a look a msg #1623 & 1527 ??
  1877.  
  1878. Thanks
  1879.   Christer
  1880.  
  1881. *** See also #1662.
  1882.  
  1883.  
  1884. From:    Paul Tletski
  1885. To:      Watcom Folk                            Msg #1655, Oct-07-93 09:00AM
  1886. Subject: Function Pointer Question...
  1887.  
  1888. I have a question concerning how to use int386 with 16 bit interrupt
  1889. handlers.  I have to interface Watcom 32-bit code with a DOS replacer
  1890. which provides an MS-DOS environment on top of a multitasking kernel.
  1891. Kernel functions are accessed through INT 2D with DL holding the
  1892. function code.
  1893.  
  1894. Consider the following example which creates a thread:
  1895.  
  1896. #include <dos.h>
  1897. ...
  1898. #define DPMI_INT        0x31
  1899. #define DPMI_DOSMEM     0x0300
  1900. #define SYSINT  0x2D
  1901. #define SYS_ALLOCATE_THREAD     0x00000001
  1902. #define IN
  1903. typedef unsigned short HANDLE;
  1904. typedef unsigned short ushort;
  1905. typedef struct real_mode_info {
  1906.         long edi;
  1907.         long esi;
  1908.         long ebp;
  1909.         long reserved;
  1910.         long ebx;
  1911.         long edx;
  1912.         long ecx;
  1913.         long eax;
  1914.         short flags;
  1915.         short es,ds,fs,gs,ip,cs,sp,ss;
  1916. } REAL_MODE_INFO;
  1917. ...
  1918. // Function prototypes
  1919. HANDLE AllocateThread (IN void (*func)());
  1920. void main (void);
  1921. void thread ();
  1922. //
  1923. ...
  1924. HANDLE AllocateThread (IN void (*func)())
  1925. {
  1926.         union REGS regs;
  1927.         struct SREGS sregs;
  1928.         REAL_MODE_INFO rminfo;
  1929.  
  1930.         // Set up the DPMI real mode structure.
  1931.         // CX:AX = Function to execute as thread.
  1932.         // DL    = SYSINT function code.
  1933.         // AX returns the thread's handle.
  1934.         memset(&rminfo, 0, sizeof(rminfo));
  1935.         rminfo.ecx = func >> 16;                // does this make sense?
  1936.         rminfo.eax = func & 0x0000FFFF;         // does this make sense?
  1937.         rminfo.edx = SYS_ALLOCATE_THREAD;
  1938.  
  1939.         regs.w.ax = DPMI_DOSMEM;
  1940.         regs.h.bl = SYSINT;
  1941.         regs.h.bh = 0;
  1942.         regs.w.cx = 0;
  1943.         sregs.es = FP_SEG(&rminfo);
  1944.         regs.x.edi = FP_OFF(&rminfo);
  1945.         int386x(DPMI_INT, ®s, ®s, &sregs);
  1946.  
  1947.         return (regs.w.cflag) ? 0 : (HANDLE)(regs.w.ax);
  1948. }
  1949. void thread ()
  1950. {
  1951. .....                   // do thread stuff
  1952. }
  1953. void main ()
  1954. {
  1955.         HANDLE hThread;
  1956. ...
  1957.         hThread = AllocateThread(thread);       // create a thread
  1958. ...
  1959. }
  1960.  
  1961. I guess the general question is how does one handle situations where
  1962. 16:16 pointers are expected, as in the above example?
  1963.  
  1964. Also, will there be an expection generated if the kernel tries to
  1965. execute the thread?
  1966.  
  1967. Thanks,
  1968. Paul Tletski
  1969. Highland Hts., OH
  1970. p.s. Is this a situation where I should use callbacks?
  1971.  
  1972. *** See also #1657.
  1973.  
  1974.  
  1975. From:    Kevin Kitsemetry
  1976. To:      Ned Konz                               Msg #1656, Oct-07-93 09:44AM
  1977. Subject: Windows NT exception handling
  1978.  
  1979. KK> Contacted customer directly.
  1980.  
  1981.  
  1982.  NK> Some time ago I left a message saying that we wanted
  1983.  NK> to use Watcom on our NT project, but that we needed to
  1984.  NK> be able to catch the NT exceptions (thrown by
  1985.  NK> RaiseException()). I received a reply that said
  1986.  NK> that,although Watcom didn't currently work with the NT
  1987.  NK> exception handling scheme,Watcom was "looking into it".
  1988.  
  1989.  NK> I did some more investigation, thinking I could get something working. I
  1990.  NK> was wrong: there is an undocumented interface to the
  1991.  NK> Windows NT exception handling that Microsoft only
  1992.  NK> shows to compiler vendors.
  1993.  
  1994.  NK> So I'm back to asking for help from Watcom. I'd like
  1995.  NK> to talk to whoever is "looking at" NT exception
  1996.  NK> handling, so I can tell them about our immediate needs
  1997.  NK> in this area.
  1998.  
  1999.  NK> What we need right now is a way to catch NT software
  2000.  NK> exceptions raised by system calls (especially the RPC
  2001.  NK> calls), and throw real C++ exceptions which correspond
  2002.  NK> to the NT exception code.
  2003.  
  2004.  NK> I can be reached at (407)262-8084, or on compuserve as
  2005.  NK> 76046,223, or via the Internet as
  2006.  NK> Ned_Konz%Conner_Software@mcimail.com
  2007.  
  2008.  NK> Thanks.
  2009.  
  2010. *** This is a reply to #1581.  *** See also #1914.
  2011.  
  2012.  
  2013. From:    Anthony Scian                          Rec'd
  2014. To:      Paul Tletski                           Msg #1657, Oct-07-93 10:37AM
  2015. Subject: Function Pointer Question...
  2016.  
  2017.  PT> I have a question concerning how to use int386 with 16 bit interrupt
  2018.  PT> handlers.  I have to interface Watcom 32-bit code with a DOS replacer
  2019.  PT> which provides an MS-DOS environment on top of a multitasking kernel.
  2020.  PT> Kernel functions are accessed through INT 2D with DL holding the
  2021.  PT> function code.
  2022.  
  2023. I think it is highly unlikely that the multitasking kernel can multitask 32-
  2024. bit functions without cooperating with DOS4G.  Does the multitasking kernel
  2025. handle 32-bit code already?  If not, I think you are in for a surprise when
  2026. the top half of your registers go away because I doubt the multitasker saves
  2027. 32-bit registers.  I think you'll have to get a 32-bit version of the
  2028. multitasker.  Unless the multitasker is extremely sophisticated and DPMI-
  2029. aware, a 16-bit version has very little chance of dealing with DOS4G 32-bit
  2030. code.
  2031.  
  2032. Anthony
  2033.  
  2034. *** This is a reply to #1655.  *** See also #1666.
  2035.  
  2036.  
  2037. From:    Anthony Scian                          Rec'd
  2038. To:      Arthur Jones                           Msg #1658, Oct-07-93 01:43PM
  2039. Subject: wmake nt and long filenames
  2040.  
  2041.  AJ> i'm having some problems with wmake in binnt, with short filenames
  2042.  AJ> it works find but it doesn't seem to make long filenames on a ntfs
  2043.  AJ> file system.  my makefile has both long and short filenames with
  2044.  AJ> equivalent dependencies, the short filenames work fine but the
  2045.  AJ> long filenames give an unable to make target error.  need i do
  2046.  AJ> something different?  it doesn't seem i should.  btw, case sensitivity
  2047.  AJ> seems to work.
  2048.  
  2049. I found the problem in make.  The NT make was compiled with a very early
  2050. version of the NT library header files that had DOS 8.3 path constants.  I've
  2051. recompiled the code with the correct constants so it should work with long
  2052. file names.  It will be in the B-level patches.
  2053.  
  2054. Anthony
  2055.  
  2056. *** This is a reply to #1629.
  2057.  
  2058.  
  2059. From:    Kevin Kitsemetry                       Rec'd
  2060. To:      Thomas B. Pollard                      Msg #1659, Oct-07-93 04:28PM
  2061. Subject: C/C++ 9.5A Wvideo interrup with <SyRq>
  2062.  
  2063.  TBP> I just added the A patches to C/C++ 9.5
  2064.  TBP> While I am running Wvideo and type -G- for go I no longer can press
  2065.  TBP> <Print Screen> to interupt the program from running.
  2066.  TBP> This happend even with the simplest programs running.
  2067.  TBP> (This id the DOS version of Wvideo.
  2068.  TBP> Sorry about the name I was trying to remember your name.
  2069.  
  2070. No problem, you got it right.  I have discussed this with the developer in
  2071. charge of WVIDEO, and he has told me that there is never any guarantee that
  2072. cntl-alt-sysrq will halt the debugger under DOS.  It may even cause (in rare
  2073. occations) the debugger to crash!
  2074.  
  2075.  
  2076. Kevin Kitsemetry
  2077. WATCOM TECHNICAL SUPPORT
  2078.  
  2079. *** This is a reply to #1648.  *** See also #1672.
  2080.  
  2081.  
  2082. From:    Kevin Kitsemetry                       Rec'd
  2083. To:      Kevin Ross                             Msg #1660, Oct-08-93 10:02AM
  2084. Subject: Floating point under Windows DOS box
  2085.  
  2086.  KK> You must make sure that you are running
  2087.  KK> wdebug.386 or wemu387.386 (you can
  2088.  KK> ditribute the second one) as a device driver,
  2089.  KK> specified in the system.ini
  2090.  KK> file, [386Enh] section.
  2091.  
  2092.  KR> I'd love to.  Could you tell me where I can find
  2093.  KR> either of these files?  They aren't included in my
  2094.  KR> Watcom C32 for DOS distribution.
  2095.  
  2096. I didn't realize that they did not come with C32 for DOS.
  2097. As it turns out, the floating point support under Windows
  2098. has changed, whereby it is no longer necessary to have
  2099. this device driver loaded.  However, the change will not
  2100. be incorporated before patch level B to the compiler.
  2101. I will make the file WEMU387.386 available in File Area 12,as a workaround
  2102. until then.
  2103.  
  2104.  
  2105. Kevin Kitsemetry
  2106. WATCOM TECHNICAL SUPPORT
  2107.  
  2108. *** This is a reply to #1649.
  2109.  
  2110.  
  2111. From:    Kevin Kitsemetry                       Rec'd
  2112. To:      Phil Duvalsaint                        Msg #1661, Oct-07-93 05:28PM
  2113. Subject: Targa Graphics Library
  2114.  
  2115.  PD> The problem seems to be that the functions in the Targa Graphics kit
  2116.  PD> are ignored.  The compiler compiles but the linker still can't
  2117.  PD> find several function definitions. I've had to fudge the original library
  2118.  PD> sources to get them to compile. (Mostly problems with register names
  2119.  PD> like changing AX to AEX or something (since Microsoft used 16 bit
  2120.  PD> register names and Watcom uses the 32 bit names)) I believe that the
  2121.  PD> problem has something to do with building the library. There has to be
  2122.  PD> an easier way. I seem to have run into several
  2123.  PD> problems with converting Microsoft C code to Watcom.
  2124.  PD> Mostly associated with finding the right library.
  2125.  
  2126. If you have compiled the source as you say, you can check the symbols by using
  2127. wlib on the library.  You can check the map file generated by the linker to
  2128. try and determine why it can't find the symbols.
  2129.  
  2130.  
  2131. Kevin Kitsemetry
  2132. WATCOM TECHNICAL SUPPORT
  2133.  
  2134. *** This is a reply to #1653.
  2135.  
  2136.  
  2137. From:    Kevin Kitsemetry                       Rec'd
  2138. To:      Christer Palm                          Msg #1662, Oct-07-93 05:33PM
  2139. Subject: Technical support
  2140.  
  2141.  CP> Are you guys just reading the last 3 messages every Friday or so ???
  2142.  CP> I can't say that I'm happy with the Technical Support turnaround times !
  2143.  CP> Sometimes problem reports doesn't get answered at all !!
  2144.  
  2145.  CP> Could you PLEEEASE take a look a msg #1623 & 1527 ??
  2146.  
  2147. It looks as though you have been dealing with Mark Delafranier.  I have
  2148. notified him of these messages.
  2149.  
  2150.  
  2151. Kevin Kitsemetry
  2152. WATCOM TECHNICAL SUPPORT
  2153.  
  2154. *** This is a reply to #1654.  *** See also #1722.
  2155.  
  2156.  
  2157. From:    Kevin Blenkinsopp
  2158. To:      All                                    Msg #1663, Oct-07-93 05:48PM
  2159. Subject: Exception Handling Timings
  2160.  
  2161. Just in case anyone's interested, I did some timing tests on exception
  2162. handling today, spurred on by something I read in the C++ Report. What I came
  2163. up with was this:
  2164.  
  2165.                         Trying          Throwing
  2166. Compiler/Loops  Normal  (x slower)      (x slower)
  2167. WPPx100,000     0.28    0.72 (2.57)     3.43 (12.25)
  2168. WPPx10,000,000  17.61   62.12 (3.52)    332.48 (18.88)
  2169. DECx10,000,000  0.9     3.2 (3.55)      c2400 (2666)
  2170.  
  2171. The timings for the DEC compiler are from Oct 93 C++ Report and are intended
  2172. only give a rough feel ... not scientific testing ... not DEC approved ...
  2173. don't sue me, etc.
  2174.  
  2175. For those of you who don't know WHY exceptions take so much longer, the
  2176. general approach (as I understand it) is that the compiler saves a bit of
  2177. extra information if you're doing something inside a try block, which it then
  2178. uses to help it unroll the stack (when the exception is thrown) and destroy
  2179. all the objects created inside the try block before it goes to the catch block.
  2180.  
  2181. Lest anybody get the wrong impression, I'm absolutely NOT slagging Watcom off
  2182. for the performance issues involved. Their implementation seems to be pretty
  2183. damn good by comparison - that last number in the table for DEC isn't a typo.
  2184.  
  2185. The moral of this story (and the point made in the article) is this:
  2186. Exceptions are for exceptional cases, not general purpose error handling. If
  2187. you want a constructor to fail cleanly, for example, exceptions are by far the
  2188. best way to handle it.
  2189. The two-and-a-half to three-and-a-half times increases that come with wrapping
  2190. code in try blocks are pretty easy to tolerate (especially given that we're
  2191. seeing two-and-a-half to five times increases in performance on our code now
  2192. that we've switched compilers) since you get much more understandable code for
  2193. it, but if exceptions get thrown too often you could be in for quite a hit.
  2194.  
  2195. Don't let me (or anybody else) scare you off exceptions. They're staggeringly
  2196. useful in places. Like everything else in this industry,it's a judgement call.
  2197.  
  2198.  
  2199. From:    David Zechiel                          Rec'd
  2200. To:      Kevin Kitsemetry                       Msg #1664, Oct-07-93 06:49PM
  2201. Subject: __InitRtns
  2202.  
  2203.   I applied all of the 'A' patches to my 9.5 compiler and then recompiled and
  2204. relinked everything.  When I try to run it nothing happens.  I traced the code
  2205. and watched it call a module called "__InitRtns" and then it exited in a
  2206. routine called "exit_with_message" or somthing close to that. I am at a loss
  2207. to explain this, can you tell me what would cause "__InitRtns" to fail and
  2208. what it is supposed to be doing?
  2209.  
  2210.   Dave Zechiel
  2211.  
  2212. *** See also #1669.
  2213.  
  2214.  
  2215. From:    Brian Schriber
  2216. To:      Anyone                                 Msg #1665, Oct-07-93 10:27PM
  2217. Subject: Wvideo Display problem
  2218.  
  2219. Help.
  2220.  
  2221. I have a problem that is something akin to a problem someone had before. What
  2222. is going on is that I am trying to debug a program and the machine seems to
  2223. lock up with a blank display. However, Wvideo IS running. If i tell it to GO
  2224. the system runs the application fine including its display, keyboard, mouse.
  2225. And when it exits it goes back to this black screen. The only thing I can see
  2226. is an underline cursor in the top left. So whats the problem? This same
  2227. program debugs fine on the 386 machine I just got off. The machine is a 486.
  2228. Now I have had problems using wvideo on another 486 we have in the office, but
  2229. the problem I am having now is just wierd. I really would appreciate any
  2230. assitance that could be provided. All in all I (and judging from the msgs here
  2231. I'm in the minority) am not totally displeased with the environment.
  2232.  
  2233. I am also having a problem breaking a running program and then restarting it
  2234. by using the <ctrl-break/print-scr> key. Although I get the debugger fine I
  2235. cannot get the program to continue. I will be getting the A level patches
  2236. after this But just in case that doesn't fix the problem (or I can't get the
  2237. download to complete before being dropped) I would still appreciate any info.
  2238.  
  2239. Brian Schriber
  2240. PDS Developement Corp
  2241. Raleigh, NC
  2242.  
  2243. WATCOM's Techinfo Utility, Version 1.3
  2244. Current Time: Thu Oct  7 13:59:16 1993WATCOM
  2245. Phone: (519) 884-0702
  2246. 415 Phillip St.                         Fax: (519) 747-4971
  2247. Waterloo, Ontario
  2248. CANADA    N2L 3X2
  2249.  
  2250. ------------------WATCOM C Environment Variables ----------------
  2251. WATCOM=<G:\WC\.>
  2252. INCLUDE=<G:\WC\H;G:\WC\H\WIN>
  2253. PATH=<Z:.;Y:.;C:\;C:\DOS;C:\NET386;C:\PATHWAY;G:\WC\BIN;G:\WC\BINB;G:\ADEPT;G:\
  2254. TT;H:\PP2\BIN;H:\UTILS;G:\SS>
  2255. File 'G:\WC\.\bin\wcc386.exe' has not been patched
  2256. File 'G:\WC\.\binnt\wcc386.exe' has not been patched
  2257. File 'G:\WC\.\bin\wvideo.exe' has not been patched
  2258. File 'G:\WC\.\binw\wvideo.exe' has not been patched
  2259. File 'G:\WC\.\binnt\wvideo.exe' has not been patched
  2260. File 'G:\WC\.\bin\wlink.exe' has not been patched
  2261. File 'G:\WC\.\binnt\wlink.exe' has not been patched
  2262. File 'G:\WC\.\binb\wlib.exe' has not been patched
  2263. File 'G:\WC\.\binnt\wlib.exe' has not been patched
  2264. ------------------WATCOM SQL Environment Variables ----------------
  2265. ... ERROR...WSQL environment variable not set.
  2266. Amount of extended memory is: 0K
  2267. Amount of base memory is: 640K
  2268. Amount of free base memory is: 521264 bytes
  2269. DOS Version 5.0
  2270. ------------C:\CONFIG.SYS-------------
  2271. break=on
  2272. FILES=80rem lastdrive=E
  2273. rem device=c:\386max\386max.sys
  2274. device=c:\dos\ansi.sys
  2275. device=c:\dos\himem.sys
  2276. dos=high
  2277. rem device=c:\dos\smartdrv.sys 4096
  2278. SHELL=C:\DOS\COMMAND.COM c:\dos\ /P /E:768
  2279. rem device=c:\pathway\pwtcp.sys
  2280. ------------C:\AUTOEXEC.BAT-------------
  2281. @ECHO off
  2282. PROMPT $p$g
  2283. PATH=C:\;C:\DOS;C:\Net386;C:\Pathway
  2284. rem *** setup on network ***
  2285. SET ADEPT=g:\ADEPT
  2286. SET PDSOPEN=G:\OPEN\OPENFILE
  2287. set tmp=g:\
  2288. rem *** start up the network ***
  2289. CALL stnw
  2290. rem *** setup for the watcom compiler ***
  2291. CALL wcset
  2292. rem *** setup Dr. Taylor's Test after network up ***
  2293. PATH %PATH%;G:\DTT
  2294. rem *** final setup requiring network be up ***
  2295. PATH %PATH%;H:\PP2\BIN;H:\UTILS;G:\SS
  2296. set pp2=g:\pp2
  2297. capture Au
  2298. rem *** go to start directory ***
  2299. cd \open
  2300. mouse
  2301. ------------------------------------------------
  2302. An Intel 486 processor is installed in this system.
  2303. 486 math coprocessor is present
  2304.         and Equipment Flags say math coprocessor IS present.
  2305. The next test may cause the system to hang if 486
  2306.         interruptsare not handled properly.
  2307. 486 interrupts are properly enabled.
  2308. ------------------------------------------------
  2309. APPEND                  NOT INSTALLED
  2310.  
  2311. *** See also #1670.
  2312.  
  2313.  
  2314. From:    Paul Tletski                           Rec'd
  2315. To:      Anthony Scian                          Msg #1666, Oct-08-93 07:14AM
  2316. Subject: Function Pointer Question...
  2317.  
  2318. Anthony,
  2319.  
  2320. After a little thought and poking around at the DPMI, I think I can do what I
  2321. mentioned in my last note.  The key is to have DPMI issue a Real-Mode to
  2322. Protected-Mode callback.  This is DPMI function 0x0303.  DOS4GW doesn't
  2323. support this function, and neither does their DOS4G offering.  I'll probably
  2324. have to get a hold of Phar Lap (TNT perhaps - is Watcom compatible with TNT?)
  2325. or some other extender (Ergo may do as well) which supports the full DPMI.
  2326. There is also an article in DDJ 2/92 about mixing real & protected mode code.
  2327. I'll let you know what I find.
  2328.  
  2329. Thanks.
  2330.  
  2331. Paul Tletski
  2332. Highland Hts., OH
  2333.  
  2334. *** This is a reply to #1657.  *** See also #1667.
  2335.  
  2336.  
  2337. From:    Dan Teven                              Rec'd
  2338. To:      Paul Tletski                           Msg #1667, Oct-08-93 09:52AM
  2339. Subject: Function Pointer Question...
  2340.  
  2341. DOS/4G _does_ support the real-mode callback functions, int 31h
  2342. functions 303h and 304h.
  2343.  
  2344. Dan Teven
  2345. Rational Systems, Inc.
  2346.  
  2347. *** This is a reply to #1666.
  2348.  
  2349.  
  2350. From:    Dave Heyliger
  2351. To:      Tech Support                           Msg #1668, Oct-08-93 10:28AM
  2352. Subject: _dos_getvect / _dos_setvect, 32-bit Windows
  2353.  
  2354.         Creating a 32-bit Windows app w/ C 9.5, and I am having trouble w/
  2355. _dos_setvect.
  2356.  
  2357.         It looks as if you call _dos_getvect and then use the same _interrupt
  2358. _far * pointer and call _dos_setvect, the code works fine. However, using a
  2359. different _interrupt _far * pointer causes incorrect setting of the vector. I
  2360. have confirmed this by tracing via VIDEO the entire assembly code chain.
  2361.  
  2362.         My question: do you have to perform any special MK_FP16() or ???
  2363. function before passing the interrupt vector to _dos_setvect?
  2364.  
  2365.         If you need to see the asm trace listing, let me know.
  2366.  
  2367.                                                         Thanks, Dave Heyliger
  2368.  
  2369. *** See also #1700.
  2370.  
  2371.  
  2372. From:    Kevin Kitsemetry
  2373. To:      David Zechiel                          Msg #1669, Oct-08-93 03:42PM
  2374. Subject: __InitRtns
  2375.  
  2376.  DZ>   I applied all of the 'A' patches to my 9.5 compiler
  2377.  DZ> and then recompiled and relinked everything.  When I
  2378.  DZ> try to run it nothing happens.  I traced the code and
  2379.  DZ> watched it call a module called "__InitRtns" and then
  2380.  DZ> it exited in a routine called "exit_with_message" or
  2381.  DZ> somthing close to that. I am at a loss to explain
  2382.  DZ> this, can you tell me what would cause "__InitRtns" to
  2383.  DZ> fail and what it is supposed to be doing?
  2384.  
  2385. I don't know off hand what would cause that, especially (I
  2386. assume) it worked before you applied the patches.  Did the
  2387. patches apply properly (no errors), and have you verified
  2388. them by running the techinfo.exe utility?
  2389.  
  2390. Next, tell me more about your application that you are trying to build.  What
  2391. platform are you targeting?  What language are you writing it in (C or C++)?
  2392. Can you provide an example,
  2393. or at least a mapfile for us to look at?
  2394.  
  2395.  
  2396. Kevin Kitsemetry
  2397. WATCOM TECHNICAL SUPPORT
  2398.  
  2399. *** This is a reply to #1664.
  2400.  
  2401.  
  2402. From:    Kevin Kitsemetry                       Rec'd
  2403. To:      Brian Schriber                         Msg #1670, Oct-08-93 01:04PM
  2404. Subject: Wvideo Display problem
  2405.  
  2406.  BS> Help.
  2407.  
  2408.  BS> I have a problem that is something akin to a problem someone had before.
  2409.  BS> What is going on is that I am trying to debug a
  2410.  BS> program and the machine seems to lock up with a blank
  2411.  BS> display. However, Wvideo IS running. If i tell it to
  2412.  BS> GO the system runs the application fine including its
  2413.  BS> display, keyboard, mouse. And when it exits it goes
  2414.  BS> back to this black screen. The only thing I can see is
  2415.  BS> an underline cursor in the top left. So whats the
  2416.  BS> problem? This same program debugs fine on the 386
  2417.  BS> machine I just got off. The machine is a 486. Now I
  2418.  BS> have had problems using wvideo on another 486 we have
  2419.  BS> in the office, but the problem I am having now is just
  2420.  BS> wierd. I really would appreciate any assitance that
  2421.  BS> could be provided. All in all I (and judging from the
  2422.  
  2423. It sounds like WVIDEO thinks that there is a second monitor on the machine.
  2424. Try specifying the /SWAP option when you
  2425. invoke wvideo.
  2426.  
  2427.  
  2428.  BS> I am also having a problem breaking a running program and then
  2429.  BS> restarting it by using the <ctrl-break/print-scr> key.
  2430.  BS> Although I get the debugger fine I cannot get the
  2431.  BS> program to continue. I will be getting the A level
  2432.  BS> patches after this But just in case that doesn't fix
  2433.  BS> the problem (or I can't get the download to complete
  2434.  BS> before being dropped) I would still appreciate any
  2435.  BS> info.
  2436.  
  2437. If you are trying to do this in DOS, then this is not a surprise. I have just
  2438. recently talked to the developers in charge of the debugger and they told me
  2439. that this is never guaranteed to work under DOS.  Did you try specifying the
  2440. new command, followed by 'go main'?
  2441.  
  2442.  
  2443. Kevin Kitsemetry
  2444. WATCOM TECHNICAL SUPPORT
  2445.  
  2446. *** This is a reply to #1665.  *** See also #1675.
  2447.  
  2448.  
  2449. From:    Tom Ohlin                              Rec'd
  2450. To:      Kevin Kitsemetry                       Msg #1671, Oct-08-93 03:44PM
  2451. Subject: 9.5 A patch
  2452.  
  2453. KK> Mark Delafranier dealt with customer on e-mail and phone.
  2454.  
  2455.  
  2456. The A patches have caused an error with fread() when the string being read
  2457. crosses a segment boundry?
  2458.  
  2459. I have a file with several hundred ascii strings - all of known length. When I
  2460. fread() each one with fread(buff,1,count,stream) all come in fine except when
  2461. the string spans the 0x1000 char in the file. Buff gets loaded with the
  2462. beginning of the string upto address 0xfff of the file. The return value from
  2463. fread() reflects accurately the number read, but feof() or ferror() do not
  2464. show an error.
  2465.  
  2466. Recompiling with the pre A patch version does not show any problems.
  2467.  
  2468. Also minor problem with \watcom\binw\wvideo. When I quit from wvideo at the
  2469. DBG> prompt the mono & vga screens both clear and nothing appears to be
  2470. happening with two blank screens. a cntl/alt/del awakens windows with its
  2471. warning prompt about doing this however the "press any key" senario repaints
  2472. the windows screen and everything returns to normal.
  2473.  
  2474. Hope there is a workaround for the fread() problem.
  2475.  
  2476. Tom Ohlin
  2477.  
  2478.  
  2479. From:    Thomas B. Pollard                      Rec'd
  2480. To:      Kevin Kitsemetry                       Msg #1672, Oct-09-93 10:49AM
  2481. Subject: C/C++ 9.5A Wvideo interrup with <SyRq>
  2482.  
  2483. OK about the <ctrl SysRq> but the Print Screen always worked before.
  2484. Last night I compleatly reinstalled 9.5 on my 386 computer at home and then
  2485. applied the A patches.  While I was in the Wvideo I pressed
  2486. <Print Screen>(with a program loaded but not running) and I got a stack over
  2487. flow and a the computer locked up.
  2488. --- Is there any other way to interrup Wvideo ?
  2489. Thanks.
  2490.  
  2491. *** This is a reply to #1659.  *** See also #1701.
  2492.  
  2493.  
  2494. From:    Jason Blochowiak                       Rec'd
  2495. To:      Kevin Kitsemetry                       Msg #1673, Oct-09-93 12:01PM
  2496. Subject: Breaking into a program that steals the keyboard
  2497.  
  2498.  Hi. I'm working on a program that completely takes over the keyboard vector
  2499. (#9). It's nice that the current version (I have the 9.5a C++ package) of
  2500. WVIDEO regains control of the keyboard when a pre-set breakpoint is hit.
  2501. However, it seems I can't break into the program with the keyboard. This is
  2502. definitely feasible (TD386 does it) - is this currently possible with WVIDEO?
  2503.  
  2504.  Jason
  2505.  
  2506. *** See also #1702.
  2507.  
  2508.  
  2509. From:    Stephen Baum
  2510. To:      All                                    Msg #1674, Oct-10-93 01:23PM
  2511. Subject: DOS4GW, VM, and OS/2
  2512.  
  2513. I have a DOS application which uses virtual memory and DOS4GW. I also have a
  2514. few customers attempting to run it in a DOS compatibility box under OS/2. It
  2515. frequently works, but tends to crash at odd times and in odd ways. One of the
  2516. more controlled crashes indicates a malloc() failure, in a circumstance that
  2517. does not fail under DOS.
  2518.  
  2519. I have a suspicion that the DOS4GW virtual memory functions erratically under
  2520. OS/2, but attempts to run without it by removing the DOS4GVM setting have not
  2521. succeeded either. I base this suspicion in part on the fact that VM seems to
  2522. screw up when the swap file is run on a compressed disk with standard DOS,
  2523. leading me to believe that swap file access does not conform to standard DOS
  2524. I/O procedures for speed reasons.
  2525.  
  2526. Any ideas as to how to get this stuff to work under OS/2?
  2527.  
  2528. Thanks, Stephen Baum
  2529.  
  2530. *** See also #1683.
  2531.  
  2532.  
  2533. From:    Brian Schriber                         Rec'd
  2534. To:      Kevin Kitsemetry                       Msg #1675, Oct-10-93 05:43PM
  2535. Subject: Wvideo Display problem
  2536.  
  2537.  BS> I am also having a problem breaking a running program and then
  2538.  BS> restarting it by using the <ctrl-break/print-scr> key.
  2539.  BS> Although I get the debugger fine I cannot get the
  2540.  BS> program to continue. I will be getting the A level
  2541.  
  2542.  KK> If you are trying to do this in DOS, then this is not a
  2543.  KK> surprise. I have just recently talked to the developers
  2544.  KK> in charge of the debugger and they told me that this is
  2545.  KK> never guaranteed to work under DOS.  Did you try
  2546.  KK> specifying the new command, followed by 'go main'?
  2547.  
  2548.  KK> Kevin Kitsemetry
  2549.  KK> WATCOM TECHNICAL SUPPORT
  2550.  
  2551. Well, I'm not trying to setup a new command (I presume you mean by setting up
  2552. new command line arguments). I will do an examine on memory, or a variable, or
  2553. set a new breakpoint. I then want the program to continue execution from where
  2554. I stopped it. I have not had a problem restarting the program, just getting it
  2555. to continue. I have tried the /SWAP option on that 486. Thanx, I don't know
  2556. why it thinks there is another monitor, but now that I can debug on the
  2557. machine I am much happier. If you could let me know about using the break key
  2558. on a program and continuation being not supported from the point at which the
  2559. User Interrupt occurs I would be appreciative.
  2560.  
  2561. Brian Schriber
  2562. PDS Developement Corp.
  2563. Raleigh, NC
  2564.  
  2565. *** This is a reply to #1670.  *** See also #1703.
  2566.  
  2567.  
  2568. From:    Solaroli Matteo
  2569. To:      Kevin Kitsemetry                       Msg #1679, Oct-11-93 08:07AM
  2570. Subject: replay to 1401
  2571.  
  2572. The program received from you (mess. #1401) doesn't run correctly.
  2573. The function call 800h of the DPMI is not supported because returns with the
  2574. carry flag set.
  2575. I'm using the subset of Rational Systems' DOS/4G provided with the WATCOM C/386
  2576. package (DOS/4GW), under MS-DOS.
  2577. Is it necessary to run the program under Windows to avoid the function call
  2578. 800h ?
  2579. Does the complete version of DOS/4G extender support this function call of
  2580. DPMI with MS-DOS ?
  2581.  
  2582. Another problem :
  2583. Is possible to use the interrupt handler 0xF (Irq7) only. Using another
  2584. interrupt the program faults with the message error :
  2585. Unexpected interrupt 0D (code 304c60) at 70:52F1
  2586. TSF32: prev_tsf32 4C60
  2587.  
  2588.  
  2589. Please answer us soon as possible.
  2590. I am looking forward to ear from you.
  2591.  
  2592.  
  2593. From:    Nigel Evans                            Rec'd
  2594. To:      Dan Cummins                            Msg #1681, Oct-11-93 10:17AM
  2595. Subject: DPMI and Interrupts using WATCOM C/386 v9.01
  2596.  
  2597. I need to write an ISR to handle DOS int 24 (critical error handler), using
  2598. the DOS4GW option within WATCOM C/386 v9.01.
  2599. However, I get a page fault when trying to use the standard sprintf() calls
  2600. within the handler. I believe the problem is most likely caused by stack
  2601. switching. Using assembler to save and restore the stack (I guess I could do
  2602. this with the pragma directive) doesn't give a page fault ... It just stuffs
  2603. my environment and probably a lot of other undesirable effects
  2604.  
  2605. Heres some sample code:
  2606.  
  2607. #include <stdio.h>
  2608. #include <sys\stat.h>
  2609. #include <dos.h>
  2610.  
  2611. char scr[2000] ;
  2612. extern mysprintf() ;
  2613.  
  2614. #define ABORT   2
  2615. #define RETRY   1
  2616. #define IGNORE  0
  2617.  
  2618. union REGS inregs, outregs ;
  2619. struct SREGS segregs ;
  2620. static int retrycount = 0 ;
  2621. #define MAXAUTORETRY    5
  2622.  
  2623. #define  SCREENROWS  25
  2624. #define  SCREENCOLS  80
  2625.  
  2626. static int  scrrow, scrcol ;
  2627. static char *STARTPOS ;
  2628. static char *scrpos ;
  2629. static int curatt ;
  2630.  
  2631. void scrinit()
  2632. {
  2633.   STARTPOS = (char *)((0xB800) << 4) ;
  2634.   scrrow = 0 ; scrcol = 0 ;   /* Top LH corner */
  2635.   scrpos = STARTPOS ;
  2636.   curatt = 0x07 ;
  2637. }
  2638.  
  2639. int keycode ()
  2640. {
  2641.   int c ;
  2642.  
  2643.   if ((c=bdos(8,0,0) & 0xFF) >= ' ')                    /* Microsoft & Lattice
  2644. C only */
  2645.     return (c) ;
  2646.   }
  2647.  
  2648. void putscr()
  2649. /*=========*/
  2650. {  char *s ;
  2651.  
  2652.   s = scr ;
  2653.   while (*s) {
  2654.     if (*s == '\n') {
  2655.       if (++scrrow > SCREENROWS) scrrow = SCREENROWS - 1 ;
  2656.       scrpos = STARTPOS + scrrow * 160 ;  scrcol = 0 ;
  2657.       s++ ;
  2658.       }
  2659.     else {
  2660.       *scrpos++ = *s++ ;
  2661.       *scrpos++ = curatt ;
  2662.       if (++scrcol >= SCREENCOLS) {
  2663.         if (++scrrow > SCREENROWS) scrrow = SCREENROWS - 1 ;
  2664.         scrpos = STARTPOS + scrrow * 160 ;  scrcol = 0 ;
  2665.         }
  2666.       }
  2667.     }
  2668. }
  2669.  
  2670. int action(flag, code, dev)
  2671. /*=======================*/
  2672. int flag ;
  2673. char code ;
  2674. char *dev ;
  2675. {
  2676.   char msg[100] ;
  2677.   char name[20] ;
  2678.   int i ;
  2679.   static char *errname[13] = {
  2680.     "Write Protected",
  2681.     "Unknown Unit",
  2682.     "Not Ready",
  2683.     "Unknown Command",
  2684.     "Data Error (CRC)",
  2685.     "Bad Request Structure Length",
  2686.     "Seek Error",
  2687.     "Unknown Media Type",
  2688.     "Sector Not Found",
  2689.     "Printer Out Of Paper",
  2690.     "Write Fault",
  2691.     "Read Fault",
  2692.     "General Failure" } ;
  2693.   static int aborted = 0 ;
  2694.  
  2695.   if (flag>=0) {
  2696.      sprintf(msg, "Drive %c:  %s - Abort or Retry",
  2697.         *(char *)(&flag)+'A', errname[code]) ;
  2698.     }
  2699.   else if (aborted) {
  2700. /* can't procede without recursion so fail    */
  2701. /* should flushing buffers in exit() anyway.  */
  2702.     _exit(3) ;
  2703.     }
  2704.   else {
  2705.     for (i=0 ; i<8 ; ++i) {
  2706.      if (dev[i+10] == ' ') break ;
  2707.       name[i] = dev[i+10] ;
  2708.       }
  2709.     name[i] = '\0' ;
  2710.     sprintf(msg, "Device %s:  %s - Abort, Retry or Ignore",
  2711.         name, errname[code]) ;
  2712.     }
  2713.   putscr() ;
  2714.   if (retrycount++ <= MAXAUTORETRY)
  2715.     return RETRY ;
  2716.   else {
  2717.     retrycount = 0 ;
  2718.     for ( ;;)
  2719.       switch (keycode()) {
  2720.         case 'a':
  2721.           aborted = 1 ;
  2722.           return ABORT ;
  2723.           break ;
  2724.         case 'r':
  2725.           return RETRY ;
  2726.         case 'i':
  2727.           if (flag<0) {
  2728.             return IGNORE ;
  2729.             }
  2730.           break ;
  2731.         }
  2732.     }
  2733.  }
  2734.  
  2735.  
  2736. int __interrupt handler (regs)
  2737. /*==========================*/
  2738. union INTPACK regs ;
  2739. {
  2740.    int flag = (int)regs.h.ah ;
  2741.    char code= (int)regs.w.di ;
  2742.    char *dev= (int)regs.x.ebx = FP_OFF(regs.w.sp) + FP_SEG(regs.w.bp) ;
  2743.  
  2744.    return(action(flag, code, dev)) ;
  2745. }
  2746.  
  2747. main()
  2748. {
  2749.  
  2750.    unsigned int CS ;
  2751.    unsigned int EIP ;
  2752.    void far *fp ;
  2753.    void *lowp ;
  2754.  
  2755.    scrinit() ;
  2756.    inregs.x.eax = 0x3524 ;
  2757.    segregs.ds = segregs.es = 0 ;
  2758.    int386x(0x21, &inregs, &outregs, &segregs) ;
  2759.    sprintf(scr,"Old Handler at CS:EIP %02X:%04X\n", CS=(unsigned
  2760. int)segregs.es, EIP=outregs.x.edx) ;
  2761.    putscr() ;
  2762.  
  2763.    fp = (void far *) handler ;
  2764.    inregs.x.eax = 0x2524 ;
  2765.    inregs.x.edx = FP_OFF(fp) ;
  2766.    segregs.ds = FP_SEG(fp) ;
  2767.    segregs.es = 0 ;
  2768.    int386x(0x21, &inregs, &outregs, &segregs) ;
  2769.    sprintf(scr,"New Handler at CS:EIP %02X:%04X", inregs.w.cx, inregs.x.edx) ;
  2770.    putscr() ;
  2771.  
  2772.    creat("a:\file", S_IREAD | S_IWRITE) ;
  2773.  
  2774.    inregs.w.ax = 0x2524 ;
  2775.    inregs.x.edx = EIP ;
  2776.    segregs.ds = CS ;
  2777.    segregs.es = 0 ;
  2778.   int386x(0x21, &inregs, &outregs, &segregs) ;
  2779.  
  2780. }
  2781.  
  2782.  
  2783. *** See also #1889.
  2784.  
  2785.  
  2786. From:    Gordo Lang
  2787. To:      Kevin Kitsemetry                       Msg #1682, Oct-11-93 10:56AM
  2788. Subject: Mangled names and Assembler
  2789.  
  2790. I am trying to implement some class method()s in assembler (using
  2791. Borland's TASM to be precise).  These are rather large routines which
  2792. cannot be satisfactorily implemented using the #pragma aux scheme.  Is
  2793. there a way to change the name-mangling scheme so that it does NOT use
  2794. characters like "?():" ?  There is no way TASM (or any other x86
  2795. assembler) can produce a subroutine label like "W?foo(ul):qv" since it
  2796. contains key characters.  I really don't want to convert all my class
  2797. methods into their equivalent "C" routines just to get around this, and
  2798. I don't want to write an OBJ label translater.  Is there a way out of
  2799. this? HELP.
  2800.  
  2801. Thanks in advance, Gordon.
  2802.  
  2803. *** See also #1711.
  2804.  
  2805.  
  2806. From:    Dan Teven                              Rec'd
  2807. To:      Stephen Baum                           Msg #1683, Oct-11-93 08:17PM
  2808. Subject: DOS4GW, VM, and OS/2
  2809.  
  2810. The DOS/4GW virtual memory manager doesn't run under OS/2; OS/2
  2811. provides the virtual memory services.
  2812.  
  2813. *** This is a reply to #1674.
  2814.  
  2815.  
  2816. From:    Chandra Chandrasekar
  2817. To:      All                                    Msg #1685, Oct-11-93 09:56PM
  2818. Subject: 32 bit to 16 bit DLL data transfer
  2819.  
  2820. Dear Beloved 32 bit developers,
  2821.  
  2822. We are currently building an application where a 32 bit DLL and
  2823. a 16 bit DLL must co-exist.  Our problem is transfering data
  2824. between functions in 16 bit DLL to 32 bit DLL and vice-versa.
  2825. We are developing the 32-bit DLL in watcom 32 bit compiler and the 16-bit DLL
  2826. with the Microsoft Visual C++ compiler.
  2827.   We would very much appreciate answers to the following questions:
  2828. 1) how do I call a function in 32 bit DLL in 16 bit DLL?
  2829. 2) What data transfer mechanism should we use?  DDE?  How do
  2830. we recognize the data formats?
  2831. 3) I have a huge class object on the 32-bit side and I want to pass the
  2832. object to the 16 bit on demand or as a return value. How do I do ito
  2833. 3) Is this possible?  Has anyone done this before?
  2834.  
  2835. please e-mail to the following address or post it on BBS and i will take it
  2836. from there.
  2837. My e-mail address is
  2838. chandra@strategy.com
  2839.  
  2840. thanks a million.
  2841. -chandra & sundar
  2842.  
  2843.  
  2844. From:    Kevin Kitsemetry                       Rec'd
  2845. To:      Edward Palandri                        Msg #1689, Oct-12-93 10:27AM
  2846. Subject: Problems with accessing an OS/2 16 bit DLL from Watcom C/386
  2847.  
  2848. KK> Internal Report #6526
  2849.  
  2850.  
  2851.  EP> I am using Watcom C/386 v9.0 patch level E and I am
  2852.  EP> trying to build an OS2 2.1 program which will call a
  2853.  EP> 16 bit DLL which is provided by another vendor.
  2854.  
  2855.  EP> The DLL is OK as we have successfully used it with an
  2856.  EP> OS/2 16 bit front end program but when I attempt to
  2857.  EP> call it from a 32 bit front end I get the following
  2858.  EP> messages from OS/2
  2859.  
  2860.  EP> SYS2070 The system could not demand load the
  2861.  EP> application's segment. OS2SKWAT->SDLL.DLL is in error.
  2862.  EP> For further information type HELP SYS127.
  2863.  
  2864.  EP> and HELP SYS127 produces:
  2865.  
  2866.  EP> SYS0127: The specified procedure could not be found.
  2867.  
  2868.  EP> EXPLANATION: The specified procedure is not in the module
  2869.  EP> being searched or in the Exitlist routine list.
  2870.  EP> ACTION: Check which procedure is being requested and make
  2871.  EP> sure that it is in the module or Exitlist routine list.
  2872.  
  2873.  EP> I have, I believe followed the instructions for
  2874.  EP> calling 16 bit DLL's but have had no success in getting it to work.
  2875.  
  2876.  EP> SDLL.DLL is in a directory on the LIBPATH
  2877.  
  2878.  EP> I have uploaded a file OS2SKWAT.ZIP to the BBS which
  2879.  EP> contains the following pieces:
  2880.  
  2881.  EP> OS2SKWAT.C      C code of the 32 front end which calls
  2882.  EP> the DLL OS2SKWAT.EXE    Excecutable produced by the
  2883.  EP> BAT file
  2884.  EP> OS2SKWAT.OBJ    Object module produced by the BAT file
  2885.  EP> OS2SKWAT.MAP    Link map
  2886.  EP> OS2SK.EXE       A 16 bit OS/2 executable that calls
  2887.  EP> the same DLL SDLL.DLL        The DLL in question
  2888.  EP> MKOS2SKW.BAT    A DOS bat file for compiling and
  2889.  EP> linking OS2SKWAT README.TXT      This fil
  2890.  
  2891.  EP> OS2SKWAT calls an entry point OS2SCRIB in SDLL.DLL
  2892.  EP> (with no trailing_). Note that when the program
  2893.  EP> actually executes it requires a driver which you do
  2894.  EP> not have, but the program does not load and never gets
  2895.  EP> to any stage of execution.
  2896.  
  2897. I was not able to reproduce this exactly as you described.
  2898. The file you sent to us did NOT include SDLL.DLL.  The
  2899. program complained that it could not find this DLL with
  2900. version 9.01e and 9.5a.
  2901.  
  2902. Having said that, we have come accross something similar
  2903. in the past, whereby the OS/2 loader was not returning the
  2904. correct segment-offset value for the 16-bit DLL at run-time. We changed the
  2905. way we implimented the call for version 9.5
  2906. (by asking for the 32-bit flat address instead of converting it ourselves).
  2907. This solved the problem, and hence it is
  2908. possible that your program would work with version 9.5.
  2909.  
  2910.  
  2911. Kevin Kitsemetry
  2912. WATCOM TECHNICAL SUPPORT
  2913.  
  2914. *** This is a reply to #1587.  *** See also #1695.
  2915.  
  2916.  
  2917. From:    Gordo Lang                             Rec'd
  2918. To:      Kevin Kitsemetry                       Msg #1691, Oct-12-93 11:42AM
  2919. Subject: C++32 -zc, #pragma #problems, extern "C" problems
  2920.  
  2921. I am progamming in C++32 and am having difficulty with a few "features".
  2922. I suspect that the "-zc" option (put const literals in _TEXT segment)
  2923. does not work in C++ using any memory model.  Is this true ?
  2924. I cannot get the "#pragma DATA_SEG" example on page 154 of the UG to
  2925. emit data into anything other than _DATA or _BSS.  Is this feature
  2926. being ignored in the C++ version of the compiler?
  2927. I believe the following constructs should be the same:
  2928. extern "C" {
  2929. int  x;
  2930. int y;
  2931. };
  2932. and ..
  2933. extern "C" int x;
  2934. extern "C" int y;
  2935. but the compiler produces different OMF records for these two cases.
  2936. The former construct produces linker complaints about duplication of
  2937. symbols.  Who is wrong here? Compiler, Linker, or Programmer?
  2938. I'm in the process of writing a de-mangler/re-mangler program to convert
  2939. the W?Mangled$:Name(s) into symbols more acceptable to an Assembler
  2940. (TASM); is the WATCOM C++32 mangling rules available?  I looked in the
  2941. manuals but couldn't find anything about mangling, is this a secret ?
  2942. Other than these teeny, weeny complaints I think the C++ is great!
  2943. Thanks in advance, Gordon.
  2944.  
  2945. *** See also #1694.
  2946.  
  2947.  
  2948. From:    Anthony Scian                          Rec'd
  2949. To:      Gordo Lang                             Msg #1694, Oct-12-93 01:06PM
  2950. Subject: C++32 -zc, #pragma #problems, extern "C" problems
  2951.  
  2952.  GL> I am progamming in C++32 and am having difficulty with a few "features".
  2953.  GL> I suspect that the "-zc" option (put const literals in _TEXT segment)
  2954.  GL> does not work in C++ using any memory model.  Is this true ?
  2955.  
  2956. if you have const int far a[] = { 1, 2, 3, 4, 5, 6 };; this should go in the
  2957. code segment if the memory model is -mc or -ml.  I'll check this.
  2958.  
  2959.  GL> I cannot get the "#pragma DATA_SEG" example on page 154 of the UG to
  2960.  GL> emit data into anything other than _DATA or _BSS.  Is this feature
  2961.  GL> being ignored in the C++ version of the compiler?
  2962.  
  2963.  Yes.  I'll add this as a bug.
  2964.  
  2965.  GL> I believe the following constructs should be the same:
  2966.  GL> extern "C" {
  2967.  GL> int  x;
  2968.  GL> int y;
  2969.  GL> };
  2970.  GL> and ..
  2971.  GL> extern "C" int x;
  2972.  GL> extern "C" int y;
  2973.  GL> but the compiler produces different OMF records for these two cases.
  2974.  GL> The former construct produces linker complaints about duplication of
  2975.  GL> symbols.  Who is wrong here? Compiler, Linker, or Programmer?
  2976.  
  2977.  Programmer.  The semantics of a declaration are not affected by an
  2978.  extern "C" block.  See p.  524-525 of the C++ PL book included in
  2979.  WATCOM C++.  See p.116-119 of the ARM (especially p.118 which has
  2980.  exactly this example) for more detail.
  2981.  
  2982.  GL> I'm in the process of writing a de-mangler/re-mangler program to convert
  2983.  GL> the W?Mangled$:Name(s) into symbols more acceptable to an Assembler
  2984.  GL> (TASM); is the WATCOM C++32 mangling rules available?  I looked in the
  2985.  GL> manuals but couldn't find anything about mangling, is this a secret ?
  2986.  
  2987.  It's not a secret but it is subject to change.  What kind of .ASM code
  2988.  do you need in the member function?  Have you looked at using #pragma aux
  2989.  code bursts instead?
  2990.  
  2991.  Anthony
  2992.  
  2993. *** This is a reply to #1691.
  2994.  
  2995.  
  2996. From:    Edward Palandri                        Rec'd
  2997. To:      Kevin Kitsemetry                       Msg #1695, Oct-12-93 09:30PM
  2998. Subject: Problems with accessing an OS/2 16 bit DLL from Watcom C/386
  2999.  
  3000. It looks like I messed up in submitting the original material. I had the best
  3001. intentions too. I have just uploaded an updated version of OS2SKWAT.ZIP
  3002. including the missing file  (SDLL.DLL).
  3003.  
  3004. Since submitting the original report, I have upgraded to C/C++ 9.5 (unpatched)
  3005. and it has had no effect on the problem which shows exactly the same symptoms.
  3006.  
  3007. I really hope this does not put me on the end of the queue again.
  3008.  
  3009. Edward Palandri
  3010.  
  3011. *** This is a reply to #1689.  *** See also #1704.
  3012.  
  3013.  
  3014. From:    John Lansdale                          Rec'd
  3015. To:      Kevin Kitsemetry                       Msg #1696, Oct-13-93 05:54AM
  3016. Subject: malloc() and A-level patches
  3017.  
  3018. Hi again. I finally tracked down the "SetDIBits()" problem that I mentioned
  3019. about a month ago. What I found out was somewhat unusual. The problem
  3020. stemmed from a malloc() performed elsewhere in my code; when this malloc
  3021. was performed the SetDIBits() function decided to fail (with an
  3022. "Invalid pointer: 0x00000" error message). The funny thing is that the
  3023. malloc() in question comes from very stable code, so I'm assuming that
  3024. v9.5 might have a memory allocation problem somewhere. I'll check up
  3025. on this once I receive the level A disks.
  3026.  
  3027. I haven't received the level A patch diskette from WATCOM yet. Could
  3028. you please check into this matter please? Thanks.
  3029.  
  3030. *** See also #1705.
  3031.  
  3032.  
  3033. From:    Ron Smith
  3034. To:      FlashTek Inc.                          Msg #1698, Oct-13-93 10:24AM
  3035. Subject: New debugger.
  3036.  
  3037. A new debugger for watcom?!  Awlright!  It's not that I don't like the
  3038. debugger.  It is *VERY* powerful once you figure ouut how to use it but it has
  3039. some serious problems debugging C++ code (especially finding mangled C++
  3040. variables and procedures).  I hope you didn't go overboard and make another
  3041. Turbo Debugger (aka the Cute Debugger)
  3042.  
  3043. Also, it seems strange that the debugger DEFAULTS to being case INSENSITIVE.
  3044. I have modified the debugger config file but since C and C++ are case
  3045. sensitive, maybe the debugger should be too.
  3046.  
  3047. *** This is a reply to #1628.
  3048.  
  3049.  
  3050. From:    Kevin Kitsemetry                       Rec'd
  3051. To:      Dave Heyliger                          Msg #1700, Oct-13-93 12:47PM
  3052. Subject: _dos_getvect / _dos_setvect, 32-bit Windows
  3053.  
  3054.  DH>         It looks as if you call _dos_getvect and then
  3055.  DH> use the same _interrupt _far * pointer and call
  3056.  DH> _dos_setvect, the code works fine. However, using a
  3057.  DH> different _interrupt _far * pointer causes incorrect
  3058.  DH> setting of the vector. I have confirmed this by
  3059.  DH> tracing via VIDEO the entire assembly code chain.
  3060.  
  3061.  DH>         My question: do you have to perform any special MK_FP16() or ???
  3062.  DH> function before passing the interrupt vector to
  3063.  DH> _dos_setvect?
  3064.  
  3065.  DH>         If you need to see the asm trace listing, let me know.
  3066.  
  3067. The short answer is no, you should not have to use one of our special Windows
  3068. functions for this.  Have you tried the example in the library manual?  What
  3069. happened?
  3070.  
  3071.  
  3072. Kevin Kitsemetry
  3073. WATCOM TECHNICAL SUPPORT
  3074.  
  3075. *** This is a reply to #1668.
  3076.  
  3077.  
  3078. From:    Kevin Kitsemetry                       Rec'd
  3079. To:      Thomas B. Pollard                      Msg #1701, Oct-13-93 12:52PM
  3080. Subject: C/C++ 9.5A Wvideo interrup with <SyRq>
  3081.  
  3082.  TBP> OK about the <ctrl SysRq> but the Print Screen always worked before.
  3083.  TBP> Last night I compleatly reinstalled 9.5 on my 386
  3084.  TBP> computer at home and then applied the A patches.
  3085.  TBP> While I was in the Wvideo I pressed
  3086.  TBP> <Print Screen>(with a program loaded but not running)
  3087.  TBP> and I got a stack over flow and a the computer locked
  3088.  TBP> up.
  3089.  
  3090. I have never heard of that.  I just tried it here in a DOS box (under OS/2)
  3091. and was not able to reproduce that behaviour.  Does it happen with any exe?
  3092.  
  3093. *** This is a reply to #1672.
  3094.  
  3095.  
  3096. From:    Kevin Kitsemetry                       Rec'd
  3097. To:      Jason Blochowiak                       Msg #1702, Oct-13-93 02:48PM
  3098. Subject: Breaking into a program that steals the keyboard
  3099.  
  3100.  JB>  Hi. I'm working on a program that completely takes
  3101.  JB> over the keyboard vector (#9). It's nice that the
  3102.  JB> current version (I have the 9.5a C++ package) of
  3103.  JB> WVIDEO regains control of the keyboard when a pre-set
  3104.  JB> breakpoint is hit. However, it seems I can't break
  3105.  JB> into the program with the keyboard. This is definitely
  3106.  JB> feasible (TD386 does it) - is this currently possible
  3107.  JB> with WVIDEO?
  3108.  
  3109. Under DOS, you may be able to press Print-Scrn to break
  3110. into the program.  This (unfortunately) will not always
  3111. work under DOS; it depends on the state of the processor
  3112. at the time.
  3113.  
  3114.  
  3115. Kevin Kitsemetry
  3116. WATCOM TECHNICAL SUPPORT
  3117.  
  3118. *** This is a reply to #1673.
  3119.  
  3120.  
  3121. From:    Kevin Kitsemetry
  3122. To:      Brian Schriber                         Msg #1703, Oct-13-93 02:52PM
  3123. Subject: Wvideo Display problem
  3124.  
  3125.  BS> breakpoint. I then want the program to continue
  3126.  BS> execution from where I stopped it. I have not had a
  3127.  BS> problem restarting the program, just getting it to
  3128.  BS> continue. I have tried the /SWAP option on that 486.
  3129.  BS> Thanx, I don't know why it thinks there is another
  3130.  BS> monitor, but now that I can debug on the machine I am
  3131.  BS> much happier. If you could let me know about using the
  3132.  BS> break key on a program and continuation being not
  3133.  BS> supported from the point at which the User Interrupt
  3134.  BS> occurs I would be appreciative.
  3135.  
  3136. Again, you should be able to continue.  But under DOS, this seldom works
  3137. because of the state that the program is now
  3138. in.  Perhaps you could use OS/2 for debugging purposes?
  3139.  
  3140.  
  3141. Kevin Kitsemetry
  3142. WATCOM TECHNICAL SUPPORT
  3143.  
  3144. *** This is a reply to #1675.  *** See also #1718.
  3145.  
  3146.  
  3147. From:    Kevin Kitsemetry                       Rec'd
  3148. To:      Edward Palandri                        Msg #1704, Oct-13-93 03:31PM
  3149. Subject: Problems with accessing an OS/2 16 bit DLL from Watcom C/386
  3150.  
  3151.  EP> It looks like I messed up in submitting the original
  3152.  EP> material. I had the best intentions too. I have just
  3153.  EP> uploaded an updated version of OS2SKWAT.ZIP including
  3154.  EP> the missing file  (SDLL.DLL).
  3155.  
  3156.  EP> Since submitting the original report, I have upgraded
  3157.  EP> to C/C++ 9.5 (unpatched) and it has had no effect on
  3158.  EP> the problem which shows exactly the same symptoms.
  3159.  
  3160.  EP> I really hope this does not put me on the end of the queue again.
  3161.  
  3162. I now have the file and tried to run the example.  I could NOT get the
  3163. debugger to load the application.
  3164.  
  3165. I will check with the developers for OS/2 support with this.  I have talked
  3166. about this problem with them and they are at a loss right now. I will contact
  3167. you when they have had a chance to investigate this further.
  3168.  
  3169.  
  3170. Kevin Kitsemetry
  3171. WATCOM TECHNICAL SUPPORT
  3172.  
  3173. *** This is a reply to #1695.  *** See also #1713.
  3174.  
  3175.  
  3176. From:    Kevin Kitsemetry                       Rec'd
  3177. To:      John Lansdale                          Msg #1705, Oct-13-93 03:37PM
  3178. Subject: malloc() and A-level patches
  3179.  
  3180.  JL> Hi again. I finally tracked down the "SetDIBits()"
  3181.  JL> problem that I mentioned
  3182.  JL> about a month ago. What I found out was somewhat unusual. The problem
  3183.  JL> stemmed from a malloc() performed elsewhere in my code; when this malloc
  3184.  JL> was performed the SetDIBits() function decided to fail (with an
  3185.  JL> "Invalid pointer: 0x00000" error message). The funny thing is that the
  3186.  JL> malloc() in question comes from very stable code, so I'm assuming that
  3187.  JL> v9.5 might have a memory allocation problem somewhere. I'll check up
  3188.  JL> on this once I receive the level A disks.
  3189.  JL> I haven't received the level A patch diskette from WATCOM yet. Could
  3190.  JL> you please check into this matter please? Thanks.
  3191.  
  3192. The level-A patches did fix problems with SetDIBits() in Windows.  I have
  3193. checked our records and the order for the patches was not processed for some
  3194. reason.  It is now, and they should arrive at your location shortly (1-2
  3195. weeks).  If you provide us with your fax number, we can send a fax out (in the
  3196. future) when orders are processed.
  3197.  
  3198.  
  3199. Kevin Kitsemetry
  3200. WATCOM TECHNICAL SUPPORT
  3201.  
  3202. *** This is a reply to #1696.  *** See also #1721.
  3203.  
  3204.  
  3205. From:    Jim de Graff                           Rec'd
  3206. To:      Kevin Kitsemetry                       Msg #1709, Oct-14-93 10:27AM
  3207. Subject: IBM Workframe
  3208.  
  3209. Several months ago I got onto this BBS trying to get a fix for a problem.
  3210. I was trying to use Watcom C 9.0 with IBM Workframe for OS2/2.1. What I
  3211. really needed was to be able to use the CREATE MAKEFILE tool to manage a
  3212. medium size project. I decided to start small and use it on a one module
  3213. project. I kept on getting DLL problems when I did the create. I was told
  3214. by your good folks that I needed version 9.5 of the compiler to be able to use
  3215. Workframe so I ordered the upgrade. Now when I try to create the makefile I
  3216. just get turfed from the application. Will someone please tell me where to get
  3217. detailed information on how to integrate Watcom C/C++ 9.5 with Workframe for
  3218. OS2/2.1? I also need to know the exact steps to go through to create the
  3219. makefile. The on-line docs that came with Workframe really suck. I need books
  3220. that I can leaf through, not hypertext links that don't let me know what I am
  3221. missing by not following a particular link (sorry for the editorializing).
  3222.  
  3223. *** See also #1715.
  3224.  
  3225.  
  3226. From:    Dan Cummins                            Rec'd
  3227. To:      Zeb Fenton                             Msg #1710, Oct-14-93 11:00AM
  3228. Subject: A-level patches & new supervisor
  3229.  
  3230. Zeb,
  3231.  
  3232. Problems with the supervisor handling bitmaps > 1Mb existed after the A-level
  3233. patch.  (If you have not done so already,you should probably apply the A-level
  3234. patch so that you have the most up-to-date versions of all the software.)  A
  3235. new
  3236. windows supervisor is available in file area 12.  The file is called
  3237. WINEXT.ZIP.
  3238.  
  3239. NOTE: The A-level patch does not contain the new fixes that are in the new
  3240. windows supervisor mentioned above.  You will need the new windows supervisor
  3241. to fix the problem.
  3242.  
  3243.  
  3244. Dan Cummins
  3245. WATCOM Languages Support
  3246.  
  3247.  
  3248. From:    Anthony Scian
  3249. To:      Gordo Lang                             Msg #1711, Oct-14-93 01:01PM
  3250. Subject: Mangled names and Assembler
  3251.  
  3252.  GL> I am trying to implement some class method()s in assembler (using
  3253.  GL> Borland's TASM to be precise).  These are rather large routines which
  3254.  GL> cannot be satisfactorily implemented using the #pragma aux scheme.  Is
  3255.  GL> there a way to change the name-mangling scheme so that it does NOT use
  3256.  GL> characters like "?():" ?  There is no way TASM (or any other x86
  3257.  GL> assembler) can produce a subroutine label like "W?foo(ul):qv" since it
  3258.  GL> contains key characters.  I really don't want to convert all my class
  3259.  GL> methods into their equivalent "C" routines just to get around this, and
  3260.  GL> I don't want to write an OBJ label translater.  Is there a way out of
  3261.  GL> this? HELP.
  3262.  
  3263. #pragma aux name_ack "__S__ack_v_i";
  3264. #pragma aux name_foo "__S__foo_v_i";
  3265. #pragma aux name_bar "__S__bar_v_i";
  3266.  
  3267. struct S {
  3268.     int __pragma("name_ack") ack();
  3269.     virtual int __pragma("name_foo") foo();
  3270.     static int __pragma("name_bar") bar();
  3271. };
  3272.  
  3273. This allows you to code the member functions in .ASM code with precisely the
  3274. names indicated in the #pragma.  The C++ compiler will use your name as the
  3275. mangled name so make sure they are unique across your program.
  3276.  
  3277. *** This is a reply to #1682.
  3278.  
  3279.  
  3280. From:    Edward Palandri                        Rec'd
  3281. To:      Kevin Kitsemetry                       Msg #1713, Oct-14-93 05:43PM
  3282. Subject: Problems with accessing an OS/2 16 bit DLL from Watcom C/386
  3283.  
  3284. I also was not able to get the debugger to execute the program. I have since
  3285. patched my 9.5 release to level a and this makes no difference.
  3286.  
  3287. I am pleased that you have been able to reproduce the problem.
  3288.  
  3289. Edward Palandri
  3290.  
  3291. *** This is a reply to #1704.
  3292.  
  3293.  
  3294. From:    Kevin Kitsemetry                       Rec'd
  3295. To:      Jim de Graff                           Msg #1715, Oct-15-93 10:23AM
  3296. Subject: IBM Workframe
  3297.  
  3298.  JdG> I was trying to use Watcom C 9.0 with IBM Workframe for OS2/2.1. What I
  3299.  JdG> really needed was to be able to use the CREATE MAKEFILE tool to manage a
  3300.  JdG> medium size project. I decided to start small and use it on a one module
  3301.  JdG> project. I kept on getting DLL problems when I did
  3302.  JdG> the create. I was told
  3303.  JdG> by your good folks that I needed version 9.5 of the compiler to be able
  3304.  JdG> to use Workframe so I ordered the upgrade. Now when I
  3305.  JdG> try to create the makefile I just get turfed from the
  3306.  JdG> application. Will someone please tell me where to get
  3307.  JdG> detailed information on how to integrate Watcom C/C++
  3308.  JdG> 9.5 with Workframe for OS2/2.1? I also need to know
  3309.  JdG> the exact steps to go through to create the makefile.
  3310.  
  3311. If all you would like to do is compile, link and run, then you just have to
  3312. copy over the .prf files into the workframe directory.  It sounds like you may
  3313. have already done that.
  3314.  
  3315. However, the make makefile utility in the Workframe will not function
  3316. correctly until the B-level patches become available.  You will also have to
  3317. have Workframe 1.1 (not 1.0).  Finally, the makefile that is generated by
  3318. Workframe has to be used by nmake, not our wmake.
  3319.  
  3320.  
  3321. Kevin Kitsemetry
  3322. WATCOM TECHNICAL SUPPORT
  3323.  
  3324. *** This is a reply to #1709.  *** See also #1719.
  3325.  
  3326.  
  3327. From:    Thomas B. Pollard                      Rec'd
  3328. To:      Kevin Kitsemetry                       Msg #1718, Oct-15-93 11:24AM
  3329. Subject: Wvideo Display problem
  3330.  
  3331. Please look at message #1534
  3332. When you stop the program look at the assembly and use Evaluate
  3333. to look at your code.  If Wvideo is changing your code to a 0X00
  3334. then you are seeing what I saw.  The other test is to check the Assembly
  3335. code before and after to run the code.
  3336. I don't thing we should have to run Os2 Just to run Wvideo and if we did
  3337. How are we going to debug a DOS dependent problem.  Like the one that is in
  3338. Wvideo.
  3339.  
  3340. *** This is a reply to #1703.  *** See also #1725.
  3341.  
  3342.  
  3343. From:    Jim de Graff                           Rec'd
  3344. To:      Kevin Kitsemetry                       Msg #1719, Oct-15-93 05:33PM
  3345. Subject: IBM Workframe
  3346.  
  3347. Unfortunately I can only access the BBS when I boot through DOS (OS2 doesn't
  3348. support netmodem) so I don't know offhand what version of Workframe I am
  3349. using. You are correct. I had already copied the .prf file over with no
  3350. success. However, I was not told (when I was told about upgrading to 9.5) that
  3351. I would also need Workframe 1.1. I was told 9.5 would fix the problem. This
  3352. happens every time I am forced to use two different products together.
  3353. Whenever something doesn't work, each party points the finger at the other. No
  3354. slur intended, but it does get frustrating to have hundreds of $$$$ of
  3355. software that can't be used.
  3356.  
  3357. *** This is a reply to #1715.  *** See also #1726.
  3358.  
  3359.  
  3360. From:    John Lansdale                          Rec'd
  3361. To:      Kevin Kitsemetry                       Msg #1721, Oct-17-93 01:52AM
  3362. Subject: malloc() and A-level patches
  3363.  
  3364.        My fax number is shared with my voice line: 416-621-8788 (call in
  3365. advance). I hope the level-A fix to the SetDIBits() problem also fixed
  3366. the problem with StretchDIBits() - they both experience the same problem
  3367. that I previously outlined.
  3368.  
  3369. *** This is a reply to #1705.  *** See also #1728.
  3370.  
  3371.  
  3372. From:    Thomas B. Pollard                      Rec'd
  3373. To:      Kevin Kitsemetry                       Msg #1723, Oct-18-93 07:56AM
  3374. Subject: DOS4GW.EXE Error [35] C/C++ 9.5A
  3375.  
  3376. TO Watcom 519-747-4971
  3377. FROM Tom Pollard 617-275-0100 Ex127
  3378. DOS4GW.EXE Error [35] C/C++ 9.5A
  3379. |
  3380. I am running the newly patched DOS4GW.EXE (8-27-93) and normally when it
  3381. normally traps an exception it will show the "Crash address
  3382. (unrelocated)" But I have had it Trap on an Unexpected Interrupt=0000
  3383. and not give the "Crash address (unrelocated)".  What I do get is the
  3384. following:
  3385. |
  3386. Error [35]: Unexpected Interrupt=0000 in DOS4GW.EXE at 01E8:7286
  3387. code=0000 ss=01F0 ds=01f0 es=01F0
  3388. ax=2C00 bx=0000 cx=01f0 dx=0020 sp=4CCC bp=8D80 si=0000 di=0000
  3389. |
  3390. Error [35]: Unexpected Interrupt=0000 in DOS4GW.EXE at 01E8:761A
  3391. code=0000 ss=01F0 ds=01f0 es=01F0
  3392. ax=2C0C bx=100CC cx=01f0 dx=0020 sp=4CCC bp=AA30 si=0000 di=0000
  3393. |
  3394. Is this my code causing the error or is it DOS4GW.EXE ?
  3395. Thanks
  3396.  
  3397.  
  3398. *** See also #1737.
  3399.  
  3400.  
  3401. From:    Kevin Kitsemetry                       Rec'd
  3402. To:      Robert Campbell                        Msg #1724, Oct-18-93 10:37AM
  3403. Subject: Bug reported in GMA_BUG.ZIP
  3404.  
  3405. KK> Internal Report #6647
  3406.  
  3407.  
  3408.  RC> Please look in GMA_BUG.ZIP for the sample code to a
  3409.  RC> problem that we have encountered with WVIDEO
  3410.  RC> (windows).  This program seems to run fine on the
  3411.  RC> first execution through the debugger, but on the
  3412.  RC> second run through,ie: new; go
  3413.  RC> it crashes.  Any help you can give in this matter
  3414.  RC> would be greatly appreciated.
  3415.  
  3416. I have taken a look at both of these examples.  There
  3417. have been a number of upgrades to the compiler and tools,
  3418. especially with respect to SetDIBits() under Windows.
  3419. The latest version of the WATCOM C/C++ tools did not
  3420. demonstrate a problem with either of the examples.
  3421.  
  3422. The latest version of the compiler is 9.5, patch level 'a'.
  3423.  
  3424. Kevin Kitsemetry
  3425. WATCOM TECHNICAL SUPPORT
  3426.  
  3427. *** This is a reply to #1611.
  3428.  
  3429.  
  3430. From:    Kevin Kitsemetry                       Rec'd
  3431. To:      Jim de Graff                           Msg #1726, Oct-18-93 10:51AM
  3432. Subject: IBM Workframe
  3433.  
  3434.  JdG> Unfortunately I can only access the BBS when I boot through DOS (OS2
  3435.  JdG> doesn't support netmodem) so I don't know offhand
  3436.  JdG> what version of Workframe I am using. You are
  3437.  JdG> correct. I had already copied the .prf file over with
  3438.  JdG> no success. However, I was not told (when I was told
  3439.  JdG> about upgrading to 9.5) that I would also need
  3440.  JdG> Workframe 1.1. I was told 9.5 would fix the problem.
  3441.  JdG> This happens every time I am forced to use two
  3442.  JdG> different products together. Whenever something
  3443.  JdG> doesn't work, each party points the finger at the
  3444.  JdG> other. No slur intended, but it does get frustrating
  3445.  JdG> to have hundreds of $$$$ of software that can't be
  3446.  JdG> used.
  3447.  
  3448. The problem has been fixed and this fix will be provided
  3449. free of charge in the form of a patch (level 'b').
  3450.  
  3451.  
  3452. Kevin Kitsemetry
  3453. WATCOM TECHNICAL SUPPORT
  3454.  
  3455. *** This is a reply to #1719.  *** See also #1731.
  3456.  
  3457.  
  3458. From:    Kevin Kitsemetry                       Rec'd
  3459. To:      John Lansdale                          Msg #1728, Oct-18-93 10:56AM
  3460. Subject: malloc() and A-level patches
  3461.  
  3462.  JL>        My fax number is shared with my voice line: 416-621-8788 (call in
  3463.  JL> advance). I hope the level-A fix to the SetDIBits() problem also fixed
  3464.  JL> the problem with StretchDIBits() - they both experience the same problem
  3465.  JL> that I previously outlined.
  3466.  
  3467. The fax verification is automatic, so I doubt that I would be able to provide
  3468. this service to you so long as the fax machine is on the same line, sorry!
  3469.  
  3470.  
  3471. Kevin Kitsemetry
  3472. WATCOM TECHNICAL SUPPORT
  3473.  
  3474. *** This is a reply to #1721.  *** See also #1753.
  3475.  
  3476.  
  3477. From:    Kevin Blenkinsopp                      Rec'd
  3478. To:      Kevin Kitsemetry                       Msg #1729, Oct-18-93 01:59PM
  3479. Subject: Please check the DPMI 800 part of this message
  3480.  
  3481. * Original Area: DOS4GPro
  3482. * Original To  : Dan Teven (1:221/186)
  3483. * Original Subj: DLLs and other stuff
  3484.  
  3485. Thanks. One of your guys faxed me some DOS/4G info this morning. Is there a
  3486. way I can get a more detailed idea of the multitasking support as well? Right
  3487. now we make everything cooperate and yield the CPU whenever a "process" is
  3488. idle, which actually works pretty well, but still means that one wild pointer
  3489. can take out the entire machine.
  3490.  
  3491. I can't look at the other mail right now, so if I didn't ask before, please
  3492. confirm that DLLs are only supported in 4G and NOT in 4GW Pro.
  3493.  
  3494. By the way, what is your role at Rational?
  3495.  
  3496. As far as this damn board goes, I take it that the general idea is to use DPMI
  3497. function 800 that Kevin K posted some sample code for a couple of weeks ago. I
  3498. saw that and figured "hey this looks like it might be useful", so I tried it
  3499. and everything seemed ok at 4 meg, but when I changed it to map to C0000000
  3500. and scribbled something there, then read it back using the driver, it wasn't
  3501. there. Does MK_FP/DPMI/4GW support things that are that high up? (The reason I
  3502. ask is that I had some DPMI classes that Qualitas gives people that couldn't
  3503. cope when you tried to set a selector base to anything higher than 16M)
  3504. Incidentally, if you're not the right guy for this please forward it to KevinK.
  3505.  
  3506. Thanks for taking time for this stuff.
  3507.  
  3508. Kevin
  3509.  
  3510. *** See also #1738.
  3511.  
  3512.  
  3513. From:    Thomas B. Pollard
  3514. To:      Keven Kitsemetry                       Msg #1730, Oct-18-93 02:15PM
  3515. Subject: C/C++ 9.5A Interrupting WVIDEO (See #1642)
  3516.  
  3517. TO Watcom 519-747-4971
  3518. FROM Tom Pollard 617-275-0100 Ex127
  3519. C/C++ 9.5A Interrupting WVIDEO (See #1642)
  3520. |
  3521. Here is another clue to the problem.
  3522. |
  3523. Back when I reported a memory problem in message #1354 all I had to do
  3524. was replace your RSIHELP.EXP with the 9.5 LA RSIHELP.EXP 2-16-93 and it
  3525. fixed the problem.  Well I can fix the inability to Interrupt WVIDEO in
  3526. the same manner I replaced RSIHELP.EXP (27064 8-27-93) with the LA
  3527. RSIHELP.EXP (25984 2-16-93) and <Prt Scr> will now Interrupt WVIDEO.
  3528. I also noted that with a program loaded but not running and in
  3529. WVIDEO when I press <Prt Scr> I beep with the 8-27-93 RSIHELP.EXP and
  3530. when I use the RSIHELP.EXP 2-16-93 I don't beep.  I hope this will help.
  3531. Message 1703 maybe related to my message #1354 and it would be
  3532. interesting if he tries the RSIHELP.EXP 2-16-93 and it fixes his
  3533. problem.
  3534. I think if you have not already tested WVIDEO on a nothing but DOS
  3535. computer (NO OS/2) you should.
  3536. |
  3537. NOTE: Before I used 9.5A patches I delete and reinstalled 9.5
  3538.  
  3539.  
  3540.  
  3541. *** See also #1739.
  3542.  
  3543.  
  3544. From:    Jim de Graff                           Rec'd
  3545. To:      Kevin Kitsemetry                       Msg #1731, Oct-18-93 03:21PM
  3546. Subject: IBM Workframe
  3547.  
  3548. Great. I'll keep my eyes open on the board until it appears. Thanks.
  3549.  
  3550. *** This is a reply to #1726.
  3551.  
  3552.  
  3553. From:    Edward Palandri                        Rec'd
  3554. To:      Kevin Kitsemetry                       Msg #1733, Oct-18-93 10:58PM
  3555. Subject: 32 bit Fortran Windows DLL, ok with Fortran 9.01, fails with 9.5a
  3556.  
  3557. Problem with Watcom Fortran 32 bit DLL's compiled using Fortran/386 9.5a
  3558. ========================================================================
  3559.  
  3560.  
  3561. I have recently attempted to upgrade to C and Fortran 9.5 and I have
  3562. run into a problem.
  3563.  
  3564. Basically the 32 bit DLL's that I compile and run successfully using
  3565. Fortran and C 9.01e do not work or work erratically if I compile them
  3566. using Fortran and C 9.5a.
  3567.  
  3568. Typically one gets a General protection fault on loading or just
  3569. after starting to execute the DLL.
  3570.  
  3571. I have uploaded a zip file containing a simple test case. It consists
  3572. of a 16 bit windows front end which calls a very simple 32 bit DLL.
  3573. The DLL loads and executes OK under 9.01e but aborts if compiled with
  3574. 9.5a
  3575.  
  3576. The ZIP file is call WATTST.ZIP. It contains a file (README.TXT) which
  3577. is a list of its components and batch files etc. for recompiling
  3578. them.
  3579.  
  3580. Please let me know if there is some obvious modification I need to
  3581. make to get this to work under 9.5a
  3582.  
  3583.  
  3584. Edward Mark Palandri
  3585. Document Sciences Corporation
  3586. 6333 Greenwich Dr, Suite 120
  3587. San Diego, CA 92122
  3588.  
  3589. Ph.  (619) 625 2030
  3590. Fax. (619) 625 2021
  3591. Intelnet Mark.DSC@Xerox.Com
  3592.  
  3593. *** See also #1741.
  3594.  
  3595.  
  3596. From:    Mark Delafranier                       Rec'd
  3597. To:      Christer Palm                          Msg #1735, Oct-19-93 09:55AM
  3598. Subject: Bug in pow()
  3599.  
  3600. KK> Internal Report #6213
  3601.  
  3602.  
  3603.  MD> Can you provide a small sample program that will
  3604.  MD> reproduce the problem? This will greatly assist into
  3605.  
  3606.  CP> OK, Here it is:
  3607.  
  3608.  CP> NOTE 1: I haven't examined if this bug occurs with other math
  3609.  CP>           functions, so similar bugs might be present in other
  3610.  CP>           math funcs !!!
  3611.  
  3612.  CP>      2: This bug only occurs when a user SIGFPE handler is present
  3613.  
  3614.  CP> Could you also PLEEEAAASE take a look at msg #1527 ???
  3615.  
  3616.  CP> Compile & link: wcl386 -od bug.c
  3617.  
  3618.  
  3619.  CP> #include <stdio.h>
  3620.  CP> #include <signal.h>
  3621.  CP> #include <math.h>
  3622.  CP> #include <errno.h>
  3623.  
  3624.  CP> void fpe_handler( int signo )
  3625.  CP> {
  3626.  CP>   puts( "Caught SIGFPE" );
  3627.  CP>   signal( SIGFPE, fpe_handler );
  3628.  CP> }
  3629.  
  3630.  CP> int matherr( struct exception *err )
  3631.  CP> {
  3632.  CP>   puts( "Caught matherr" );
  3633.  CP>   return 0;
  3634.  CP> }
  3635.  
  3636.  CP> void main( void )
  3637.  CP> {
  3638.  CP>   signal( SIGFPE, fpe_handler );
  3639.  
  3640.  CP>   errno = 0;
  3641.  CP>   log( -1.0 );          // No SIGFPE, sets errno, calls matherr
  3642.  CP>   printf( "errno after invalid log: %d\n", errno );
  3643.  
  3644.  CP>   errno = 0;
  3645.  CP>   pow( 1000.0, 1000.0 );    // Raises SIGFPE, no errno, no matherr
  3646.  CP>   printf( "errno after invalid pow: %d\n", errno );
  3647.  CP> }
  3648.  
  3649. Christer:
  3650.  
  3651. The sample code above does not reproduce a problem with the SIGFPE handler.
  3652.  
  3653. I tried to reproduce the problem with WATCOM C/C++32 patch level "A".
  3654.  
  3655. If you have any other questions or concerns, please do not hesitate to contact
  3656. WATCOM TECHNICAL SUPPORT.
  3657.  
  3658. Hot-line:     (519) 884-0702        Internet:        tech@watcom.on.ca fax:
  3659.       (519) 747-4971        Compuserve:      type GO WATCOM BBS:
  3660. (519) 884-2103        WATCOM Sales:    1-800-265-4555
  3661.  
  3662. Mark DeLaFranier
  3663. WATCOM TECHNICAL SUPPORT
  3664.  
  3665. *** This is a reply to #1623.  *** See also #1736.
  3666.  
  3667.  
  3668. From:    Fred Crigger                           Rec'd
  3669. To:      Mark Delafranier                       Msg #1736, Oct-19-93 11:16AM
  3670. Subject: Bug in pow()
  3671.  
  3672. KK> Internal Report #6213
  3673.  
  3674.  
  3675.  MD> Can you provide a small sample program that will
  3676.  MD> reproduce the problem? This will greatly assist into
  3677.  
  3678.  CP> OK, Here it is:
  3679.  
  3680.  CP> NOTE 1: I haven't examined if this bug occurs with other math
  3681.  CP>           functions, so similar bugs might be present in other
  3682.  CP>           math funcs !!!
  3683.  
  3684.  CP>      2: This bug only occurs when a user SIGFPE handler is present
  3685.  
  3686.  CP> Could you also PLEEEAAASE take a look at msg #1527 ???
  3687.  
  3688.  CP> Compile & link: wcl386 -od bug.c
  3689.  
  3690.  
  3691.  CP> #include <stdio.h>
  3692.  CP> #include <signal.h>
  3693.  CP> #include <math.h>
  3694.  CP> #include <errno.h>
  3695.  
  3696.  CP> void fpe_handler( int signo )
  3697.  CP> {
  3698.  CP>   puts( "Caught SIGFPE" );
  3699.  CP>   signal( SIGFPE, fpe_handler );
  3700.  CP> }
  3701.  
  3702.  CP> int matherr( struct exception *err )
  3703.  CP> {
  3704.  CP>   puts( "Caught matherr" );
  3705.  CP>   return 0;
  3706.  CP> }
  3707.  
  3708.  CP> void main( void )
  3709.  CP> {
  3710.  CP>   signal( SIGFPE, fpe_handler );
  3711.  
  3712.  CP>   errno = 0;
  3713.  CP>   log( -1.0 );          // No SIGFPE, sets errno, calls matherr
  3714.  CP>   printf( "errno after invalid log: %d\n", errno );
  3715.  
  3716.  CP>   errno = 0;
  3717.  CP>   pow( 1000.0, 1000.0 );    // Raises SIGFPE, no errno, no matherr
  3718.  CP>   printf( "errno after invalid pow: %d\n", errno );
  3719.  CP> }
  3720.  
  3721.  MD> Christer:
  3722.  
  3723.  MD> The sample code above does not reproduce a problem
  3724.  MD> with the SIGFPE handler.
  3725.  
  3726.  MD> I tried to reproduce the problem with WATCOM C/C++32 patch level "A".
  3727.  
  3728.  MD> If you have any other questions or concerns, please do
  3729.  MD> not hesitate to contact WATCOM TECHNICAL SUPPORT.
  3730.  
  3731.  MD> Hot-line:     (519) 884-0702        Internet:
  3732.  MD> tech@watcom.on.ca fax:          (519) 747-4971
  3733.  MD> Compuserve:      type GO WATCOM BBS:          (519)
  3734.  MD> 884-2103        WATCOM Sales:    1-800-265-4555
  3735.  
  3736.  MD> Mark DeLaFranier
  3737.  MD> WATCOM TECHNICAL SUPPORT
  3738.  
  3739. Did you read msg 1530 and 1572?  He is complaining that pow doesn't call
  3740. matherr and set errno if you have a signal handler for SIGFPE. I tried the
  3741. program and it does exactly what he says happens. i.e. it doesn't do what the
  3742. manual says should happen.  Your message says that there is no problem with
  3743. the A-level patch.  I don't think anything has been done in A-level patch to
  3744. change the behaviour of this program.  He is going to be upset after
  3745. downloading the huge A-level patch, and discover that the program still has
  3746. the same behaviour.  Then he is going to be upset that you don't understand
  3747. his well stated problem.
  3748.  
  3749. Fred
  3750.  
  3751. *** This is a reply to #1735.
  3752.  
  3753.  
  3754. From:    Kevin Kitsemetry                       Rec'd
  3755. To:      Kevin Blenkinsopp                      Msg #1738, Oct-19-93 03:37PM
  3756. Subject: Please check the DPMI 800 part of this message
  3757.  
  3758.  KB> As far as this damn board goes, I take it that the general idea is to
  3759.  KB> use DPMI function 800 that Kevin K posted some sample
  3760.  KB> code for a couple of weeks ago. I saw that and figured
  3761.  KB> "hey this looks like it might be useful", so I tried
  3762.  KB> it and everything seemed ok at 4 meg, but when I
  3763.  KB> changed it to map to C0000000 and scribbled something
  3764.  KB> there, then read it back using the driver, it wasn't
  3765.  KB> there. Does MK_FP/DPMI/4GW support things that are
  3766.  KB> that high up? (The reason I ask is that I had some
  3767.  KB> DPMI classes that Qualitas gives people that couldn't
  3768.  KB> cope when you tried to set a selector base to anything
  3769.  KB> higher than 16M) Incidentally, if you're not the right
  3770.  KB> guy for this please forward it to KevinK.
  3771.  
  3772. I don't believe that there should be a problem mapping things above 4 MB.  If
  3773. you want to check the DPMI support for DOS/4GW,you can run the program in a
  3774. Windows DOS box, or while running QEMM (whereby DPMI functions are passed on
  3775. to the DPMI host).
  3776.  
  3777.  
  3778. Kevin Kitsemetry
  3779. WATCOM TECHNICAL SUPPORT
  3780.  
  3781. *** This is a reply to #1729.  *** See also #1759.
  3782.  
  3783.  
  3784. From:    Kevin Kitsemetry                       Rec'd
  3785. To:      Thomas B. Pollard                      Msg #1739, Oct-19-93 03:40PM
  3786. Subject: C/C++ 9.5A Interrupting WVIDEO (See #1642)
  3787.  
  3788.  TBP> Here is another clue to the problem.
  3789.  TBP> |
  3790.  TBP> Back when I reported a memory problem in message #1354 all I had to do
  3791.  TBP> was replace your RSIHELP.EXP with the 9.5 LA RSIHELP.EXP 2-16-93 and it
  3792.  TBP> fixed the problem.  Well I can fix the inability to Interrupt WVIDEO in
  3793.  TBP> the same manner I replaced RSIHELP.EXP (27064 8-27-93) with the LA
  3794.  TBP> RSIHELP.EXP (25984 2-16-93) and <Prt Scr> will now Interrupt WVIDEO.
  3795.  TBP> I also noted that with a program loaded but not running and in
  3796.  TBP> WVIDEO when I press <Prt Scr> I beep with the 8-27-93 RSIHELP.EXP and
  3797.  TBP> when I use the RSIHELP.EXP 2-16-93 I don't beep.  I hope this will help.
  3798.  
  3799. I will pass all of this on to the developers.  Thanks.  I will certainly
  3800. contact you if I hear anything from them.
  3801.  
  3802.  
  3803. Kevin Kitsemetry
  3804. WATCOM TECHNICAL SUPPORT
  3805.  
  3806. *** This is a reply to #1730.
  3807.  
  3808.  
  3809. From:    Kevin Kitsemetry                       Rec'd
  3810. To:      Edward Palandri                        Msg #1741, Oct-19-93 04:09PM
  3811. Subject: 32 bit Fortran Windows DLL, ok with Fortran 9.01, fails with 9.5a
  3812.  
  3813.  EP> Problem with Watcom Fortran 32 bit DLL's compiled using Fortran/386 9.5a
  3814.  EP> ========================================================================
  3815.  
  3816. I have received the file and will investigate the problem.  This now has
  3817. Internal Report #8091.
  3818.  
  3819.  
  3820. Kevin Kitsemetry
  3821. WATCOM TECHNICAL SUPPORT
  3822.  
  3823. *** This is a reply to #1733.
  3824.  
  3825.  
  3826. From:    Thomas B. Pollard                      Rec'd
  3827. To:      Kevin Kitsemetry                       Msg #1742, Oct-20-93 07:50AM
  3828. Subject: DOS4GW.EXE Error [35] C/C++ 9.5A
  3829.  
  3830. I still would like to find out what error #35 is.
  3831. After I wrote you I turned on the NULL pointer test and found out a spot in
  3832. the code that was writing to the zero page.  So most likely it is my
  3833. code doing this.  That dog4g=NULLP has been very helpful.
  3834.  
  3835. *** This is a reply to #1737.  *** See also #1743.
  3836.  
  3837.  
  3838. From:    Kevin Kitsemetry                       Rec'd
  3839. To:      Thomas B. Pollard                      Msg #1743, Oct-20-93 05:31PM
  3840. Subject: DOS4GW.EXE Error [35] C/C++ 9.5A
  3841.  
  3842.  TBP> I still would like to find out what error #35 is.
  3843.  TBP> After I wrote you I turned on the NULL pointer test
  3844.  TBP> and found out a spot in the code that was writing to
  3845.  TBP> the zero page.  So most likely it is my
  3846.  TBP> code doing this.  That dog4g=NULLP has been very helpful.
  3847.  
  3848. Error [35] means that for some reason, the program was halting in the DOS/16M
  3849. kernal, and was therefor unable to dump and of the 32-bit register
  3850. information.  This may be a bug in the
  3851. DOS/4GW extender as well as in the program.  Would it be
  3852. possible to upload a small example that reproduces the problem?
  3853.  
  3854.  
  3855. Kevin Kitsemetry
  3856. WATCOM TECHNICAL SUPPORT
  3857.  
  3858. *** This is a reply to #1742.  *** See also #1748.
  3859.  
  3860.  
  3861. From:    Matt Pigan
  3862. To:      All                                    Msg #1744, Oct-20-93 06:06PM
  3863. Subject: WCSTOMBS & related functions.
  3864.  
  3865. We here at Southern Computer Systems are in the process of evaluating 32 bit
  3866. compilers (so we can decide on our "standard" compiler).  In a simple Double
  3867. Byte Character test (using only ANSI multibyte & wide character functions) we
  3868. were unable to properly redisplay the multibyte string after adding some
  3869. simple text into the string.  The same code was compiled under IBM C Set++
  3870. v2.0 and it worked just fine.
  3871.  
  3872. We are almost purely an OS/2 house.  We currently have a project for
  3873. converting our product over into Japanese, which requires the DBCS support.
  3874. Any help or follow up would be greatly appreciated.  If you need the source
  3875. (under 30 lines of C code), please call our BBS or
  3876. me by phone and I can Upload it to you.
  3877.  
  3878. Matt
  3879. Phone: (205) 251-2985
  3880. BBS: (205) 251-1330 (send E-mail to Matt Pigan)
  3881.  
  3882. *** See also #1749.
  3883.  
  3884.  
  3885. From:    Matthew Heinze                         Rec'd
  3886. To:      Christer Palm                          Msg #1745, Oct-20-93 07:57PM
  3887. Subject: Re-post of #132 in area 11, since this also concerns c/c++32 9.5
  3888.  
  3889.  CP> /*
  3890.  CP>  *    Example showing a bug in WCC386 v9.01e code generator
  3891.  CP>  */
  3892.  CP> void main( void )
  3893.  CP> {
  3894.  CP>   struct test {
  3895.  CP>     double d;
  3896.  CP>   } s = {
  3897.  CP>     666.0         /* Test value */
  3898.  CP>   };
  3899.  
  3900.  CP>   union {
  3901.  CP>     double d;
  3902.  CP>     struct test *p;
  3903.  CP>   } u;
  3904.  
  3905.  CP>   u.p = &s;
  3906.  
  3907.  CP>   u.d = u.p->d;
  3908.  CP> /*
  3909.  CP>  * WDISASM reveals a code generation bug in the preceding statement:
  3910.  CP>  *
  3911.  CP>  *  ; has to move 2 DWORDs to move a double, since it's 8 bytes:
  3912.  CP>  *
  3913.  CP>  *  mov     eax,-10H[ebp]     ; pick up pointer to double
  3914.  CP>  *  mov     eax,[eax]         ; fetch the low DWORD
  3915.  CP>  *  mov     -10H[ebp],eax     ; store it to
  3916.  CP> destination - OVERWRITES THE POINTER
  3917.  CP>  *  mov     eax,-10H[ebp]     ; pick up the (NOW DESTROYED) pointer again
  3918.  CP>  *  mov     eax,+4H[eax]      ; fetch the high DWORD
  3919.  CP> from never-never land
  3920.  CP>  *  mov     -0cH[ebp],eax     ;  and happily store it in destination
  3921.  CP>  */
  3922.  
  3923.  CP>  /*
  3924.  CP>   * Force compiler to update the stack image of 'u' by
  3925.  CP> using a reference to it,
  3926.  CP>   *  or else our bug will be wiped out by the
  3927.  CP> optimizer if we don't use the
  3928.  CP>   *  /d2 or /od compiler options:
  3929.  CP>   */
  3930.  
  3931.  CP>   printf( "%g  %p", u.d, &u );    /* Hey, what happened ??? */ }
  3932.  
  3933. This problem will be fixed with the B-level patches for C/C++32 Version 9.5.
  3934.  
  3935. Matthew Heinze
  3936. WATCOM TECHNICAL SUPPORT
  3937.  
  3938. *** This is a reply to #1527.  *** See also #1760.
  3939.  
  3940.  
  3941. From:    Joe Friedman
  3942. To:      Tech Support                           Msg #1746, Oct-20-93 09:01PM
  3943. Subject: ASPI driver for c++ 32
  3944.  
  3945. I'm looking for an ASPI (Advanced SCSI Programming Interface) driver that will
  3946. work for programs written in the c++ 32-bit compiler.  I've seen ones for
  3947. standard DOS and OS/2, but I need one for the 4GW DOS extender.  Any ideas on
  3948. where I might find one?  So far, I have not been able to get a response from
  3949. Adaptec, and thought someone at WATCOM might have some other ideas.
  3950.  
  3951. *** See also #1750.
  3952.  
  3953.  
  3954. From:    Paul Tletski                           Rec'd
  3955. To:      Kevin Kitsemetry                       Msg #1747, Oct-21-93 10:17AM
  3956. Subject: What is _wstart?
  3957.  
  3958. Kevin,
  3959.  
  3960. I've been porting some code from zApp application framework to use the Watcom
  3961. compiler  and I've been encountering the following undefined link reference
  3962. which I believe is generated somehow by the Watcom compiler.  I'm putting
  3963. together some DOS applications which use zApp. zApp is more or less a Windows
  3964. replacer, supporting a large amount of the Windows API.  Is _wstart a Watcom
  3965. generated symbol or label for some Window's dependency?  I don't see it in any
  3966. of the simple DOS programs I've put together so far.
  3967.  
  3968. Thanks.
  3969.  
  3970. Paul Tletski
  3971. Highland Hts., OH
  3972.  
  3973. *** See also #1751.
  3974.  
  3975.  
  3976. From:    Thomas B. Pollard                      Rec'd
  3977. To:      Kevin Kitsemetry                       Msg #1748, Oct-21-93 02:57PM
  3978. Subject: DOS4GW.EXE Error [35] C/C++ 9.5A
  3979.  
  3980. Sorry no it is a program that is 758000 bytes and it is controling a
  3981. device.  So it would be very hardfor you to test.  But as I said the program
  3982. was accessing null pointers and probably causing problems.
  3983. Thanks for you time.
  3984.  
  3985. *** This is a reply to #1743.
  3986.  
  3987.  
  3988. From:    Kevin Kitsemetry                       Rec'd
  3989. To:      Matt Pigan                             Msg #1749, Oct-21-93 03:18PM
  3990. Subject: WCSTOMBS & related functions.
  3991.  
  3992.  MP> We here at Southern Computer Systems are in the
  3993.  MP> process of evaluating 32 bit compilers (so we can
  3994.  MP> decide on our "standard" compiler).  In a simple
  3995.  MP> Double Byte Character test (using only ANSI multibyte
  3996.  MP> & wide character functions) we were unable to properly
  3997.  MP> redisplay the multibyte string after adding some
  3998.  MP> simple text into the string.  The same code was
  3999.  MP> compiled under IBM C Set++ v2.0 and it worked just
  4000.  MP> fine.
  4001.  MP>
  4002.  MP> We are almost purely an OS/2 house.  We currently have a project for
  4003.  MP> converting our product over into Japanese, which
  4004.  MP> requires the DBCS support.  Any help or follow up
  4005.  MP> would be greatly appreciated.  If you need the source
  4006.  MP> (under 30 lines of C code), please call our BBS or
  4007.  
  4008. WATCOM has doube byte character support.  If you would like,you could send us
  4009. the program and we could run it here for
  4010. you.
  4011.  
  4012.  
  4013. Kevin Kitsemetry
  4014. WATCOM TECHNICAL SUPPORT
  4015.  
  4016. *** This is a reply to #1744.
  4017.  
  4018.  
  4019. From:    Kevin Kitsemetry                       Rec'd
  4020. To:      Joe Friedman                           Msg #1750, Oct-21-93 04:05PM
  4021. Subject: ASPI driver for c++ 32
  4022.  
  4023.  JF> I'm looking for an ASPI (Advanced SCSI Programming
  4024.  JF> Interface) driver that will work for programs written
  4025.  JF> in the c++ 32-bit compiler.  I've seen ones for
  4026.  JF> standard DOS and OS/2, but I need one for the 4GW DOS
  4027.  JF> extender.  Any ideas on where I might find one?  So
  4028.  JF> far, I have not been able to get a response from
  4029.  JF> Adaptec, and thought someone at WATCOM might have some
  4030.  JF> other ideas.
  4031.  
  4032. I have checked with our manager for Independent Software Vendor Support,Roger
  4033. Kehl.  He does not know of any products that will do this, but you may contact
  4034. him directly by phone if you wish to have him call one of these companies that
  4035. you mentioned in your message.  Our phone number here 1-519-886-3700.
  4036.  
  4037.  
  4038. Kevin Kitsemetry
  4039. WATCOM TECHNICAL SUPPORT
  4040.  
  4041. *** This is a reply to #1746.
  4042.  
  4043.  
  4044. From:    Kevin Kitsemetry                       Rec'd
  4045. To:      Paul Tletski                           Msg #1751, Oct-21-93 03:30PM
  4046. Subject: What is _wstart?
  4047.  
  4048.  PT> Kevin,
  4049.  
  4050.  PT> I've been porting some code from zApp application framework to use the
  4051.  PT> Watcom compiler  and I've been encountering the
  4052.  PT> following undefined link reference which I believe is
  4053.  PT> generated somehow by the Watcom compiler.  I'm putting
  4054.  PT> together some DOS applications which use zApp. zApp is
  4055.  PT> more or less a Windows replacer, supporting a large
  4056.  PT> amount of the Windows API.  Is _wstart a Watcom
  4057.  PT> generated symbol or label for some Window's
  4058.  PT> dependency?  I don't see it in any of the simple DOS
  4059.  PT> programs I've put together so far.
  4060.  
  4061. Yes, it is a WATCOM generated symbol.  You can find them in the \LIB386\WIN
  4062. libraries.
  4063.  
  4064.  
  4065. Kevin Kitsemetry
  4066. WATCOM TECHNICAL SUPPORT
  4067.  
  4068. *** This is a reply to #1747.
  4069.  
  4070.  
  4071. From:    Ronald Schellberg                      Rec'd
  4072. To:      Matthew Heinze                         Msg #1752, Nov-03-93 01:17PM
  4073. Subject: Program load time under windows vs dos
  4074.  
  4075. KK> Internal Report #8457
  4076.  
  4077.  
  4078. I uploaded a file called 'loadtime.zip',  it contains the program, a link
  4079. response file, two objects and two libraries.  The program takes several
  4080. minutes to load in a dos window and about 10 seconds with dos4gvm=1 set in DOS
  4081. 5.0.  My machine is a model 95 ibm 486 with 18 MB of real memory.  To recreate
  4082. the problem just execute 'plot8lj3'.  I have been using wlinkp to link the
  4083. program.  I have had problems in the past with wlink.
  4084.  
  4085. MH> Customer contacted by phone.  Problem appears to be related to temporary
  4086. MH> Windows swap file on an extremely fragmented hard disk.
  4087.  
  4088.  
  4089. From:    John Lansdale                          Rec'd
  4090. To:      Kevin Kitsemetry                       Msg #1753, Oct-22-93 01:41AM
  4091. Subject: malloc() and A-level patches
  4092.  
  4093. I still haven't received the A-level patches by mail and was wondering
  4094. if you could please check into this for me. Thanks!
  4095.  
  4096.  
  4097. *** This is a reply to #1728.  *** See also #1763.
  4098.  
  4099.  
  4100. From:    Solaroli Matteo                        Rec'd
  4101. To:      Kevin Kitsemetry                       Msg #1754, Oct-22-93 07:14AM
  4102. Subject: problem using interrupt
  4103.  
  4104.  
  4105.  
  4106. Problem handling interrupt.
  4107. If an interrupt handler call a function with arguments the program fails and
  4108. the computer crashes.
  4109. I'm use :
  4110. Op. Sys.        : MS-DOS V 6.0
  4111. Dos Extender    : DOS4GW V 1.2
  4112. C compiler      : WCC386 V 9.5
  4113. Option compiler : wcl386 /d2 <filename>
  4114.  
  4115.  
  4116. The program is the follow :
  4117.  
  4118. #include <dos.h>
  4119. #include <stdlib.h>
  4120.  
  4121.  
  4122. void (__interrupt __far *oldhandler)();
  4123. void __interrupt __far handler();
  4124.  
  4125. char buffer1[50] = "";
  4126. short count = 0;
  4127. short intcount = 0;
  4128.  
  4129. main()
  4130. {
  4131.  
  4132.    oldhandler = _dos_getvect(0x1c);
  4133.    _dos_setvect(0x1c, handler);
  4134.  
  4135.    do
  4136.       {
  4137.       }
  4138.    while (!intcount);
  4139.  
  4140.    printf("String    : %s\n",buffer1);
  4141.    printf("Count     : %d\n",count);
  4142.    printf("IntCount  : %d\n",intcount);
  4143.    _dos_setvect(0x1c, oldhandler);
  4144. }
  4145.  
  4146.  
  4147. void __interrupt __far handler()
  4148. {
  4149.  
  4150.  
  4151.    pass1(buffer1);            // pass a string address
  4152.    pass2(&count);             // pass a short pointer
  4153.    intcount++;
  4154.  
  4155.    _chain_intr(oldhandler);
  4156. }
  4157.  
  4158.  
  4159. void pass1(char *ptr)
  4160. {
  4161.    strcpy(ptr, "TEST OK");
  4162. }
  4163.  
  4164.  
  4165. void pass2(short *count)
  4166. {
  4167.    (*count)++;
  4168. }
  4169.  
  4170.  
  4171. If I delete the pass1() call the program runs correctly with the following
  4172. outputs :
  4173. String     :
  4174. Count      : 1
  4175. IntCount   : 1
  4176.  
  4177. otherwise the computer crashes.
  4178. I think that the segment used to refernce the parameter is SS, and normally
  4179. it is equal to DS (Flat Memory Model USER MANUAL pag. 243).In this
  4180. case it is changed by the DOS4GW when the interrupt occours (USER MANUAL
  4181. pag. 339).
  4182. When I force the argument to a __far pointer the program runs correctly, but
  4183. it is
  4184. necessary to modify the function prototype. I can not do it some time because
  4185. I have not the sources of all the functions I need.
  4186. Is there any solution ?
  4187.  
  4188.  
  4189. Please answer us soon as possible.
  4190. I am looking forward to ear from you.
  4191.  
  4192.  
  4193. *** See also #1758.
  4194.  
  4195.  
  4196. From:    Frank Feller                           Rec'd
  4197. To:      Kevin Kitsemetry                       Msg #1755, Oct-22-93 08:10AM
  4198. Subject: C library func write(), mode O_BINARY
  4199.  
  4200. Dear Kevin Kitsemetry,
  4201.  
  4202. I'm a little bit angry that you have left all my faximiles and BBS
  4203. messages unreplied.
  4204. You wrote my in your fax from 09/24/93 that the problem have been fixed
  4205. in the A level patch of V9.5 C/C++32, but it isn't so.
  4206. My company need a fast solution!!
  4207.  
  4208. Why did you answer yet ????????
  4209.  
  4210. *** See also #1764.
  4211.  
  4212.  
  4213. From:    Paul Tletski                           Rec'd
  4214. To:      Kevin Kitsemetry                       Msg #1756, Oct-22-93 08:56AM
  4215. Subject: One more time...
  4216.  
  4217. Kevin,
  4218.  
  4219. Perhaps I wasn't clear enough about the problem I'm having with the unresolved
  4220. linker symbol _wstart.  Please note that I am NOT building a Windows
  4221. application.  I am using an application framework which supports the Windows
  4222. API, but the executables run under <<DOS>>.  My build process is in no way
  4223. dependent upon any Windows executable format.  I repeat, it is strictly a DOS
  4224. apllication which utilizes the Windows API.  I do not understand why the
  4225. symbol _wstart is a referenced symbol if I am not compiling & linking a
  4226. Windows application.
  4227.  
  4228. Thanks.
  4229.  
  4230. Paul Tletski
  4231. Allen-Bradley Co.
  4232. Highland Hts., OH
  4233.  
  4234. *** See also #1765.
  4235.  
  4236.  
  4237. From:    Anthony Scian                          Rec'd
  4238. To:      Paul Tletski                           Msg #1757, Oct-22-93 09:58AM
  4239. Subject: What is _wstart?
  4240.  
  4241.  PT> I've been porting some code from zApp application framework to use the
  4242.  PT> Watcom compiler  and I've been encountering the
  4243.  PT> following undefined link reference which I believe is
  4244.  PT> generated somehow by the Watcom compiler.  I'm putting
  4245.  PT> together some DOS applications which use zApp. zApp is
  4246.  PT> more or less a Windows replacer, supporting a large
  4247.  PT> amount of the Windows API.  Is _wstart a Watcom
  4248.  PT> generated symbol or label for some Window's
  4249.  PT> dependency?  I don't see it in any of the simple DOS
  4250.  PT> programs I've put together so far.
  4251.  
  4252. "_wstart" is a reference that causes the Windows libraries to be linked in. It
  4253. is triggered by compiling code with a WinMain() function.  This is a reserved
  4254. name for Windows programs.  If you do not want the WATCOM Windows libraries to
  4255. be linked in, create a dummy variable called "wstart". This should satisfy the
  4256. linker.
  4257.  
  4258. Anthony
  4259.  
  4260. *** This is a reply to #1747.
  4261.  
  4262.  
  4263. From:    Anthony Scian                          Rec'd
  4264. To:      Solaroli Matteo                        Msg #1758, Oct-22-93 10:03AM
  4265. Subject: problem using interrupt
  4266.  
  4267.  SM>
  4268.  SM>
  4269.  SM> Problem handling interrupt.
  4270.  SM> If an interrupt handler call a function with arguments
  4271.  SM> the program fails and
  4272.  SM> the computer crashes.
  4273.  SM> I'm use :
  4274.  SM> Op. Sys.        : MS-DOS V 6.0
  4275.  SM> Dos Extender    : DOS4GW V 1.2
  4276.  SM> C compiler      : WCC386 V 9.5
  4277.  SM> Option compiler : wcl386 /d2 <filename>
  4278.  SM>
  4279.  SM>
  4280.  SM> The program is the follow :
  4281.  SM>
  4282.  SM> #include <dos.h>
  4283.  SM> #include <stdlib.h>
  4284.  SM>
  4285.  SM>
  4286.  SM> void (__interrupt __far *oldhandler)();
  4287.  SM> void __interrupt __far handler();
  4288.  SM>
  4289.  SM> char buffer1[50] = "";
  4290.  SM> short count = 0;
  4291.  SM> short intcount = 0;
  4292.  SM>
  4293.  SM> main()
  4294.  SM> {
  4295.  SM>
  4296.  SM>    oldhandler = _dos_getvect(0x1c);
  4297.  SM>    _dos_setvect(0x1c, handler);
  4298.  SM>
  4299.  SM>    do
  4300.  SM>       {
  4301.  SM>       }
  4302.  SM>    while (!intcount);
  4303.  SM>
  4304.  SM>    printf("String    : %s\n",buffer1);
  4305.  SM>    printf("Count     : %d\n",count);
  4306.  SM>    printf("IntCount  : %d\n",intcount);
  4307.  SM>    _dos_setvect(0x1c, oldhandler);
  4308.  SM> }
  4309.  SM>
  4310.  SM>
  4311.  SM> void __interrupt __far handler()
  4312.  SM> {
  4313.  SM>
  4314.  SM>
  4315.  SM>    pass1(buffer1);            // pass a string address
  4316.  SM>    pass2(&count);             // pass a short pointer
  4317.  SM>    intcount++;
  4318.  SM>
  4319.  SM>    _chain_intr(oldhandler);
  4320.  SM> }
  4321.  SM>
  4322.  SM>
  4323.  SM> void pass1(char *ptr)
  4324.  SM> {
  4325.  SM>    strcpy(ptr, "TEST OK");
  4326.  SM> }
  4327.  SM>
  4328.  SM>
  4329.  SM> void pass2(short *count)
  4330.  SM> {
  4331.  SM>    (*count)++;
  4332.  SM> }
  4333.  SM>
  4334.  SM>
  4335.  SM> If I delete the pass1() call the program runs
  4336.  SM> correctly with the following
  4337.  SM> outputs :
  4338.  SM> String     :
  4339.  SM> Count      : 1
  4340.  SM> IntCount   : 1
  4341.  SM>
  4342.  SM> otherwise the computer crashes.
  4343.  SM> I think that the segment used to refernce the
  4344.  SM> parameter is SS, and normally
  4345.  SM> it is equal to DS (Flat Memory Model USER MANUAL pag. 243).In this
  4346.  SM> case it is changed by the DOS4GW when the interrupt occours (USER MANUAL
  4347.  SM> pag. 339).
  4348.  SM> When I force the argument to a __far pointer the
  4349.  SM> program runs correctly, but it is
  4350.  SM> necessary to modify the function prototype. I can not
  4351.  SM> do it some time because
  4352.  SM> I have not the sources of all the functions I need.
  4353.  SM> Is there any solution ?
  4354.  
  4355. WATCOM C/C++ compiles an __interrupt function so that assumes that SS != DS.
  4356. If you call any functions from your interrupt routine, they must all be
  4357. compiled to assume the same thing because they will be called during an
  4358. interrupt also.  Compile all modules that contain functions that are called
  4359. from interrupt routines with the compiler option -zu or as you found out pass
  4360. far pointers and don't let the function access global data by name.
  4361.  
  4362. Anthony
  4363.  
  4364. *** This is a reply to #1754.
  4365.  
  4366.  
  4367. From:    Roman Lewkow                           Rec'd
  4368. To:      Kevin Kitsemetry                       Msg #1759, Oct-22-93 10:53AM
  4369. Subject: Please check the DPMI 800 part of this message
  4370.  
  4371.  KB> As far as this damn board goes, I take it that
  4372.  KB> the general idea is to
  4373.  KB> use DPMI function 800 that Kevin K posted some sample
  4374.  KB> code for a couple of weeks ago. I saw that and figured
  4375.  KB> "hey this looks like it might be useful", so I tried
  4376.  KB> it and everything seemed ok at 4 meg, but when I
  4377.  
  4378. Could you please tell me where was this sample code posted ?
  4379.  
  4380. thanks, Roman
  4381.  
  4382. *** This is a reply to #1738.  *** See also #1766.
  4383.  
  4384.  
  4385. From:    Christer Palm
  4386. To:      Matthew Heinze                         Msg #1760, Oct-22-93 11:05AM
  4387. Subject: Re-post of #132 in area 11, since this also concerns c/c++32 9.5
  4388.  
  4389. Guess I have to wait for the B-level patches, since the A level patches was
  4390. recently released.  OK, The workaround was really simple, so i'll guess I'm
  4391. happy with it.
  4392.  
  4393.  Cheers
  4394.   / Christer
  4395.  
  4396. *** This is a reply to #1745.
  4397.  
  4398.  
  4399. From:    Howard Keller
  4400. To:      Watcom                                 Msg #1761, Oct-22-93 03:09PM
  4401. Subject: Zinc Application Framework 3.5 and Watcom C++32 for NT
  4402.  
  4403. I'm not sure who to address this letter to.
  4404. I'm trying to use the Zinc Application Framework 3.5 to build applications for
  4405. both OS/2 2.1 and WindowsNT.  No problem with OS/2, but Zinc doesn't provide
  4406. libraries for the 9.5 WindowsNT compiler.  When inquiring about this from Zinc
  4407. teck support, I was told that they have enperienced "serious problems" with
  4408. the Watcom C++32 9.5 NT compiler and they don't plan to support it until the
  4409. problems have been resolved.  I was unable to find out the nature of the
  4410. problems.  Is anyone aware of this at Watcom and if there is a problem, what's
  4411. the time frame for repair?
  4412.  
  4413. *** See also #1826.
  4414.  
  4415.  
  4416. From:    Matthias Zander
  4417. To:      Kevin Semetry                          Msg #1762, Oct-22-93 05:31PM
  4418. Subject: Var.Access Pmode Rmode
  4419.  
  4420. U R G E N T
  4421.  
  4422. Dear Kevin,
  4423. In about two weeks we've to finish our actual product change from Borland C3.1
  4424. to your C/C++ 32 Compiler. We've great problems with the bimodal ISR for
  4425. serial communications. We have done our job  before successfully with the
  4426. PHARLAP 286-DOS Extender. Due to your bimodal.c example we've understood how
  4427. to install and register the real and protected mode ISR's. Unfortunately we
  4428. don't know how to access variables (e.g. the receive queue) from the real mode
  4429. as well as from the protected mode and how to install such ones to achieve the
  4430. bimodal access.
  4431.  
  4432. We assume that these variables have to be installed in the DOS memory so that
  4433. the real mode ISR is able to access them. How could this be done? Are these
  4434. variables accessable from the protected mode also? At the compiling time these
  4435. variables must be known to the real mode ISR. How can this problem be handled?
  4436.  
  4437. Thaks in advance.
  4438.  
  4439. With best regards, Matthias Zander, Karsten Kiehlmann
  4440.                    c.o. IAV GmbH Dept. Electronic
  4441.                    Carnotstrasse 1
  4442.                    D-10587 Berlin
  4443.                    F.R.G.
  4444.                    Tel. +49 - 30 - 39 08 08 - 54
  4445.                    Fax. +49 - 30 - 39 08 08 - 90
  4446.  
  4447. *** See also #1789.
  4448.  
  4449.  
  4450. From:    Kevin Kitsemetry
  4451. To:      John Lansdale                          Msg #1763, Oct-22-93 06:33PM
  4452. Subject: malloc() and A-level patches
  4453.  
  4454.  JL> I still haven't received the A-level patches by mail and was wondering
  4455.  JL> if you could please check into this for me. Thanks!
  4456.  
  4457. They were shipped out on the 21st of Oct.
  4458.  
  4459.  
  4460. Kevin Kitsemetry
  4461. WATCOM TECHNICAL SUPPORT
  4462.  
  4463. *** This is a reply to #1753.
  4464.  
  4465.  
  4466. From:    Kevin Kitsemetry                       Rec'd
  4467. To:      Frank Feller                           Msg #1764, Oct-22-93 06:45PM
  4468. Subject: C library func write(), mode O_BINARY
  4469.  
  4470.  FF> Dear Kevin Kitsemetry,
  4471.  FF>
  4472.  FF> I'm a little bit angry that you have left all my faximiles and BBS
  4473.  FF> messages unreplied.
  4474.  FF> You wrote my in your fax from 09/24/93 that the problem have been fixed
  4475.  FF> in the A level patch of V9.5 C/C++32, but it isn't so.
  4476.  FF> My company need a fast solution!!
  4477.  
  4478. To my knowledge, you have sent me two faxes, and two BBS messages.  The BBS
  4479. messages were in Area 2, numbers 1767 and 1889.  I have since taken the time
  4480. to go back and make sure that I have read and replied to these messages.  Sure
  4481. enough, I had.  They are messages numbered 1786 and 1897 respectively.
  4482.  
  4483. In my second message to you I had indicated that I had received your fax,and
  4484. answered you on this BBS.  As I stated then, if you have the C/C++ compiler,
  4485. then the C32DOS_A.ZIP is the WRONG file!!!  You require C32_A.ZIP.
  4486.  
  4487. I was told by the head developer that your problem would be solved in the A-
  4488. level patches.  If it still is not solved once you have received the correct
  4489. file, please let me know and I will bring it to his attention once again.
  4490.  
  4491.  
  4492. Kevin Kitsemetry
  4493. WATCOM TECHNICAL SUPPORT
  4494.  
  4495. *** This is a reply to #1755.
  4496.  
  4497.  
  4498. From:    Kevin Kitsemetry                       Rec'd
  4499. To:      Paul Tletski                           Msg #1765, Oct-22-93 06:51PM
  4500. Subject: One more time...
  4501.  
  4502.  PT> Kevin,
  4503.  
  4504.  PT> Perhaps I wasn't clear enough about the problem I'm having with the
  4505.  PT> unresolved linker symbol _wstart.  Please note that I
  4506.  PT> am NOT building a Windows application.  I am using an
  4507.  
  4508. You were defining a WINMAIN function in your program, so the compiler assumed
  4509. that you are building a Windows function.  You must define a dummy _wstart
  4510. symbol to get around the problem, or rename the function to something else.
  4511.  
  4512.  
  4513. Kevin Kitsemetry
  4514. WATCOM TECHNICAL SUPPORT
  4515.  
  4516. *** This is a reply to #1756.
  4517.  
  4518.  
  4519. From:    Jason Blochowiak                       Rec'd
  4520. To:      Kevin Kitsemetry                       Msg #1768, Oct-23-93 02:50PM
  4521. Subject: Locking for VM
  4522.  
  4523.  Hi again. I'm working on a project that uses interrupts fairly extensively -
  4524. it wouldn't be an easy task to find everything that gets touched by something
  4525. in an ISR. It would be acceptable to me to require enough real RAM (under DPMI
  4526. or VMM) to have the entire code & data "segments" locked down, as they don't
  4527. comprise the bulk of memory that my program deals with. I don't recall seeing
  4528. documentation anywhere on how to do this (or, for that matter, how to lock
  4529. down a specific function). I can certainly dredge through the DPMI docs
  4530. myself,but I need to know how to determine which addresses need to be passed
  4531. to the DPMI functions. Thanks in advance,
  4532.  
  4533.  Jason
  4534.  
  4535. *** See also #1792.
  4536.  
  4537.  
  4538. From:    Jason Blochowiak                       Rec'd
  4539. To:      Kevin Kitsemetry                       Msg #1769, Oct-23-93 04:00PM
  4540. Subject: Assembly optimizer
  4541.  
  4542.  This may seem like a somewhat strange question, but... Has Watcom considered
  4543. offering an assembly optimizer? It would seem that it would be possible to
  4544. pass hand-written assembly through parts of the optimizer in the code
  4545. generator. The reason I think this would be useful: Although I can write
  4546. faster code in asm than I can in C (due to the fact that C doesn't allow for
  4547. the tersest possible expression of a code goal), and I can do a good job of
  4548. register allocation, keeping track of the possibilities for things like
  4549. pipeline stalls requires a bit more time than I can usually afford to spend. I
  4550. would think that an optimizer would be able to squeeze out a few more cycles,
  4551. and if it would do things like enforcing optimal register use, it could be
  4552. quite helpful. I wouldn't want this to go directly to object code - I'd want
  4553. it to dump assembly source back out, so I could examine & modify it further.
  4554. If this could be done now (even if the method is somewhat kludgy), I'd be
  4555. interested in hearing how.
  4556.  
  4557.  Jason
  4558.  
  4559. *** See also #1793.
  4560.  
  4561.  
  4562. From:    Peter Weatherall                       Rec'd
  4563. To:      Kevin Kitsemetry                       Msg #1770, Oct-25-93 06:01AM
  4564. Subject: Mixed C/C++
  4565.  
  4566. With an application built from C and C++ compiled modules, is there some way
  4567. of accessing global data defined in a C+++ module from a C module (or
  4568. assembler). Currently, when I comile with wpp386 the global data is given a
  4569. type encoded name and so the reference from C is unresolved by the linker.
  4570.  
  4571. *** See also #1771.
  4572.  
  4573.  
  4574. From:    Anthony Scian                          Rec'd
  4575. To:      Peter Weatherall                       Msg #1771, Oct-25-93 05:32PM
  4576. Subject: Mixed C/C++
  4577.  
  4578.  PW> With an application built from C and C++ compiled
  4579.  PW> modules, is there some way of accessing global data
  4580.  PW> defined in a C+++ module from a C module (or
  4581.  PW> assembler). Currently, when I comile with wpp386 the
  4582.  PW> global data is given a type encoded name and so the
  4583.  PW> reference from C is unresolved by the linker.
  4584.  
  4585. In C++, if you want to export data so that C and ASM code can reference
  4586. it,simply export it as extern "C".
  4587.  
  4588. extern "C" {
  4589.     int data;
  4590.     int a[] = { 1, 2, 3, 4 };
  4591. };
  4592.  
  4593. *** This is a reply to #1770.
  4594.  
  4595.  
  4596. From:    Kevin Blenkinsopp                      Rec'd
  4597. To:      Roman Lewkow                           Msg #1772, Oct-25-93 06:58PM
  4598. Subject: Please check the DPMI 800 part of this message
  4599.  
  4600. Roman,
  4601.  
  4602. I can't actually remember exactly where I got it from, but if I remember right
  4603. it was a reply of Kevin's to someone else that I snagged with the terminal
  4604. program I use. I'll throw it in file area 12 for you.
  4605.  
  4606. Kevin B
  4607.  
  4608. *** This is a reply to #1759
  4609.  
  4610. From:    Thomas B. Pollard
  4611. To:      Brian Schriber                         Msg #1774, Oct-26-93 07:27AM
  4612. Subject: Wvideo Problem See (1725)
  4613.  
  4614. Message 1725 was realy for you.  Please try it and let me know how you
  4615. do.
  4616.  
  4617.  
  4618. From:    Stefano Lena
  4619. To:      All                                    Msg #1776, Oct-26-93 02:58PM
  4620. Subject: problems using Dyn ESQL (Watcom)
  4621.  
  4622. I have execution problems and data corruption using Watcom C32 9.5 and Watcom
  4623. SQL. We are developing applications under DOS6.0 using dynamic ESQL. After
  4624. compiling our applications with C32 9.5 compiler we have had problems: the
  4625. dynamics calls don't function well, a second call (select statement) over
  4626. write previous variables.
  4627. We are using the DBLIBWFG SQL Library and all programs and libraries are
  4628. compiled with these options:
  4629. wcl386 /p <module_name>
  4630. sqlpp -n -o dos32 <module_name>
  4631. wcl386 /c /w0 /omaxnet /zpi /4r /mf <module_name>
  4632. and our programs are linked with this command:
  4633. wlink <modules> system dos4g option stack=32.
  4634.  
  4635. I have also send a fax to the Watcom Tecnical Support about this problem, if
  4636. anybody know the answer, please call me back on this message area.
  4637. Thanks. I need a quick answer !
  4638.  
  4639. *** See also #1782.
  4640.  
  4641.  
  4642. From:    Chris Bennett                          Rec'd
  4643. To:      Kevin Kitsemetry                       Msg #1777, Oct-27-93 01:05AM
  4644. Subject: GP Fault when writing to 0a0000
  4645.  
  4646. Kevin, as it turns out my design required a different approach that alleviated
  4647. the problem.  I now only do direct DMAs into screen video RAM.  Out of
  4648. interest, my code was not generating an interrupt at all... simply writing a
  4649. sequence of bytes to (byte ptr) addresses within a0000 range.  It could be due
  4650. to the fact that the code segment was byte aligned, but I never went back to
  4651. check it out.  My app didn't require it in the end.  My apologies for not
  4652. getting back to you earlier.  I only think to logon when I'm desperate (or
  4653. checking for rev A patches as I'm doing now).  Thanks again.  /Chris
  4654.  
  4655. *** This is a reply to #1259.
  4656.  
  4657.  
  4658. From:    Anthony Scian                          Rec'd
  4659. To:      Stefano Lena                           Msg #1782, Oct-27-93 09:54AM
  4660. Subject: problems using Dyn ESQL (Watcom)
  4661.  
  4662.  SL> I have execution problems and data corruption using
  4663.  SL> Watcom C32 9.5 and Watcom SQL. We are developing
  4664.  SL> applications under DOS6.0 using dynamic ESQL. After
  4665.  SL> compiling our applications with C32 9.5 compiler we
  4666.  SL> have had problems: the dynamics calls don't function
  4667.  SL> well, a second call (select statement) over write
  4668.  SL> previous variables.
  4669.  SL> We are using the DBLIBWFG SQL Library and all programs
  4670.  SL> and libraries are compiled with these options:
  4671.  SL> wcl386 /p <module_name>
  4672.  SL> sqlpp -n -o dos32 <module_name>
  4673.  SL> wcl386 /c /w0 /omaxnet /zpi /4r /mf <module_name>
  4674.  SL> and our programs are linked with this command:
  4675.  SL> wlink <modules> system dos4g option stack=32.
  4676.  
  4677. Shouldn't you have option stack=32k?
  4678.  
  4679. *** This is a reply to #1776.  *** See also #1796.
  4680.  
  4681.  
  4682. From:    Jim Ehrismann                          Rec'd
  4683. To:      Kevin Kitsemetry                       Msg #1787, Oct-27-93 02:05PM
  4684. Subject: Graphics support
  4685.  
  4686. Hi Kevin.
  4687.  
  4688.         I have a customer with a Genoa WINDOWSVGA24 model 8500 VL (1M)
  4689. graphics card. He cannot run our software in any mode other than 640x480x16
  4690. colours. We have C32 for DOS 9.5a. Can you help?
  4691.  
  4692.                                         Jim
  4693.  
  4694. *** See also #1799.
  4695.  
  4696.  
  4697. From:    Jim Ehrismann                          Rec'd
  4698. To:      Kevin Kitsemetry                       Msg #1788, Oct-27-93 02:12PM
  4699. Subject: trig function bugs
  4700.  
  4701. /*- FILE TRIGTEST.C
  4702.  
  4703. compiler: C32 for DOS 9.5a
  4704.  
  4705. build: WCL386 TRIGTEST
  4706.  
  4707. run: TRIGTEST
  4708.  
  4709.     I have not yet inspected behaviour of other trig functions. I did notice
  4710.     that atanh() shows this same behaviour in C/386 9.0e and C 9.0.
  4711.  
  4712.  
  4713.                         Jim Ehrismann
  4714.                         Atlantis Scientific Systems Group Inc.
  4715.                         (613) 727-1087
  4716. -*/
  4717.  
  4718. #include <stdio.h>
  4719. #include <stdlib.h>
  4720. #include <math.h>
  4721.  
  4722.  
  4723. #define PI          3.14159265358979323846
  4724. #define PI_BY_TWO   ( PI / 2.0 )
  4725. #define PI_BY_FOUR  ( PI / 4.0 )
  4726.  
  4727.  
  4728. main()
  4729. {
  4730.     double x;
  4731.  
  4732.     x = -PI_BY_FOUR;
  4733.     printf( "tan(%6.5g)=%6.5g\n", x, tan( x ) );    /*- sign is OK -*/
  4734.     x = PI_BY_FOUR;
  4735.     printf( "tan(%6.5g)=%6.5g\n", x, tan( x ) );    /*- sign is OK -*/
  4736.  
  4737.     x = -PI_BY_TWO;
  4738.     printf( "tan(%6.5g)=%6.5g\n", x, tan( x ) );    /*- sign is wrong -*/
  4739.     x = PI_BY_TWO;
  4740.     printf( "tan(%6.5g)=%6.5g\n", x, tan( x ) );    /*- sign is wrong -*/
  4741.  
  4742.     x = -0.5;
  4743.     printf( "atanh(%6.5g)=%6.5g\n", x, atanh( x ) );    /*- sign is wrong -*/
  4744.     x = 0.5;
  4745.     printf( "atanh(%6.5g)=%6.5g\n", x, atanh( x ) );    /*- sign is wrong -*/
  4746.  
  4747. }
  4748.  
  4749. *** See also #1800.
  4750.  
  4751.  
  4752. From:    Kevin Kitsemetry
  4753. To:      Matthias Zander                        Msg #1789, Oct-27-93 04:56PM
  4754. Subject: Var.Access Pmode Rmode
  4755.  
  4756.  MZ> communications. We have done our job  before
  4757.  MZ> successfully with the PHARLAP 286-DOS Extender. Due to
  4758.  MZ> your bimodal.c example we've understood how to install
  4759.  MZ> and register the real and protected mode ISR's.
  4760.  MZ> Unfortunately we don't know how to access variables
  4761.  MZ> (e.g. the receive queue) from the real mode as well as
  4762.  MZ> from the protected mode and how to install such ones
  4763.  MZ> to achieve the bimodal access.
  4764.  
  4765.  MZ> We assume that these variables have to be installed in
  4766.  MZ> the DOS memory so that the real mode ISR is able to
  4767.  MZ> access them. How could this be done? Are these
  4768.  MZ> variables accessable from the protected mode also? At
  4769.  MZ> the compiling time these variables must be known to
  4770.  MZ> the real mode ISR. How can this problem be handled?
  4771.  
  4772. You can set up a buffer using DPMI function 100h.  This allocates a real mode
  4773. buffer, which you can set a pointer to from protected mode.
  4774.  
  4775.  
  4776. Kevin Kitsemetry
  4777. WATCOM TECHNICAL SUPPORT
  4778.  
  4779. *** This is a reply to #1762.  *** See also #1861.
  4780.  
  4781.  
  4782. From:    Rainer Schupp
  4783. To:      Tech Support                           Msg #1790, Oct-27-93 04:58PM
  4784. Subject: assembler pragma
  4785.  
  4786. Hello,
  4787.  
  4788. I've just changed from C V9.0 E-Level-Patch to V9.5,
  4789. everything did get compiled except some hard-coded assembly parts.
  4790.  
  4791. For example:
  4792.  
  4793.  
  4794. static unsigned long  DSAliasFor2F;
  4795. void far* DoCallDriverPointer;
  4796.  
  4797. void far* CallDriverAsm();
  4798. #pragma aux CallDriverAsm = \
  4799. "push es","mov ecx,[DSAliasFor2F+2]","call dword ptr
  4800. [DoCallDriverPointer]","pop es"  \ modify [ebx ecx];
  4801.  
  4802. void far* CallDriver(long func)
  4803. {
  4804.  func = func;
  4805.  return CallDriverAsm();
  4806. }
  4807.  
  4808.  
  4809. This is the message:
  4810. Error! E1156: Assembler error: 'Invalid indirect memory operand'
  4811.  
  4812.  
  4813. Why is it now an error?
  4814.  
  4815. *** See also #1801.
  4816.  
  4817.  
  4818. From:    Jerry Rice                             Rec'd
  4819. To:      Jim Ehrismann                          Msg #1791, Oct-28-93 01:35AM
  4820. Subject: Graphics support
  4821.  
  4822. JE>Hi Kevin.
  4823.  
  4824. JE>        I have a customer with a Genoa WINDOWSVGA24 model 8500 VL (1M)
  4825. JE>graphics card. He cannot run our software in any mode other than 640x480x16
  4826. JE>colours. We have C32 for DOS 9.5a. Can you help?
  4827.                                         Jim
  4828.  
  4829.       As a temporary  fix, you might have him  load his VESA
  4830. Driver. Watcom works fine with VESA.COM on a Genoa I have at
  4831. work, 256 colors at 1024x768. Note that he has to load it as
  4832. a tsr first, before running the Watcom App.
  4833.  
  4834.                                        Jer
  4835. ___
  4836.  X SLMR 2.1a X
  4837.  
  4838.  
  4839. From:    Kevin Kitsemetry                       Rec'd
  4840. To:      Jason Blochowiak                       Msg #1792, Oct-28-93 11:55AM
  4841. Subject: Locking for VM
  4842.  
  4843.  JB> RAM (under DPMI or VMM) to have the entire code & data
  4844.  JB> "segments" locked down, as they don't comprise the
  4845.  JB> bulk of memory that my program deals with. I don't
  4846.  JB> recall seeing documentation anywhere on how to do this
  4847.  JB> (or, for that matter, how to lock down a specific
  4848.  JB> function). I can certainly dredge through the DPMI
  4849.  JB> docs myself,but I need to know how to determine which
  4850.  JB> addresses need to be passed to the DPMI functions.
  4851.  JB> Thanks in advance,
  4852.  
  4853.  
  4854. Locking and Unlocking linear regions are DPMI functions 600h and 601h
  4855. respectively.  We don't have an example of using
  4856. these functions, but they are outlined in the 0.9 DPMI spec,available on this
  4857. BBS.
  4858.  
  4859.  
  4860. Kevin Kitsemetry
  4861. WATCOM TECHNICAL SUPPORT
  4862.  
  4863. *** This is a reply to #1768.  *** See also #1795.
  4864.  
  4865.  
  4866. From:    Kevin Kitsemetry                       Rec'd
  4867. To:      Jason Blochowiak                       Msg #1793, Oct-28-93 12:00PM
  4868. Subject: Assembly optimizer
  4869.  
  4870.  JB>  This may seem like a somewhat strange question, but... Has Watcom
  4871.  JB> considered offering an assembly optimizer? It would
  4872.  JB> seem that it would be possible to pass hand-written
  4873.  JB> assembly through parts of the optimizer in the code
  4874.  JB> generator. The reason I think this would be useful:
  4875.  JB> Although I can write faster code in asm than I can in
  4876.  JB> C (due to the fact that C doesn't allow for the
  4877.  JB> tersest possible expression of a code goal), and I can
  4878.  JB> do a good job of register allocation, keeping track of
  4879.  JB> the possibilities for things like pipeline stalls
  4880.  JB> requires a bit more time than I can usually afford to
  4881.  JB> spend. I would think that an optimizer would be able
  4882.  JB> to squeeze out a few more cycles, and if it would do
  4883.  JB> things like enforcing optimal register use, it could
  4884.  JB> be quite helpful. I wouldn't want this to go directly
  4885.  JB> to object code - I'd want it to dump assembly source
  4886.  JB> back out, so I could examine & modify it further. If
  4887.  JB> this could be done now (even if the method is somewhat
  4888.  JB> kludgy), I'd be interested in hearing how.
  4889.  
  4890. I do not know of any development plans of this sort right
  4891. now, but I will pass your suggestion along to the
  4892. development team.
  4893.  
  4894.  
  4895. Kevin Kitsemetry
  4896. WATCOM TECHNICAL SUPPORT
  4897.  
  4898. *** This is a reply to #1769.
  4899.  
  4900.  
  4901. From:    Jason Blochowiak                       Rec'd
  4902. To:      Kevin Kitsemetry                       Msg #1795, Oct-28-93 02:54PM
  4903. Subject: Locking for VM
  4904.  
  4905.  As expected, the DPMI functions themselves aren't that big of a deal. What I
  4906. need to know is how to determine the values to pass - where the code for the
  4907. program resides & how long it is, and where the static data resides and how
  4908. long it is. I don't recall seeing how to determine these values on my previous
  4909. scans of the documentation - if I'm having a memory lapse, pointing me to the
  4910. right page in the docs (I have 9.5) would be entirely sufficient.
  4911.  
  4912.  Thanks,
  4913.   Jason
  4914.  
  4915. *** This is a reply to #1792.  *** See also #1825.
  4916.  
  4917.  
  4918. From:    Stefano Lena                           Rec'd
  4919. To:      Anthony Scian                          Msg #1796, Oct-28-93 04:24PM
  4920. Subject: problems using Dyn ESQL (Watcom)
  4921.  
  4922. Yes ! It's only a sintax problem in the message. 32k is ok. Thank you but this
  4923. in't the problem.
  4924.  
  4925. *** This is a reply to #1782.
  4926.  
  4927.  
  4928. From:    Kevin Kitsemetry
  4929. To:      Rainer Schupp                          Msg #1801, Nov-01-93 12:44PM
  4930. Subject: assembler pragma
  4931.  
  4932.  RS> Hello,
  4933.  
  4934.  
  4935.  
  4936.  RS> This is the message:
  4937.  RS> Error! E1156: Assembler error: 'Invalid indirect memory operand'
  4938.  
  4939.  
  4940. I am not sure what has changed.  The error is coming from the inline
  4941. assembler. Can you provide us with the complete module, so that I can
  4942. reproduce the message here?
  4943.  
  4944.  
  4945. Kevin Kitsemetry
  4946. WATCOM TECHNICAL SUPPORT
  4947.  
  4948. *** This is a reply to #1790.
  4949.  
  4950.  
  4951. From:    Peter Weatherall                       Rec'd
  4952. To:      Kevin Kitsemetry                       Msg #1803, Oct-29-93 05:47AM
  4953. Subject: Class Library & memory  models
  4954.  
  4955. Two questions regarding Watcom C/C++ 32:
  4956.  
  4957. 1 Is there any informatin available concerning re-entrancy (or not) of
  4958. components of the Watcom class library ? I have re-implemented new/delete +
  4959. malloc/free to operater in a multithreaded environment using a synchronisation
  4960. object, so the dynamic creation & destruction of objects does not itself cause
  4961. a re-entrancy kind of problem with free space management.
  4962.  
  4963. 2 Id there any significant difference between the small and flat memory models?
  4964.  
  4965. *** See also #1808.
  4966.  
  4967.  
  4968. From:    Mike Dijkema                           Rec'd
  4969. To:      Kevin Kitsemetry                       Msg #1804, Oct-29-93 07:01AM
  4970. Subject: BIMODAL
  4971.  
  4972. It appears that in the new dos4gw which came along with WC9.5 the bimodal
  4973. program won't run anymore. All serial IO is actually not working because
  4974. something appears to go wrong in the apssing up dan down of the interrupts. It
  4975. does though run on the old 9.0 version. Ok it is now possible to trap GP
  4976. faults, but apparently it is not yet ok...
  4977. Mike...
  4978.  
  4979. *** See also #1815.
  4980.  
  4981.  
  4982. From:    Anthony Scian                          Rec'd
  4983. To:      Peter Weatherall                       Msg #1808, Oct-29-93 10:33AM
  4984. Subject: Class Library & memory  models
  4985.  
  4986.  PW> Two questions regarding Watcom C/C++ 32:
  4987.  
  4988.  PW> 1 Is there any informatin available concerning re-
  4989.  PW> entrancy (or not) of components of the Watcom class
  4990.  PW> library ? I have re-implemented new/delete +
  4991.  PW> malloc/free to operater in a multithreaded environment
  4992.  PW> using a synchronisation object, so the dynamic
  4993.  PW> creation & destruction of objects does not itself
  4994.  PW> cause a re-entrancy kind of problem with free space
  4995.  PW> management.
  4996.  
  4997.  The multi-threaded versions of the library are reentrant, the others
  4998.  are not reentrant.  Use -bm if you want multi-threaded code to work.
  4999.  malloc/free are already enabled and reentrant in the multi-threaded
  5000.  library along with synchronized access to POSIX file handles, stdio
  5001.  file objects, etc.  Also some CLIB functions have thread-specific
  5002.  data so that threads cannot affect each other, an example of this
  5003.  is rand().
  5004.  
  5005.  PW> 2 Id there any significant difference between the
  5006.  PW> small and flat memory models?
  5007.  
  5008.  Yes.
  5009.  
  5010.  flat:  CS=DS=ES=SS=data=code
  5011.  small: CS=code DS=SS=data ES floats
  5012.  
  5013.  In flat, a wayward data pointer can corrupt code.  All of our libraries
  5014.  should work in the small model.
  5015.  
  5016. *** This is a reply to #1803.
  5017.  
  5018.  
  5019. From:    Nicos Skouras                          Rec'd
  5020. To:      Anthony Scian                          Msg #1810, Oct-29-93 12:10PM
  5021. Subject: WLINK Problem
  5022.  
  5023. Thanks for your effort
  5024. Nicos Skouras
  5025.  
  5026.  
  5027. From:    Rainer Schupp                          Rec'd
  5028. To:      Kevin Kitsemetry                       Msg #1812, Oct-31-93 07:52AM
  5029. Subject: msg 1790 + 1801
  5030.  
  5031. The provided code in msg #1790 is complete.
  5032. (Except the line breaks in the pragma aux,
  5033. check the backslashes). If compiled with
  5034. wcc386p test.c , it passes the 9.0 E-level
  5035. compiler with no warnings and no errors, but
  5036. it won't pass the 9.5 compiler.
  5037.  
  5038. *** See also #1817.
  5039.  
  5040.  
  5041.