DP Tool Club 15/CD_ASCQ_15_070894.iso/vrac/watcom.zip/WC931214.CAP

Internet Message Format | 1993-12-14 | 184KB

From:    Kevin Kitsemetry
To:      Mike Dijkema                           Msg #1815, Nov-01-93 03:21PM
Subject: BIMODAL

 MD> It appears that in the new dos4gw which came along
 MD> with WC9.5 the bimodal program won't run anymore. All
 MD> serial IO is actually not working because something
 MD> appears to go wrong in the apssing up dan down of the
 MD> interrupts. It does though run on the old 9.0 version.
 MD> Ok it is now possible to trap GP faults, but
 MD> apparently it is not yet ok...

You should make sure that you have applied the A-level
patch to the compiler, and that you get the new version
of BIMODAL.ZIP from the BBS.  This should solve your
problems with the Bimodal example.


Kevin Kitsemetry
WATCOM TECHNICAL SUPPORT

*** This is a reply to #1804.


From:    Kevin Kitsemetry                       Rec'd
To:      Rainer Schupp                          Msg #1817, Nov-01-93 03:54PM
Subject: msg 1790 + 1801

 RS> The provided code in msg #1790 is complete.
 RS> (Except the line breaks in the pragma aux,
 RS> check the backslashes). If compiled with
 RS> wcc386p test.c , it passes the 9.0 E-level
 RS> compiler with no warnings and no errors, but
 RS> it won't pass the 9.5 compiler.

I just compiled this example, and got 0 warning and 0 errors. Please make sure
you have the A-level patch applied to the
compiler.


Kevin Kitsemetry
WATCOM TECHNICAL SUPPORT

*** This is a reply to #1812.


From:    Matt Goheen                            Rec'd
To:      John Hinkley                           Msg #1818, Nov-01-93 05:33PM
Subject: C386 9.5

Geez, I read your message and kept muttering, yeah, Yeah!, YEAH!  We have
basically gone through ALL the same steps (and same problems) that you mention
(including the "hang" at startup w/DOS6 -- 5-7 seconds with my little 8Mb, as
well as the move to FlashTek X32).  Anyway, I don't have any solutions, but
you aren't alone...

        - Matt Goheen

*** This is a reply to #1137.


From:    Jerry Rice
To:      Kevin Kitsemetry                       Msg #1819, Nov-03-93 10:45AM
Subject: On Intel Code Builder

KK> Internal Report #9313


      Have you come up with  any solutions to the Intel Code Builder to Watcom
problem?

      The  basic problem  is that  I can't  use .rex  files. Intel no longer
accepts them.

      The only thing I can see from the manuals, both Watcom and Intel, is
that Intel can accept PharLaps Easy-OMF object format,  in  both  .obj  and
.lib.  Their  Lib32 can take a PharLap Easy-OMF  library and convert it  to
Intel Easy-OMF. Your  Womp.exe  can  take  a  Watcom  object  or library and
convert it  to PharLap Easy OMF.  But would it work  on your CLIBs.lib,...,
plus startup code? Then I could use wcc386 to compile to  watcom objects,
convert  these to Pharlap,  then convert  them  to  Intel,  then  link  them
with il32, which pastes on intel's extender. I doubt if it will work, since I
have   never  seen   any  converter   work  perfectly,  only acceptibly. That
is, your  Womp.exe will convert watcom .obj to pharlap, acceptible enough to
be accepted by pharlap, but not  necessarily  enough  for  Intel's  lib32  to
be able to convert it to Intel format.


      Anyway, I  entend to try  this, but I  need some info. Given  that  I
am  using  the  pentium switches and maximum optimization, 5s... What startup
and library modules would I have to convert, create. I noticed a couple of
.asm files in the startup directory. I have both tasm 3.0, 3.2 and ml 6.1. I
don't  know  whether  ml  can  create  a  pharlap easy omf directly or not,
but I do know that  intel will accept both tasm and ml  obj's. Which do you
suggest?  I suppose I could use  WOMP.exe  to  convert  the  32  bit  ml  6.1
objects to Pharlap?  With  all  of  these,  tasm  and  ml, there is the
problem of switches! Any suggestions would be helpful!!


                                     Jer

___
 X SLMR 2.1a X


From:    Eric Nylander
To:      All                                    Msg #1820, Nov-02-93 03:54AM
Subject: pharlap, qemm, and graph.h

if you are having problems running graph.h while in pharlap, and you are using
qemm, the stealth mode of qemm causes a GP.
stealth can be turned off for the video rom to remove the GP.


From:    Marcus Erickson                        Rec'd
To:      Kevin Kitsemetry                       Msg #1823, Nov-02-93 11:44AM
Subject: Problem with Patching 9.5 (a)

I am haing trouble applying my 'A' version patch to my version 9.5
DOS32 compiler.  I purchased 9.0 but received a free copy of 9.5 at
SD 93. When I try to apply the A level patches, I get the warning that
BPATCH can not apply the patches because the file sizes are different than
what it expects.
    Thank you,
        Marcus Erickson
        Pocket Soft, Inc.

*** See also #1830.


From:    Richard Parkinson                      Rec'd
To:      Kevin Kitsemetry                       Msg #1824, Nov-02-93 01:38PM
Subject: C32 V9.5 problems

Hello,

I am currently porting an OS/2 16 bit app written with Microsoft C6.0 to an
OS/2 32 bit app with Watcom C/C++32 V9.5.

I have found that there seems to be a problem with the Watcom compiler.

Basicall my program has some large and complex structures which contain
pointers to other structures. These are all dynamically allocated with
DosAllocSharedMem.

Everthing works fine untill I access data that is in a structure which itself
is part of a structure.

i.e.

Structure 1

  long var1;
  long var2;
  struct struct2 *struct2;

structure 2

   long var1;
   long var2;

if I allocate memory for an array of structure 1 and then allocate an array of
structure2 within structure1 I cant access any of structure 2, I get a PV.

If however I copy the address from the structure pointer in structure 1 to a
temporary variable I CAN access the memory.

All this worked fine with the Microsoft compiler so I can only assume that
there is a bug in the Watcom compiler that causes an incorrect address to be
returned when you have a structure array that contains a structure array.

If you nead any more information just let me know, but for now I can-not use
the watcom compiler for my app. This is a serious bug!

Regards,

Richard Parkinson.

*** See also #1831.


From:    Kevin Kitsemetry                       Rec'd
To:      Jason Blochowiak                       Msg #1825, Nov-02-93 04:30PM
Subject: Locking for VM

 JB>  As expected, the DPMI functions themselves aren't
 JB> that big of a deal. What I need to know is how to
 JB> determine the values to pass - where the code for the
 JB> program resides & how long it is, and where the static
 JB> data resides and how long it is. I don't recall seeing
 JB> how to determine these values on my previous scans of
 JB> the documentation - if I'm having a memory lapse,
 JB> pointing me to the right page in the docs (I have 9.5)
 JB> would be entirely sufficient.



/* Here's how to lock a function called "lockme"
*/
int lockme ()
        {
        }

int function_after_lockme ();
        {
        }

int lock_lockme ()
        {
        void *p;
        int len;

        p = (void *) lockme;            /* p = linear address to lock */
        len = (char *) function_after_lockme - (char *) lockme;
                                        /* len = length of area to lock */

        /* now load BX:CX with 'p' and SI:DI with 'len' and issue int 31h/
           600h to lock the code for the function
        */
        }

*** This is a reply to #1795.  *** See also #1894.


From:    Kevin Kitsemetry                       Rec'd
To:      Howard Keller                          Msg #1826, Nov-02-93 04:34PM
Subject: Zinc Application Framework 3.5 and Watcom C++32 for NT

 HK> I'm not sure who to address this letter to.
 HK> I'm trying to use the Zinc Application Framework 3.5 to build
 HK> applications for both OS/2 2.1 and WindowsNT.  No
 HK> problem with OS/2, but Zinc doesn't provide libraries
 HK> for the 9.5 WindowsNT compiler.  When inquiring about
 HK> this from Zinc teck support, I was told that they have
 HK> enperienced "serious problems" with the Watcom C++32
 HK> 9.5 NT compiler and they don't plan to support it
 HK> until the problems have been resolved.  I was unable
 HK> to find out the nature of the problems.  Is anyone
 HK> aware of this at Watcom and if there is a problem,
 HK> what's the time frame for repair?

I have talked with our person responsible for Third Party
Vendor Support for WATCOM products, and he told me that
we are aware of the problems, and are currently working with Zinc to resolve
them.


Kevin Kitsemetry
WATCOM TECHNICAL SUPPORT

*** This is a reply to #1761.


From:    Kevin Kitsemetry                       Rec'd
To:      Marcus Erickson                        Msg #1830, Nov-03-93 10:49AM
Subject: Problem with Patching 9.5 (a)

 ME> I am haing trouble applying my 'A' version patch to my version 9.5
 ME> DOS32 compiler.  I purchased 9.0 but received a free copy of 9.5 at
 ME> SD 93. When I try to apply the A level patches, I get the warning that
 ME> BPATCH can not apply the patches because the file
 ME> sizes are different than what it expects.

You can run the techinfo utility to see if the files are already patched to
level 'a'.  If you think that the files have been corrupted somehow, you can
re-install the compiler and then apply the patches. Remember, you must apply
them in DOS, not OS/2.


Kevin Kitsemetry
WATCOM TECHNICAL SUPPORT

*** This is a reply to #1823.  *** See also #1841.


From:    Kevin Kitsemetry
To:      Richard Parkinson                      Msg #1831, Nov-03-93 10:52AM
Subject: C32 V9.5 problems

 RP> Hello,

 RP> I am currently porting an OS/2 16 bit app written with
 RP> Microsoft C6.0 to an OS/2 32 bit app with Watcom
 RP> Basicall my program has some large and complex
 RP> structures which contain pointers to other structures.
 RP> These are all dynamically allocated with
 RP> DosAllocSharedMem.


 RP> If however I copy the address from the structure
 RP> pointer in structure 1 to a
 RP> temporary variable I CAN access the memory.

 RP> If you nead any more information just let me know, but
 RP> for now I can-not use the watcom compiler for my app.
 RP> This is a serious bug!

Can you provide us with a small example program that illustrates the problem,
so that we can reproduce it here?  You can upload it in file area 12 on this
BBS.


Kevin Kitsemetry
WATCOM TECHNICAL SUPPORT

*** This is a reply to #1824.


From:    Nicos Skouras                          Rec'd
To:      Kevin Kitsemetry                       Msg #1833, Nov-03-93 01:04PM
Subject: WVIDEO

I believe that I misused the word 'in the weeds'. The WVIDEO is still active
but because the system has switched to Graphics Mode any motion
of the mouse ( to select anything from the menus ) results in a trail of
non-characters that makes the screen completely garbled after a while.
Thanks for your efforts
Nicos skouras


From:    Nicos Skouras                          Rec'd
To:      Kevin Kitsemetry                       Msg #1834, Nov-03-93 01:08PM
Subject: C++32 & get/set vectors

Using C++32 9.5a, Pharlap 4.0, and attempting to use the functions:
_dos_getvevct, _dos_setvect & _chain_intr I get no results, not even
mem. exception errors.
To verify it I went away from my software and did a test module using
the examples in page 138, 154 & 87 of the Library Functions manual
(4th edition) with the same results.
Any help on the subject ??
Thanks Nicos Skouras

*** See also #1847.


From:    Kevin Blenkinsopp                      Rec'd
To:      Kevin Kitsemetry                       Msg #1838, Nov-03-93 06:51PM
Subject: Zero-sized arrays, const-ness

Kevin,

first off, thanks for sorting out that locked port problem.
Couple of compiler problems for you:
first,
  struct frog {
    int n;
    char a[];
  };
throws up an error because of the zero-sized array. It's legal ANSI (I think)
and it's definitely legal MS (I'm porting the code) - I thought there might be
a switch to enable things like this, but I can't find it in the docs.
Also,
  const int n = 32;
  char buf[n];
chokes on the declaration of buf because it says it needs a constant
expression inside the brackets. It's as if the compiler has lost the const-
ness of the int. Similar problems (not surprisingly) with
  const char *s="frog";
  char buf[strlen(s)];
which is how I found it in the first place.

Any suggestions would be greatly appreciated.

Cheers,

Kevin

*** See also #1840.


From:    David Zechiel                          Rec'd
To:      Kevin Kitsemetry                       Msg #1839, Nov-03-93 07:48PM
Subject: asm directive

Does the C++ compiler support the asm compiler directive in extended mode?  I
can't locate much about this in the documentation.

  Thanks in advance,

  Dave Zechiel

*** See also #1849.


From:    Anthony Scian                          Rec'd
To:      Kevin Blenkinsopp                      Msg #1840, Nov-04-93 10:49AM
Subject: Zero-sized arrays, const-ness

 KB> Couple of compiler problems for you:
 KB> first,
 KB>   struct frog {
 KB>     int n;
 KB>     char a[];
 KB>   };
 KB> throws up an error because of the zero-sized array.
 KB> It's legal ANSI (I think) and it's definitely legal MS
 KB> (I'm porting the code) - I thought there might be a
 KB> switch to enable things like this, but I can't find it
 KB> in the docs.

 This is definitely not legal ANSI although it is an MS extension.
 The C compiler accepts this but the C++ compiler correctly rejects
 it as incorrect.  We've logged this as a possible enhancement to
 the C++ compiler.

 KB> Also,
 KB>   const int n = 32;
 KB>   char buf[n];

 The C compiler is correct in rejecting this code.  This works fine
 in C++.

 KB> chokes on the declaration of buf because it says it needs a constant
 KB> expression inside the brackets. It's as if the
 KB> compiler has lost the const-ness of the int. Similar
 KB> problems (not surprisingly) with
 KB>   const char *s="frog";
 KB>   char buf[strlen(s)];

This is incorrect, array dimensions must be constant.  Both the C and C++
compilers are correct in rejecting this code.

*** This is a reply to #1838.


From:    Marcus Erickson                        Rec'd
To:      Kevin Kitsemetry                       Msg #1841, Nov-04-93 11:38AM
Subject: Problem with Patching 9.5 (a)

Thanks for your suggestions by unfortunately they do not apply in my
situation.  I have a version of 9.5 according to the banners.
An example file:
   FILE: WCC386.EXE
   SIZE: 625566 bytes
   DATE: 2/11/93

   BPATCH -Q: Says that file has not been patched
   BANNER   : Says that it is version 9.5

   When I try to apply the A patch, I get the message existing file
   is the wrong size. Expecting file of size 627702 bytes and found one
   with size 625566 bytes.

   I was wondering if the free releases of the 9.5 compiler given
   out at SD 3 were pre-releases or special releaes or something?

   Thanks for your help!

*** This is a reply to #1830.  *** See also #1850.


From:    Skip Fedanzo
To:      Watcom                                 Msg #1842, Nov-04-93 08:39PM
Subject: realloc() with DOS4G professional

I discovered with the new DOS4G Professional that realloc() isn't working
correctly and am wondering when WATCOM is issuing a fix.

*** See also #1852.


From:    Colly Myers
To:      All                                    Msg #1843, Nov-04-93 10:12PM
Subject: Classes in DLLs

Is it possible to put a class library in a DLL under Windows/NT and if it is
possible can sub-classes reference the DLL from the main program.

Colly Myers

*** See also #1853.


From:    Kevin Kitsemetry                       Rec'd
To:      Nicos Skouras                          Msg #1847, Nov-05-93 02:57PM
Subject: C++32 & get/set vectors

 NS> Using C++32 9.5a, Pharlap 4.0, and attempting to use the functions:
 NS> _dos_getvevct, _dos_setvect & _chain_intr I get no results, not even
 NS> mem. exception errors.
 NS> To verify it I went away from my software and did a test module using
 NS> the examples in page 138, 154 & 87 of the Library Functions manual
 NS> (4th edition) with the same results.

I just tried the getvect.c example (provided in src\clibexam) and it worked
fine with 9.5a.  What problem did you have?  What was the output after you ran
this example program?


Kevin Kitsemetry
WATCOM TECHNICAL SUPPORT

*** This is a reply to #1834.  *** See also #1851.


From:    Kevin Kitsemetry                       Rec'd
To:      David Zechiel                          Msg #1849, Nov-05-93 03:11PM
Subject: asm directive

 DZ> Does the C++ compiler support the asm compiler
 DZ> directive in extended mode?  I can't locate much about
 DZ> this in the documentation.

No, WATCOM C++ supports in-line assembly instructions via a pragma statement.
This is documented (a bit) in the User's Guide beginning on page 166.
Although it looks like they
are called as functions, the compiler actually generates the code in-line.


Kevin Kitsemetry
WATCOM TECHNICAL SUPPORT

*** This is a reply to #1839.


From:    Kevin Kitsemetry                       Rec'd
To:      Marcus Erickson                        Msg #1850, Nov-05-93 03:19PM
Subject: Problem with Patching 9.5 (a)

 ME>    I was wondering if the free releases of the 9.5 compiler given
 ME>    out at SD 3 were pre-releases or special releaes or something?

I was unaware of this before.  The SD version that were given away for free
cannot be patched.  You have the option of upgrading to the General
Availability release of the compiler if you wish, which could then be patched.


Kevin Kitsemetry
WATCOM TECHNICAL SUPPORT

*** This is a reply to #1841.


From:    Nicos Skouras                          Rec'd
To:      Kevin Kitsemetry                       Msg #1851, Nov-05-93 03:25PM
Subject: C++32 & get/set vectors

I did not use the example program, just copied the code from the library
manual. It behaved as if the timer was never intercepted or chained.
I'll try using the getvect.c and see.
Thanks for your efforts
Nicos Skouras

*** This is a reply to #1847.


From:    Kevin Kitsemetry                       Rec'd
To:      Skip Fedanzo                           Msg #1852, Nov-05-93 03:22PM
Subject: realloc() with DOS4G professional

 SF> I discovered with the new DOS4G Professional that realloc() isn't working
 SF> correctly and am wondering when WATCOM is issuing a fix.

Which problem are you referring to?  Perhaps the file RSIMEM in file area 10
will help you.  It shows how to acquire large blocks of memory under the
Rational DOS extender.


Kevin Kitsemetry
WATCOM TECHNICAL SUPPORT

*** This is a reply to #1842.  *** See also #1857.


From:    Kevin Kitsemetry                       Rec'd
To:      Colly Myers                            Msg #1853, Nov-05-93 03:30PM
Subject: Classes in DLLs

 CM> Is it possible to put a class library in a DLL under
 CM> Windows/NT and if it is possible can sub-classes
 CM> reference the DLL from the main program.

Both are possible, BUT:  There were problems with the C++
compiler under Windows NT that have been fixed and will be
made available in the B-level patches.


Kevin Kitsemetry
WATCOM TECHNICAL SUPPORT

*** This is a reply to #1843.


From:    Nicos Skouras                          Rec'd
To:      Kevin Kitsemetry                       Msg #1854, Nov-05-93 04:22PM
Subject: getvect.c (src\clibexam- C++ 9.5A )

Reference previous messages: 1834, 1847, 1851 (which should be deleted)
I compiled the getvect.c test program with the same results:
The executable displays: "Delayed for 1 second" the number of times it
should ( 15 ) and the the program terminates without displaying the '.'
expected after each 5 sec intervals and the variable clock_ticks never gets
incremented !!!.
I do not believe that the set/get/chain function actually WORK
Please advise
Thanks
Nicos skouras

*** See also #1862.


From:    Matthew Heinze
To:      Mark Yu                                Msg #1855, Nov-05-93 06:35PM
Subject: C++ Sampler Programs

 MY> We're using v9.5 to build 32-bit windows apps and I was wondering if you
 MY> could post some C++ sample programs on the BBS.

I have placed a C++ example in the WATCOM C file area, #10.  This is a simple
calendar example that will be updated as new versions are available.

 MY> Borland or Zortech)?  Finally, when I mix C++ and C
 MY> programs and invoke wmake to do the build, I get
 MY> numerous undefined references of global data (the
 MY> programs compile fine using Borland C++).  Is there
 MY> some encapsulation that must be performed on the data
 MY> (as one does with functions using extern "C" { etc.)?

Please provide a small example of the problem you are having mixing C and C++
so that we can reproduce the problem here.

Matthew Heinze
WATCOM TECHNICAL SUPPORT

*** This is a reply to #1487.


From:    Donald Tevault
To:      Watcom Technical Support               Msg #1856, Nov-06-93 05:27AM
Subject: Make utility

        Is the make utility for the C/C++32 compiler package meant to work
with the C++ compiler?  It seems that it isn't, since all of your example
MAKEFILES are written for the C compiler,  and since I can't get it to work
with the C++ compiler.  This presents a problem for me, because I'm trying to
use the C++ compiler with Kedwell Software's Databoss for Windows package.
Databoss generates C++ code and a makefile for it.  The make utility will
recognize the C++ files if I add the line ".EXTENSION .CPP".  However, it
still will not invoke the C++ compiler, and just dumps me back out to DOS
without any error messeges.  To make things even more frustrating, none of the
included manuals mention that the make utility will not work with C++.
        Thanks for your time.  I'll check back next week for a reply.
                                 Sincerely,
                                 Donald A. Tevault
                                 Registration number:

*** See also #1863.


From:    Skip Fedanzo                           Rec'd
To:      Kevin Kitsemetry                       Msg #1857, Nov-06-93 11:56AM
Subject: realloc() under DOS4G Professional

The specific problem I refer to concerns realloc() freeing previously
malloced data space.  I have an application that does a fair amount of
malloc/realloc/freeing and it runs slower and slower over time, apparently
because it's wending its way through memory that should have
been returned to the free list.  I'm hypothesizing the cause, but the
type of bug reported by Rational would produce the effect I observe;
hence my interest.

*** This is a reply to #1852.  *** See also #1864.


From:    Norm Case
To:      Tech-Support                           Msg #1858, Nov-09-93 10:23AM
Subject: File Handles in NT DLL's

KK> Duplicate.


Here is a new problem I ran into with using file handles 'creat'ed in the main
application and then passed on to a function in a DLL.

cprob5.c:

#include <sys\types.h>
#include <sys\stat.h>
#include <io.h>

void main()
   {
   int handle;

   handle = creat("file", S_IWRITE | S_IREAD);
   use_handle_in_dll(handle);
   close(handle);
   }


cprob5a.c:

#include <sys\types.h>
#include <sys\stat.h>
#include <io.h>
#include <errno.h>

void use_handle_in_dll(int handle)
   {
   int err;

   err = write(handle,"hello", 6);
   printf("handle = %d, err = %d, errno = %d\n", handle, err, errno);
   }


cprob5.lnk:

system nt
name cprob5dl.exe
option map=cprob5.map
debug all
file cprob5
library cprob5a.lib

cprob5a.lnk:

system nt_dll initinstance terminstance
option map=cprob5a.map
debug all
name cprob5a.dll
file cprob5a
export use_handle_in_dll

If I link cprob5 straight (cprob5.exe) with cprob5a (not from DLL) then the
result is as expected, handle = 3, err = 6 (number of bytes written) and errno
= 0.  But, if I link cprob5a with cprob5a in a DLL (cprob5dl.exe) then the
rusult is, handle = 3, err = -1, errno = 4, indicating a bad file handle.

The file 4deanne5.zip contains the files needed to demonstrate this problem.

Please let me know as soon as possible the solution or a work around to this
problem.  Thanks for you help.

Norman Case
4D Graphics

[phone]


From:    Norm Case                              Rec'd
To:      Kevin Kitsemetry                       Msg #1860, Nov-09-93 10:22AM
Subject: File handles in NT DLL's

KK> Duplicate message.


Here is a new problem I ran into with using file handles 'creat'ed in the main
application and then passed on to a function in a DLL.

cprob5.c:

#include <sys\types.h>
#include <sys\stat.h>
#include <io.h>

void main()
   {
   int handle;

   handle = creat("file", S_IWRITE | S_IREAD);
   use_handle_in_dll(handle);
   close(handle);
   }


cprob5a.c:

#include <sys\types.h>
#include <sys\stat.h>
#include <io.h>
#include <errno.h>

void use_handle_in_dll(int handle)
   {
   int err;

   err = write(handle,"hello", 6);
   printf("handle = %d, err = %d, errno = %d\n", handle, err, errno);
   }


cprob5.lnk:

system nt
name cprob5dl.exe
option map=cprob5.map
debug all
file cprob5
library cprob5a.lib

cprob5a.lnk:

system nt_dll initinstance terminstance
option map=cprob5a.map
debug all
name cprob5a.dll
file cprob5a
export use_handle_in_dll

If I link cprob5 straight (cprob5.exe) with cprob5a (not from DLL) then the
result is as expected, handle = 3, err = 6 (number of bytes written) and errno
= 0.  But, if I link cprob5a with cprob5a in a DLL (cprob5dl.exe) then the
rusult is, handle = 3, err = -1, errno = 4, indicating a bad file handle.

The file 4deanne5.zip contains the files needed to demonstrate this problem.

Please let me know as soon as possible the solution or a work around to this
problem.  Thanks for you help.

Norman Case
4D Graphics

[phone]


From:    Karsten Kiehlmann                      Rec'd
To:      Kevin Kitsemetry                       Msg #1861, Nov-08-93 07:36PM
Subject: Var.Access Pmode Rmode --> MORE INFORMATION NEEDED <--

Dear Kevin,

thanks for your first answer.

Unfortunately it doesn't cover all of our questions which I'd tried to specify
more exactly in the  last message. So could you please answer to  all of the
questions in message no. 1773 ??

Your last answer doesn't solve our problems.

Thanks.

With best regards,

K. Kiehlmann

c/o IAV GmbH, Dept. Electronic, Carnotstrasse 1, D-10587 Berlin, F.R.G.
    Tel.:  [phone]       Fax.: [phone]

*** This is a reply to #1789.  *** See also #1865.


From:    Kevin Kitsemetry                       Rec'd
To:      Nicos Skouras                          Msg #1862, Nov-09-93 10:10AM
Subject: getvect.c (src\clibexam- C++ 9.5A )

 NS> Reference previous messages: 1834, 1847, 1851 (which should be deleted)
 NS> I compiled the getvect.c test program with the same results:
 NS> The executable displays: "Delayed for 1 second" the number of times it
 NS> should ( 15 ) and the the program terminates without displaying the '.'
 NS> expected after each 5 sec intervals and the variable
 NS> clock_ticks never gets
 NS> incremented !!!.

What is your environment that you are running this in.  Send a copy of the
output from running techinfo.exe (don't forget to have the WATCOM environment
variable set).


Kevin Kitsemetry
WATCOM TECHNICAL SUPPORT

*** This is a reply to #1854.  *** See also #1866.


From:    Kevin Kitsemetry                       Rec'd
To:      Donald Tevault                         Msg #1863, Nov-09-93 10:13AM
Subject: Make utility

 DT>         Is the make utility for the C/C++32 compiler package meant to
 DT> work with the C++ compiler?  It seems that it isn't,
 DT> since all of your example MAKEFILES are written for
 DT> the C compiler,  and since I can't get it to work with
 DT> the C++ compiler.  This presents a problem for me,
 DT> because I'm trying to use the C++ compiler with
 DT> Kedwell Software's Databoss for Windows package.
 DT> Databoss generates C++ code and a makefile for it.
 DT> The make utility will recognize the C++ files if I add
 DT> the line ".EXTENSION .CPP".  However, it still will
 DT> not invoke the C++ compiler, and just dumps me back
 DT> out to DOS without any error messeges.  To make things

Because the C++ is so new, there aren't any examples of
using wmake with it.  There are many ways that you can use
it (it does indeed work).  Try creating a makefile to build calendar.cpp.  If
you can't get it work, upload your makefile attempt and I will have a look at
it.


Kevin Kitsemetry
WATCOM TECHNICAL SUPPORT

*** This is a reply to #1856.


From:    Kevin Kitsemetry                       Rec'd
To:      Skip Fedanzo                           Msg #1864, Nov-09-93 10:16AM
Subject: realloc() under DOS4G Professional

 SF> The specific problem I refer to concerns realloc() freeing previously
 SF> malloced data space.  I have an application that does a fair amount of
 SF> malloc/realloc/freeing and it runs slower and slower
 SF> over time, apparently because it's wending its way
 SF> through memory that should have
 SF> been returned to the free list.  I'm hypothesizing the cause, but the
 SF> type of bug reported by Rational would produce the effect I observe;
 SF> hence my interest.

No, they type of bug that Rational is talking about would report that the
malloc() failed because there was insufficient memory available.  It has to do
with the fact that after many malloc() and free()'s, the memory becomes
fragmented.  Other DOS extenders have implimented a feature,whereby the
fragmented memory is recognized as a large chunk (joining the pieces) so that
the fragmentation appears non existant.  Rational does not do this.


Kevin Kitsemetry
WATCOM TECHNICAL SUPPORT

*** This is a reply to #1857.  *** See also #1867.


From:    Kevin Kitsemetry                       Rec'd
To:      Karsten Kiehlmann                      Msg #1865, Nov-09-93 10:28AM
Subject: Var.Access Pmode Rmode --> MORE INFORMATION NEEDED <--

 KK> Dear Kevin,
 KK> thanks for your first answer.
 KK>
 KK> Unfortunately it doesn't cover all of our questions
 KK> which I'd tried to specify more exactly in the  last
 KK> message. So could you please answer to  all of the
 KK> questions in message no. 1773 ??

Sorry about the confusion.  The message I posted was in response to an earlier
message from someone else (the fist message sent by I believe one of your
collegues).  I have to check the answers to the questions in 1773 before I
posted a reply to that message.  I believe this is the reply you were waiting
for:


KK> 1 How can proteceted mode code be called from real mode code (ISR's) ?

Protected mode code and data are not in general accessible to real mode ISRs,
because they may be in extended memory, and can't be addressed in real mode.
The only way to access them would be to pass up into protected mode on another
interrupt vector.  32-bit protected-mode code wouldn't run in 16-bit real mode
anyway.


KK> 2 How can real mode variables be installed / declaired so that they are
KK> accessable from real mode code (the stupid ISR's
KK> again) as well as from protected mode code, too ?

Real mode "variables" don't exist.  You can move data to low memory so it's
accessible to both protected mode code and real mode code, but the concept of
a variable implies a symbolic name, and the only way to use a symbolic name is
to link for the appropriate mode.  Since DOS/4GW programs are always linked
for protected mode, any code one manages to coax into low memory and run as an
ISR can't assume any addresses external to it are valid -- all it can assume
is that it can read and write to absolute offsets within its own CS.  There's
no support in DOS/4GW for more sophisticated mixed-mode programming.


KK> 3 Are there any other possiblities to install real
KK> mode code (ISR's) than you did in your example
KK> 'bimodal' (that's funny but not sufficent)?

To date, that is our only programming example that we have.


Kevin Kitsemetry
WATCOM TECHNICAL SUPPORT

*** This is a reply to #1861.


From:    Nicos Skouras                          Rec'd
To:      Kevin Kitsemetry                       Msg #1866, Nov-09-93 04:21PM
Subject: getvect.c (src\clibexam- C++ 9.5A )

Please see File area #12 where I uploaded a file TECHINFO.OUT
Thanks for the efforts
Nicos Skouras

*** This is a reply to #1862.  *** See also #1870.


From:    Tim Anderson
To:      Kevin Kreutzweiser                     Msg #1868, Nov-10-93 05:06PM
Subject: C++ not compatible w/C

KK> Internal Report #10014


Hey, it's simply amazing that you are asking questions on something I'm
working on again! Just an aside, however. You don't hear me asking questions
about the NT stuff anymore. This should be a WARNING to you since when I USE
stuff I generally COMMENT on it. We are still using Watcom for Windows 32bit
though...

Anyway, I want the function prototype generator to generate C++ compatible
function prototypes. I want to be able to dump out ALL function prototypes
whether they are STATIC or not, and I want the original TYPEDEF's or #defines
and NOT what the preprocessor sez they should be. So we need a couple new
flags. -v can be dump out non-static function prototypes -v1 can be dump out
ALL function prototypes, regardless if they are static or not. This would help
me to get our stuff to compile under C++,so that I can start playing with C++
stuff. Note: I am not having any problems doing EXACTLY THIS (sans
preprocessor unfortunately) using the development environment for NT that was
developed by a company in Redmond.

Oh ya, the static's HAVE to have 'static' in front of them, and the non
static's HAVE to have 'extern' in front of them. Also, there is a problem with
two dimensional array's and the function prototyper.

foo(int spaz[2][2]);

is dumped

int foo(int spaz(*)[2]);

This is OK for C land, but not OK for C++ land. All you have to do to watch
this thing explode is to generate prototypes and try to use them. Yes, we
should have been doing this from day one. Unfortunately I have quite a few
files that I need to prototype (and also create extern's for the equivolent H
file) and I want to do this automatically. We have been able to do this for C,
but noone has a prototype generator that allows CROSS PLATFORM and CROSS
LANGUAGE prototypes. I can't beleive that I am the only one in the world that
is doing this...

Tim

*** This is a reply to #1434.


From:    Russell Williamson                     Rec'd
To:      Kevin Kitsemetry                       Msg #1869, Nov-09-93 10:14PM
Subject: WVIDEO messages

While debugging a 32-bit C++ (9.5 level A) program built for DOS/4GW, I often
see the message 'No memory for type'.  Is this a memory shortage, or a failure
to recognize a type?  Also, WVIDEO often fails to recognize the symbol 'this'
while tracing through a member function.  Could this be related to the
first error?

*** See also #1872.


From:    Kevin Kitsemetry                       Rec'd
To:      Nicos Skouras                          Msg #1870, Nov-10-93 10:14AM
Subject: getvect.c (src\clibexam- C++ 9.5A )

 NS> Please see File area #12 where I uploaded a file TECHINFO.OUT
 NS> Thanks for the efforts
 NS> Nicos Skouras

I tried it with Pharlap 5.0 and it worked fine.  I have taken a look at the
techinfo output and you seem to have
everything patched correctly.  Can you try the .exe on another computer?


Kevin Kitsemetry
WATCOM TECHNICAL SUPPORT

*** This is a reply to #1866

From:    Kevin Kitsemetry                       Rec'd
To:      Russell Williamson                     Msg #1872, Nov-10-93 05:11PM
Subject: WVIDEO messages

 RW> While debugging a 32-bit C++ (9.5 level A) program
 RW> built for DOS/4GW, I often see the message 'No memory
 RW> for type'.  Is this a memory shortage, or a failure to
 RW> recognize a type?  Also, WVIDEO often fails to
 RW> recognize the symbol 'this' while tracing through a
 RW> member function.  Could this be related to the
 RW> first error?

The first problem is likely due to fact that you are running out of dymanic
memory in the debugger.  Try increasing the amount of dymanic space used by
WVIDEO by specifying /dynamic=xxx.  The default is 40K.  If this doesn't work
you may have to use one of the remote debugging methods to debug your
application.


Kevin Kitsemetry
WATCOM TECHNICAL SUPPORT

*** This is a reply to #1869.


From:    Kevin Blenkinsopp                      Rec'd
To:      Kevin Kitsemetry                       Msg #1877, Nov-11-93 12:45PM
Subject: Profiling

* Original Area: wc
* Original To  : Kevin Kitsemetry (1:221/186)

Kevin,

I've been trying to profile some code, and wprof is telling me that my code is
spending 100% of its time in OS/external stuff. This seemed pretty unlikely to
me, so I hacked up a little noddy progam and tried again. This time, wprof
tells me that there aren't any samples in the file. I've uploaded the noddy
code to the file area. It was compiled with wcl386 -d2, using c++ 9.5a and
dos4g. Incidentally, if I run samprsi with "dos4gw wsamprsi t" like it says in
the manual, I get a dos4gw error saying it can't find the loader for wsamprsi.
Just running "wsamprsi t" seems to be fine. Any ideas as to what I'm doing
wrong?

Cheers,

Kevin

*** See also #1881.


From:    Tim Anderson                           Rec'd
To:      Kevin Kitsemetry                       Msg #1878, Nov-12-93 11:14AM
Subject: inline

KK> Internal Report #10180


I have this rather simple inline using "another compiler from a company in
Redmond", and I don't know how to inline it with Watcom. Why is this so
difficult?

/* In reality this is page_offset = div(idx, temp_page_size); */ /* stretched
out to return two integers instead of a structure */

__asm {
        xor edx,edx
        mov eax,idx
        div temp_page_size
        mov iPage,eax
        mov iOffset,edx
}

Is there an easy way to access variables outside of the inline? The main
problem is that this 'returns' two integer values, and I can't see an easy way
to set this up using all that #pragma fake function in an inline nonsense.

Since this is really the 'div' function as documented in the <stdlib.h> file,
is it inlined allready?

tim anderson

PS: I was able to chop a big chunk of time off of "that other companies"
routines for this by inlining them. On the order of 34% or so! Amazing...


*** See also #1883.


From:    Lam Lee
To:      Watcom                                 Msg #1879, Nov-12-93 09:07AM
Subject: WIndows 32b DLL with 9.5A bug

Hi,
We just recompiled a large 32 bit DLL using C/C++ 9.5A.  This program was
working ok under 9.1E but now we will get a GPF on the very first call into
the DLL.  The app that calls this 32b DLL is a 16 bit app that use MS C
compiler 6.0AX.   From reading the msg on this forum and some one told me on
CIS that Watcom has a bug in the DLL supervisor, which there is a pre-release
fix on the BBS.  I can not seems to locate this program in this area?  Is that
the WINEXT.ZIP?  Can someone point me to where this file might be.  Thanks.

*** See also #1882.


From:    Kevin Kitsemetry                       Rec'd
To:      Kevin Blenkinsopp                      Msg #1881, Nov-12-93 09:47AM
Subject: Profiling

 KB> * Original Area: wc
 KB> * Original To  : Kevin Kitsemetry (1:221/186)

 KB> Kevin,

 KB> I've been trying to profile some code, and wprof is telling me that my
 KB> code is spending 100% of its time in OS/external
 KB> stuff. This seemed pretty unlikely to me, so I hacked
 KB> up a little noddy progam and tried again. This time,
 KB> wprof tells me that there aren't any samples in the
 KB> file. I've uploaded the noddy code to the file area.
 KB> It was compiled with wcl386 -d2, using c++ 9.5a and
 KB> dos4g. Incidentally, if I run samprsi with "dos4gw
 KB> wsamprsi t" like it says in the manual, I get a dos4gw
 KB> error saying it can't find the loader for wsamprsi.
 KB> Just running "wsamprsi t" seems to be fine. Any ideas
 KB> as to what I'm doing wrong?

I am not sure why it would be spending most of the time in
the OS/external.  I am unable to confirm with the develpement team on this as
the key people I need to talk to are not
available this week.

On the other hand, it does not surprise me that your small
program does have any samples in the file - you can only
profile larger programs that execute for a certain amount
of time.  You also probably do not want to use /d2 as that
option disables optimizations.


Kevin Kitsemetry
WATCOM TECHNICAL SUPPORT

*** This is a reply to #1877.


From:    Kevin Kitsemetry                       Rec'd
To:      Tim Anderson                           Msg #1883, Nov-12-93 11:01AM
Subject: inline

KK> Internal Report #10180


 TA> /* In reality this is page_offset = div(idx,
 TA> temp_page_size); */ /* stretched out to return two
 TA> integers instead of a structure */

 TA> __asm {
 TA>         xor edx,edx
 TA>         mov eax,idx
 TA>         div temp_page_size
 TA>         mov iPage,eax
 TA>         mov iOffset,edx
 TA> }

 TA> Is there an easy way to access variables outside of
 TA> the inline? The main problem is that this 'returns'
 TA> two integer values, and I can't see an easy way to set
 TA> this up using all that #pragma fake function in an
 TA> inline nonsense.


There are several ways of coding a div pragma.
1)
    #pragma aux mydiv = "xor edx,edx" \
                        "div ecx"     \
                        "mov iPage,eax"\
                        "mov iOffset,edx" \
                        parm [eax] [ecx];
OR, you could pass in the address of iPage and return iOffset in a register
    extern int mydiv( int num, int divisor, int *answer );
    #pragma aux mydiv = "xor edx,edx" \
                        "div ecx"     \
                        "mov [ebx],eax"\
                        parm [eax] [ecx] [ebx] value [edx];
    page_offset = mydiv( idx, temp_page_size, &iPage );

If temp_page_size is a power of 2, which it most likely is, you can do much
much better by using shifting and anding since these are only 1 clock
instructions, vs the divide instruction which can take up to 40 some clocks.
If this is the case, then you can just code it as straight C code.
        iPage = idx >> n;
        iOffset = idx & mask;
where n and mask are the appropriate constants for accomplishing the same
thing as dividing by temp_page_size;

 TA> Since this is really the 'div' function as documented
 TA> in the <stdlib.h> file, is it inlined allready?

Yes, they can be inlined with the /oi compiler option.


Kevin Kitsemetry
WATCOM TECHNICAL SUPPORT

*** This is a reply to #1878.  *** See also #1884.


From:    Tim Anderson                           Rec'd
To:      Kevin Kitsemetry                       Msg #1884, Nov-12-93 12:04PM
Subject: inline

Thanks for the hints! After I got away from the computer for awhile,
I realized that there was a reasonable way to do this using the Watcom
style #pragma aux stuff. I geuss that's what I get for working too long
at one thing and then trying to change gears...

Nothing like some sleep and a shower to clear your head out...

tim

*** This is a reply to #1883.


From:    Phil Duvalsaint
To:      All                                    Msg #1885, Nov-12-93 01:34PM
Subject: Autocad ads_command troubles

I have been trying to do some block insertions in ADS and have run into
      a problem.  I get the error:
Application K:\EVENTCAD\ADS\ECINERT.EXP ERROR :incorrect request for command
list data

Here are three different code fragments which I have tried. They all generate
the same error.  The block 10TOP72 can be manually inserted, and AutoLisp has
no problems with it.  I've checked the order of arguments and they appear to
be correct.  Does anybody have any idea what could be the problem?


struct resbuf *tmp;
ads_point POINT;
float ROT,HEIGHT;
char *BLOCK;

  BLOCK=strdup("10TOP72");
  ROT=0;
  HEIGHT=32.0
  POINT[X]=2846.0;
  POINT[Y]=1842.0;
  POINT[Z]=0.0;

1)
  tmp=ads_buildlist(RTSTR,"_.INSERT",
                    RTSTR,BLOCK,
                    RTPOINT,POINT,
                    RTSTR,"",RTSTR,"",
                    RTREAL,ROT,
                    RTSTR,"",0);
      ads_retlist(tmp);
      ads_cmd(tmp);
      ads_relrb(tmp);

2)
     POINT[Z]=HEIGHT;
     ads_command(RTSTR,"_.INSERT",
                 RTSTR,BLOCK,
                 RT3DPOINT,POINT,
                 RTSTR,"",RTSTR,"",
                 RTREAL,ROT,
                 RTSTR,"",RTSTR,"",RTSTR,"",
                 RTSTR,"",RTSTR,"",RTSTR,"",0);

3)
    ads_command(RTSTR,"_.INSERT",
                RTSTR,"10TOP72",
                RTPOINT,POINT,
                RTSTR,"",RTSTR,"",RTSTR,"",RTSTR,"",0);

*** See also #1890.


From:    Donald Tevault                         Rec'd
To:      Dan Cummins                            Msg #1886, Nov-15-93 09:17PM
Subject: WMAKE

DC> Internal Report #10428

# Hi Kevin!
#       I made the makefile for the Calendar.cpp file as you said, and it #
does invoke the C++ compiler without any problem.  I then tried playing around
# some more with this zipcode.mak file, but no matter what I tried, I still
got # the same results.  That is, it just dumps me out to DOS without invoking
the # C++ compiler.  It's not that it can't find the compiler,because even
when I # move the compiler to the same directory as this makefile, it still
does the # same thing.  If you can figure out a way to make it work, I will be
very # grateful.
#        Many thanks in advance.
#                Donald Tevault
#
#
#
#       MakeFile Frame For Watcom C++ or better
# ~1 = APPNAME, ~2 = APPNAMEdlg, ~3 =  APPNAMEm,
# ~4 = APPNAMEdb, ~5 = APPNAMEini
# ~6 = Include Directory, ~7 = Library Directory
# ~8 = Source Directory
.EXTENSIONS: .CPP
SD = C:\DB4W\SOURCE\\

FILES = charf.obj pictures.obj ZIPCODDD.obj ZIPCODMM.obj\
dllutil.obj stdfile.obj database.obj toolbar.obj specscrl.obj\ stdquery.obj
linkman.obj memof.obj combo.obj dialogs.obj\
table.obj query.obj stdidx.obj lexer.obj parser.obj symbol.obj\ decor.obj
static.obj keyfilt.obj checkbox.obj btree.obj file.obj



INCLUDEDIR = C:\DB4W\SOURCE
LIBDIR   = C:\WATCOM\LIB386;C:\WATCOM\LIB386\WIN\\

COM = WIN386 1
CC = wpp386

# Most Compiler-Specific Items are in the following 7 lines # Almost any
Windows C++ compiler that uses a MAKEFILE can be # supported here # COMPILER =
LINKER   = wlink
RC        = wrc
RFLAGS   = /r /i=$(SOURCEDIR)
#CFLAGS  = /c /GW
CPPFLAGS = -zW -oaxt -d1 -d -w4 -fpc -i=$(INCLUDEDIR)
LFLAGS   = /Lw
LFILES   = ZIPCODE.def

.cpp.obj:
       $(CC) $[*.cpp $(CPPFLAGS)

#.c.obj:
#       $(COMPILER) $(CFLAGS) $^.

ZIPCODE.res: ZIPCODE.rc
        $(RC) $(RFLAGS) ZIPCODE.rc

ZIPCODE.EXE: ZIPCODE.obj $(FILES) ZIPCODE.rc  ZIPCODE.def
        $(LINKER) $(LFLAGS) $(FILES) $(LFILES)
        wbind ZIPCODE -R -31 ZIPCODE.res
#       rc -t -K ~1

#       Dependencies
CHARF =         $(SD)charf.hpp
DATABASE =      $(SD)database.hpp
PICTURES =      $(SD)pictures.hpp
GLOBAL =        $(SD)global.hpp
DLLUTIL =       $(SD)dllutil.hpp
FRAME =         $(SD)frame.hpp
STATBAR =       $(SD)statbar.hpp
MEMOF =         $(SD)memof.hpp
COMBO =         $(SD)combo.hpp
TOOLBAR =       $(SD)toolbar.hpp
SPECSCRL =      $(SD)specscrl.hpp
GENERIC =       $(SD)generic.hpp
STDQUERY =      $(SD)stdquery.hpp
DIALOGS =       $(SD)dialogs.hpp
LINKMAN =       $(SD)linkman.hpp
QUERY =         $(SD)query.hpp
TABLE =         $(SD)table.hpp
STDIDX =        $(SD)stdidx.hpp
STDFILE =       $(SD)stdfile.hpp
LEXER =  $(SD)lexer.hpp
PARSER =         $(SD)parser.hpp
SYMBOL =         $(SD)symbol.hpp
DECOR =  $(SD)decor.hpp
STATIC =         $(SD)static.hpp
KEYFILT =       $(SD)keyfilt.hpp
CHECKBOX =      $(SD)checkbox.hpp
BTREE    =      $(SD)btree.hpp
FILE     =      $(SD)file.hpp

stdidx.obj      : $(SD)stdidx.cpp $(STDIDX)
charf.obj       : $(SD)charf.cpp  $(CHARF) $(DLLUTIL) $(DATABASE) pictures.obj
: $(SD)pictures.cpp $(PICTURES)
ZIPCODE.obj      : ZIPCODE.cpp $(STDFILE) $(GLOBAL) $(FRAME) $(DATABASE)
$(STATBAR)\
                 $(TOOLBAR) $(SPECSCRL) $(CHARF) $(NUMF) $(COMBO) $(MEMOF)
$(DLLUTIL) ZIPCODE.cpp ZIPCODE.res      : ZIPCODE.rc ZIPCODE.h ZIPCODE.stb
ZIPCODDD.obj     : ZIPCODDD.cpp $(GENERIC) $(CHARF) $(DATABASE) ZIPCODE.cpp
ZIPCODMM.obj     : ZIPCODMM.cpp $(FRAME) $(STDFILE) $(GLOBAL) $(DATABASE)
$(STATBAR)\
                 $(TOOLBAR) ZIPCODDD.hpp ZIPCODE.h $(GENERIC) $(DIALOGS)
dllutil.obj     : $(SD)dllutil.cpp $(DLLUTIL)
stdfile.obj     : $(SD)stdfile.cpp $(DLLUTIL) $(STDQUERY) $(STDFILE) $(MKTREE)\
        $(PICTURES)
database.obj : $(SD)database.cpp $(DATABASE) $(GLOBAL) $(GENERIC) $(FRAME)\
        $(STATBAR) $(CHARF) $(DLLUTIL) $(SPECSCRL) $(DIALOGS) toolbar.obj :
$(SD)toolbar.cpp $(TOOLBAR) $(DATABASE)
statbar.obj     : $(SD)statbar.cpp $(STATBAR)
specscrl.obj : $(SD)specscrl.cpp $(SPECSCRL)
stdquery.obj : $(SD)stdquery.cpp $(STDQUERY) $(DLLUTIL)
linkman.obj     : $(SD)linkman.cpp $(LINKMAN) $(GLOBAL) $(PICTURES) memof.obj
      : $(SD)memof.cpp $(MEMOF) $(DLLUTIL) $(DATABASE) combo.obj       :
$(SD)combo.cpp $(COMBO) $(DLLUTIL) $(DATABASE) dialogs.obj     :
$(SD)dialogs.cpp $(DIALOGS) $(STDFILE) $(GLOBAL) $(GENERIC) table.obj       :
$(SD)table.cpp $(TABLE)
query.obj       : $(SD)query.cpp $(QUERY)
lexer.obj       : $(SD)lexer.cpp $(LEXER)
parser.obj      : $(SD)parser.cpp $(PARSER)
symbol.obj      : $(SD)symbol.cpp $(SYMBOL)
decor.obj       : $(SD)decor.cpp $(DECOR)
static.obj      : $(SD)static.cpp $(STATIC)
keyfilt.obj      : $(SD)keyfilt.cpp $(KEYFILT)
checkbox.obj : $(SD)checkbox.cpp $(CHECKBOX)
btree.obj       : $(SD)btree.cpp $(BTREE)
file.obj         : $(SD)file.cpp $(FILE)

*** See also #1970.


From:    Hal Lonas                              Rec'd
To:      Kevin Kitsemetry                       Msg #1887, Nov-15-93 09:36PM
Subject: FSETENV patch

DC> Internal report #10429

Kevin,
I was told on the Compuserve forum that there are preliminary B-level patches
available for c++ 32 for the FSETENV bug in the Windows DLL supervisor...
Could I get the patch?
Hal

*** See also #1891.


From:    Rainer Schupp
To:      Watcom Technical Support               Msg #1888, Nov-15-93 09:39PM
Subject: comparison bug ?

DC> Internal Report #10430

The result of the following test-program will
be RIGHT if compiled with the 9.0 E-level
compiler, but will be WRONG if compiled with
the 9.5 A-level C++ compiler.


#include <stdio.h>

unsigned char GetValue( void );


main()
{
 unsigned char stat = GetValue();
 if ((signed char)stat < 0)
   {
   if (stat < (unsigned char)0xC0)
     printf( "wrong" );
   else
     printf( "right" );
   }
}


unsigned char GetValue() {return (0xF0);}


From:    Dan Cummins
To:      Nigel Evans                            Msg #1889, Nov-15-93 08:28PM
Subject: DPMI and Interrupts using WATCOM C/386 v9.01

 NE> I need to write an ISR to handle DOS int 24 (critical
 NE> error handler), using the DOS4GW option within WATCOM
 NE> C/386 v9.01.

I placed some examples of critical error handling under DOS4GW on the BBS for
you, as I mentioned in my fax.  Hope these helped.

(This was Internal report #7387)

Dan

*** This is a reply to #1681.


From:    Dan Cummins                            Rec'd
To:      Phil Duvalsaint                        Msg #1890, Nov-15-93 09:04PM
Subject: Autocad ads_command troubles

 PD> I have been trying to do some block insertions in ADS
 PD> and have run into              a problem.  I get the
 PD> error:
 PD> Application K:\EVENTCAD\ADS\ECINERT.EXP ERROR
 PD> :incorrect request for command list data

 PD> Here are three different code fragments which I have
 PD> tried. They all generate the same error.  The block
 PD> 10TOP72 can be manually inserted, and AutoLisp has no
 PD> problems with it.  I've checked the order of arguments
 PD> and they appear to be correct.  Does anybody have any
 PD> idea what could be the problem?


 PD> struct resbuf *tmp;
 PD> ads_point POINT;
 PD> float ROT,HEIGHT;
 PD> char *BLOCK;
 PD>
 PD>   BLOCK=strdup("10TOP72");
 PD>   ROT=0;
 PD>   HEIGHT=32.0
 PD>   POINT[X]=2846.0;
 PD>   POINT[Y]=1842.0;
 PD>   POINT[Z]=0.0;

 PD> 1)
 PD>   tmp=ads_buildlist(RTSTR,"_.INSERT",
 PD>                     RTSTR,BLOCK,
 PD>                     RTPOINT,POINT,
 PD>                     RTSTR,"",RTSTR,"",
 PD>                     RTREAL,ROT,
 PD>                     RTSTR,"",0);
 PD>       ads_retlist(tmp);
 PD>       ads_cmd(tmp);
 PD>       ads_relrb(tmp);
 PD>
 PD> 2)
 PD>      POINT[Z]=HEIGHT;
 PD>      ads_command(RTSTR,"_.INSERT",
 PD>                  RTSTR,BLOCK,
 PD>                  RT3DPOINT,POINT,
 PD>                  RTSTR,"",RTSTR,"",
 PD>                  RTREAL,ROT,
 PD>                  RTSTR,"",RTSTR,"",RTSTR,"",
 PD>                  RTSTR,"",RTSTR,"",RTSTR,"",0);

 PD> 3)
 PD>     ads_command(RTSTR,"_.INSERT",
 PD>                 RTSTR,"10TOP72",
 PD>                 RTPOINT,POINT,
 PD>                 RTSTR,"",RTSTR,"",RTSTR,"",RTSTR,"",0);

I'm guessing that you're looking for help from some other ADS developers.  I'm
in Technical Support here at WATCOM, and I'm afraid that the error message you
mentioned doesn't sound
like a WATCOM message.  Also, the above functions (ads_*) are unfamiliar. Have
you tried calling AutoCAD support?  If you find that it traces down to a
WATCOM problem, I'd be more than happy to
investigate.

Dan Cummins
WATCOM Languages Support

*** This is a reply to #1885.


From:    Jason Blochowiak                       Rec'd
To:      Kevin Kitsemetry                       Msg #1894, Nov-16-93 06:47AM
Subject: Locking for VM

 Ok, that makes sense - thanks. How does one go about locking down the entire
code segment (or chunk of code, or whatever you want to call it) and the
static data segment? Or, more specifically, how does one find the addresses of
the start & end of the code & data segments?

 Jason

*** This is a reply to #1825.  *** See also #1899.


From:    Anthony Scian                          Rec'd
To:      Rainer Schupp                          Msg #1897, Nov-16-93 04:38PM
Subject: comparison bug ?

DC> Internal Report #10430

 RS> The result of the following test-program will
 RS> be RIGHT if compiled with the 9.0 E-level
 RS> compiler, but will be WRONG if compiled with
 RS> the 9.5 A-level C++ compiler.

I've duplicated the problem but I'm not sure when a fix
will be available.

Anthony


 RS> #include <stdio.h>

 RS> unsigned char GetValue( void );


 RS> main()
 RS> {
 RS>  unsigned char stat = GetValue();
 RS>  if ((signed char)stat < 0)
 RS>    {
 RS>    if (stat < (unsigned char)0xC0)
 RS>      printf( "wrong" );
 RS>    else
 RS>      printf( "right" );
 RS>    }
 RS> }


 RS> unsigned char GetValue() {return (0xF0);}

*** This is a reply to #1888.  *** See also #1900.


From:    Dan Cummins                            Rec'd
To:      Jason Blochowiak                       Msg #1899, Nov-16-93 09:48PM
Subject: Locking for VM

 JB>  Ok, that makes sense - thanks. How does one go about
 JB> locking down the entire code segment (or chunk of
 JB> code, or whatever you want to call it) and the static
 JB> data segment? Or, more specifically, how does one find
 JB> the addresses of the start & end of the code & data
 JB> segments?

 JB>  Jason

I'm no expert - but here's a suggestion.  You can find out
what your CS and DS are using the library function segread(). Then (it
appears) you can pass the CS value, for example,
to DPMI function 000Bh, "Get Descriptor".  This will allow
you to obtain a copy of the descriptor table entry for your CS (you need to
pass an 8-byte buffer to hold the copy).

From this entry, you can extract the base address and limit of your selector.
This should be all the info you need.
Please refer to your nearest 80386 Programming Guide/Technical Reference for
the format of the descriptor table entry.  You will need to extract specific
bits to get the values you need.

Hope this helps.

Dan Cummins
WATCOM Languages Support

*** This is a reply to #1894.  *** See also #1925.


From:    Tom Hollins
To:      Tech support 9.5a C++32                Msg #1903, Nov-18-93 12:00AM
Subject: DVX XLIB compile problem its a C hdr with C++ processing nested class.

Hello, I have tried to solve this problem myself but have been unable to do
so. I just bought my compiler last week, the techinfo states it is at
patchlevel a. My makefile, and output follow, additional source can be
uploaded as you need. Essentially the C++ compiler will not process the Xlib.h
(which is a C header with correct protos) even though I have surrounded the
include files with the extern "C" { } directive. The compiler balks with an
error 263 nested class %N has not been defined and you guys write it off with
a "some working C code will not work unchanged" message in your manual. Well,
that won't float. We need some sort of work around or fix because I cannot go
into the X source and modify everything to the liking of this compiler. We
have tested this exact code with the GNU 2.2.2 compiler that came with DVX and
it worked fine, ran fine. Now its time to port to a commercial compiler
(license restrictions on GNU). Why is there a difference in the two
implementations of the compilers? Please give me a work around or a patch or
something to go by so I can continue my development otherwise we will have to
use the Microbrains uh microsoft compiler. Thank you for your time.

#
# Makefile for artemis.cc
#
# ATTENTION!!!   Do NOT use deadcode elimination because it will crash the
#                  program when it is run under dvx. yep.
#

extension        = .exe
filename         = artemis
additional_files = @linkfile.lst

obj_file1  = \x\global\sharemem
obj_file2  = artobj
obj_file3  = butwind
obj_file4  = artutil
obj_file5  = xpm
obj_file6  = mainwind
obj_file7  = statwind
obj_file8  = wind1
obj_file9  = wind2
obj_file10 = inputman

objs = $(obj_file1).obj $(obj_file2).obj $(obj_file3).obj $(obj_file4).obj &
 $(obj_file5).obj $(obj_file6).obj $(obj_file7).obj $(obj_file8).obj &
 $(obj_file9).obj $(obj_file10).obj $(filename).obj

exe_file      = $(filename)$(extension)
wcl_options   = /bt=dos /mf /l=dos4g /c
cpp_options   =
wlink_options = @\x\watlink.fle name $^@ file $^*

$(exe_file) : $(objs)
   wlink $(wlink_options) $(additional_files)
   !copy $(exe_file) \artemis\prog

$(obj_file1).obj: $(obj_file1).c
   wcl386 $(obj_file1) $(wcl_options) /fo=$^:

$(obj_file2).obj: $(obj_file2).cc
   wcl386 $(obj_file2) $(wcl_options) /fo=$^: $(cpp_options)

$(obj_file3).obj: $(obj_file3).cc
   wcl386 $(obj_file3) $(wcl_options) /fo=$^: $(cpp_options)

$(obj_file4).obj: $(obj_file4).cc
   wcl386 $(obj_file4) $(wcl_options) /fo=$^: $(cpp_options)

$(obj_file5).obj: $(obj_file5).c
   wcl386 $(obj_file5) $(wcl_options) /fo=$^:

$(obj_file6).obj: $(obj_file6).cc
   wcl386 $(obj_file6) $(wcl_options) /fo=$^: $(cpp_options)

$(obj_file7).obj: $(obj_file7).cc
   wcl386 $(obj_file7) $(wcl_options) /fo=$^: $(cpp_options)

$(obj_file8).obj: $(obj_file8).cc
   wcl386 $(obj_file8) $(wcl_options) /fo=$^: $(cpp_options)

$(obj_file9).obj: $(obj_file9).cc
   wcl386 $(obj_file9) $(wcl_options) /fo=$^: $(cpp_options)

$(obj_file10).obj: $(obj_file10).cc
   wcl386 $(obj_file10) $(wcl_options) /fo=$^: $(cpp_options)

$(filename).obj: $(filename).cc
   wcl386 $(filename) $(wcl_options) $(cpp_options)

WATCOM Make Version 3.2
Copyright by WATCOM International Corp. 1988, 1993. All rights reserved.
WATCOM is a trademark of WATCOM International Corp.
wcl386 artobj /bt=dos /mf /l=dos4g /c /fo=
WATCOM C/C++32 Compile and Link Utility Version 9.5
Copyright by WATCOM International Corp. 1988, 1993. All rights reserved.
WATCOM is a trademark of WATCOM International Corp.
       wpp386 artobj.cc  /bt=dos /mf /fo=
WATCOM C++32 Optimizing Compiler  Version 9.5a
Copyright by WATCOM International Corp. 1989, 1993. All rights reserved.

*** See also #1913.


From:    Tom Hollins
To:      Tech Support C++32 9.5a                Msg #1904, Nov-18-93 12:16AM
Subject: Desqview/X Xlib Header under C++ gives a nested class error

Okay, hopefully this message doesn't get trashed.
When compiling a C++ module using make with WCL an error 263 Nested class %N
has not been defined. Your manual writes this off with a "well some C stuff
won't run under C++ without modification". Well we have verified the code with
the GNU C++ compiler 2.2.2 which came with DVX and everything seemed to work
(except their licensing policy). I need an answer or workaround fast. I cannot
continue development with your compiler (which is a whole week old) and I will
be forced to use the Microbrain er Microsoft compiler. Please save us!!!!
Seriously, this should not occur since I have function protos (or DVX placed
them in the XLIB.H file) and I have an extern "C" {} around the #include files
(does this work for include files? you might want to check).
What I need from you folks: 1) a straight out fix, 2) a work around that
doesn't adversle impact my schedule (like going into all of the Xlib header
files and modifying them).
I will upload my compiler output (hopefully it won't trash this message again).
WATCOM Make Version 3.2
Copyright by WATCOM International Corp. 1988, 1993. All rights reserved.
WATCOM is a trademark of WATCOM International Corp.
        wcl386 artobj /bt=dos /mf /l=dos4g /c /fo=
WATCOM C/C++32 Compile and Link Utility Version 9.5
Copyright by WATCOM International Corp. 1988, 1993. All rights reserved.
WATCOM is a trademark of WATCOM International Corp.
       wpp386 artobj.cc  /bt=dos /mf /fo=
WATCOM C++32 Optimizing Compiler  Version 9.5a
Copyright by WATCOM International Corp. 1989, 1993. All rights reserved.
WATCOM is a trademark of WATCOM International Corp.
c:\watcom\h\X11/Xlib.h(304): Error! E263: (col 1) nested class '_XDisplay' has
not been defined
c:\watcom\h\X11/Xlib.h(304): Note! N393: (col 1) included from
c:\watcom\h\X11/Intrinsi.h(33)
c:\watcom\h\X11/Xlib.h(304): Note! N393: (col 1) included from artobj.cc(42)
c:\watcom\h\X11/Xlib.h(613): Error! E263: (col 1) nested class 'XKeytrans' has
not been defined
c:\watcom\h\X11/Xlib.h(613): Error! E263: (col 1) nested class
'_XrmHashBucketRec' has not been defined
c:\watcom\h\X11/Xlib.h(613): Error! E263: (col 1) nested class '_XSQEvent' has
not been defined
c:\watcom\h\sys/time.h(25): Warning! W481: (col 17) class/enum has the same
name as the function/variable 'timezone'
c:\watcom\h\sys/time.h(25): Note! N392: (col 17) 'long timezone' defined in:
c:\watcom\h\time.h(76) (col 17)
c:\watcom\h\sys/time.h(25): Note! N393: (col 17) included from
c:\watcom\h\X11/Xos.h(164)
c:\watcom\h\sys/time.h(25): Note! N393: (col 17) included from
c:\watcom\h\X11/Intrinsi.h(36)
c:\watcom\h\sys/time.h(25): Note! N393: (col 17) included from artobj.cc(42)
artemis.h(49): Error! E117: (col 22) too many storage class specifiers
artemis.h(49): Note! N393: (col 22) included from artobj.cc(53)
artemis.h(49): Error! E326: (col 38) defining 'fname_language' is not possible
because its type has unknown size
artemis.h(49): Note! N392: (col 38) 'char * fname_language[]' defined in:
artemis.h(49) (col 22)
artemis.g(47): Error! E328: (col 32) storage class of 'fname_language'
conflicts with previous declaration
artemis.g(47): Note! N392: (col 32) 'char * fname_language[]' defined in:
artemis.g(47) (col 15)
artemis.g(47): Note! N393: (col 32) included from artobj.cc(54)
artemis.g(47): Error! E042: (col 32) symbol 'fname_language' already defined
artemis.g(47): Note! N392: (col 32) 'char * fname_language[]' defined in:
artemis.h(49) (col 22)
artobj.cc: 384 lines, included 14157, 1 warning, 8 errors
Error: Compiler returned a bad status compiling 'artobj.cc'
Error(E42): Last command making (artobj.obj) returned a bad status
Error(E02): Make execution terminated


From:    Ron Smith
To:      Tech Support                           Msg #1906, Nov-18-93 04:19PM
Subject: Dynamic Overlays

The Dynamic Overlay option DOES NOT WORK!!!!
We have a VERY SIMPLE program that illustrates the effect.  It is called
BADOVLS.ZIP and is in the C/C++ 9.5 Problems and Fixes File Area.
PLEASE HELP.  We are waiting for a call back from your tech support but we
need an answer SOON!
THANKS.

BTW - Hasn't anyone else used this option???

*** See also #1908.


From:    Mike Brennen
To:      Tech Support                           Msg #1907, Nov-18-93 04:57PM
Subject: wildargs under C++

while I'm logged in to get 9.5 patch a, i'll throw a question in also.  i
noticed today that linking wildargv into a c++ link causes the linker to abort
with undefined symbols; is wildargv not allowed with c++????  thanks

*** See also #1909.


From:    Mike Paola
To:      Ron Smith                              Msg #1908, Nov-18-93 05:12PM
Subject: Dynamic Overlays

 RS> The Dynamic Overlay option DOES NOT WORK!!!!
 RS> We have a VERY SIMPLE program that illustrates the
 RS> effect.  It is called BADOVLS.ZIP and is in the C/C++
 RS> 9.5 Problems and Fixes File Area.
 RS> PLEASE HELP.  We are waiting for a call back from your
 RS> tech support but we need an answer SOON!
 RS> THANKS.

Ron, we're looking into it - thanks for the concise example. Incident Number:
10776

*** This is a reply to #1906.


From:    Mike Paola                             Rec'd
To:      Mike Brennen                           Msg #1909, Nov-18-93 05:28PM
Subject: wildargs under C++

 MB> while I'm logged in to get 9.5 patch a, i'll throw a
 MB> question in also.  i noticed today that linking
 MB> wildargv into a c++ link causes the linker to abort
 MB> with undefined symbols; is wildargv not allowed with
 MB> c++????  thanks

In the B-level patches, we've modified WILDARGV so that it can be compiled
with C++ as well.  The current one can't.

*** This is a reply to #1907.


From:    Mike Paola
To:      Ron Smith                              Msg #1910, Nov-18-93 05:29PM
Subject: Dynamic Overlays

 RS> The Dynamic Overlay option DOES NOT WORK!!!!
 RS> We have a VERY SIMPLE program that illustrates the
 RS> effect.  It is called BADOVLS.ZIP and is in the C/C++
 RS> 9.5 Problems and Fixes File Area.
 RS> PLEASE HELP.  We are waiting for a call back from your
 RS> tech support but we need an answer SOON!
 RS> THANKS.

The problem turned out to be your use of the -zc option.  You can't use this
with overlays since the code segment can move around on you.  Turning this
option off fixed the problem.

*** This is a reply to #1906.


From:    Mans Agevik
To:      All                                    Msg #1911, Nov-18-93 05:39PM
Subject: Free memory

Hi!

I have a question regarding how to determine the amount of free memory left.
When I use _memavl() (which according to the manual should work with DOS/32)
it reports 4004 bytes left when there actually is more than 30MB left...
I also tried the DPMI function 500, but when I free some allocated memory
the amount of free memory returned is not increased. Am I missing something
here or am I just plain stupid? Thanks in advance.

//MCA

*** See also #1913.


From:    Lam Lee                                Rec'd
To:      Dan Cummins                            Msg #1912, Nov-18-93 09:43PM
Subject: Watcom C9.5A DLL Bug

DC> Internal Report #10689

Hi,

I'm still having big problem rebuild our 32 bit DLL under the new C compiler
9.5a.  I have called in tech support but so far has not received an answer,so
I thought I will provide some additional info:

* We have a 16 bit windows program (using MSC 60AX) called a Watcom 32bit DLL
program, which is about 1.3 MB.  Everything was working OK under C 9.01e
release.

* We just added support for this product to talk to Watcom SQL, using the just
released version which forced us to upgrade to 9.5 (since the latest Watcom
SQL does not work with 9.01).

* We got 9.5, but could not use it because of the StrechDiBit bug, since we do
a lots of graphic operation.

* We waited and upgrade to patch A as soon as it was available.  Changed the
makefile to take care of the new windows include directory, the new 'wrc'
command, recompile the whole 32 bit DLL appication.  Not a single line of code
has changed.  We have GPF as soon as a call from the 16 bit code is made to
the 32bit DLL.

* We downloaded the latest supervisors (dated 10/5) and relink our dll. Same
GPF at same place.  We also tried in bump up the stack/heap space but same
result.

So please help because we got a big release coming up.  I have zip up several
log file from Dr.Watcom and Heapwalker to provide some more data.  Here are
some additional info:

The 16 bit code is compiled using medium memory model.  It's about 300K. I
compiled Watcom's DLL test program MSC16 & DLL32, and it works.  I use the
same MSC16.EXE program to call our large 32b DLL and it WORKED.

We recompile using 9.5 without patch A and it seems to work (there is some
other GPF but at least I was talking to the DLL).

So, can someone tell me a little more about what changes between 9.5 and 9.5A
that could cause this problem.  I would zip our code and send it up if I have
to (but it is too large).  Any help would be greatly appreciated.

Lam Le
Enc. watbug.zip


From:    Dan Cummins                            Rec'd
To:      Mans Agevik                            Msg #1913, Nov-18-93 09:26PM
Subject: Free memory

 MA> Hi!

 MA> I have a question regarding how to determine the
 MA> amount of free memory left.
 MA> When I use _memavl() (which according to the manual
 MA> should work with DOS/32)
 MA> it reports 4004 bytes left when there actually is more than 30MB left...
 MA> I also tried the DPMI function 500, but when I free some allocated memory
 MA> the amount of free memory returned is not increased.
 MA> Am I missing something here or am I just plain stupid?
 MA> Thanks in advance.

 MA> //MCA

The _memavl() "works" but does not always return meaningful results,even in
the 16-bit world, and is documented as such.  The example for _memavl() calls
_nheapgrow() - and you will notice that the _heapgrow functions are not
supported in the 32-bit library.  The information you are looking for will
probably not be provided by these library functions.

If you use DPMI 500h you will be getting information about free memory in the
system.  If your application has malloced memory before this call, and you
free the memory, you will not see the memory returned to the system heap
space.  This is because it remains in the application heap space, in case your
app does another malloc later.  Once you do a malloc(), memory is
moved from the system heap to the application heap.  The CLIB memory
management routines take over the management of your application's memory.

If you want mallocs and frees to go directly to and from
system memory then you can use DPMI 501h, 502h and 503h.

Dan Cummins
WATCOM Languages Support

*** This is a reply to #1911.  *** See also #1918.


From:    Brian Burton                           Rec'd
To:      Kevin Kitsemetry                       Msg #1914, Nov-18-93 09:40PM
Subject: Windows NT exception handling

Could you please share the current status with the rest of us?
Is there any preliminary estimate of when NT style exceptions
will be supported?

Thanks
KK> Contacted customer directly.


 NK> Some time ago I left a message saying that we wanted
 NK> to use Watcom on our NT project, but that we needed to
 NK> be able to catch the NT exceptions (thrown by
 NK> RaiseException()). I received a reply that said
 NK> that,although Watcom didn't currently work with the NT
 NK> exception handling scheme,Watcom was "looking into it".

 NK> I did some more investigation, thinking I
 NK> could get something working. I
 NK> was wrong: there is an undocumented interface to the
 NK> Windows NT exception handling that Microsoft only
 NK> shows to compiler vendors.

 NK> So I'm back to asking for help from Watcom. I'd like
 NK> to talk to whoever is "looking at" NT exception
 NK> handling, so I can tell them about our immediate needs
 NK> in this area.

 NK> What we need right now is a way to catch NT software
 NK> exceptions raised by system calls (especially the RPC
 NK> calls), and throw real C++ exceptions which correspond
 NK> to the NT exception code.

 NK> I can be reached at [phone], or on compuserve as
 NK> 76046,223, or via the Internet as
 NK> [e-mail]

 NK> Thanks.

*** This is a reply to #1656.  *** See also #1930.


From:    Kip Compton                            Rec'd
To:      Kevin Kitsemetry                       Msg #1915, Nov-19-93 02:23AM
Subject: NT Stuff

I recently bought your compiler mostly for NT work...I have a few
comments/questions:

(1) I can't seem to call some of the Win32 functions.  I noticed that most of
the header files aren't there.  Do I need to buy some extra SDK to be able to
call Win32 functions?  It seems that some of the API is there (in particular
the console API -- is part of the SDK there and not the rest?)  If I do buy
the Win32 SDK, what parts do I use with WATCOM?  I know that it comes with the
Microsoft compiler, or at least the pre-release version did.

(2) I compiled a program where I had forgotten the ) on a call to malloc and
right after wpp386 spit up the error NT claimed that wcpp386 had attempted to
read memory location 0...

(3) When will patch level B be available?  I noticed that you said in a msg
that problems with wmake and long paths will be fixed in them.

Thanks,
Kip

*** See also #1921.


From:    Mats Manhav                            Rec'd
To:      Kevin Kitsemetry                       Msg #1916, Nov-19-93 06:03AM
Subject: reading files and Watcom 9.5

Hallo Watcom,

In the file %WATCOM%\src\win\edit\efile.c there is a function FileEdit. In
that function you open a file with open(), and read it with _dos_read().

I have an editor where I open a file with OpenFile() and read it with read().

This worked fine in WATCOM C386 9.01d with patch level e applied. It does not
work under 9.5.

If I instead use OpenFile() and _dos_read() it works.

Here is the function FileEdit edited to not work under 9.5

void FileEdit( LPEDATA ed, BOOL openfile )
{
    LOCALHANDLE hbuff_new,hbuff_old;
    char        fname[_MAX_PATH];
    char        str[128];
    long int    len=0;
    char        _FAR *buff;
    int  rc;
    int  h;
    unsigned    bytes;

    if( !CheckFileSave( ed ) ) return;
    if( openfile ) {
        if( !GetFileName( ed, FILE_OPEN, fname ) ) return;
    } else {
        fname[0] = 0;
    }

    /*
     * get file size, and get a buffer
     */
    if( fname[0] != 0 ) {
//      h = open( fname, O_RDONLY | O_BINARY );

   h = OpenFile( fname, (LPOFSTRUCT)&OfStruct, OF_READ);

        if( h < 0 ) {
            sprintf( str,"Could not open file %s", fname );
            MessageBox( ed->hwnd, str, EditTitle, MB_OK );
            return;
        }
        len = filelength( h );
    }
    if( len >= 0xFFFFL || (hbuff_new = LocalAlloc( LMEM_MOVEABLE |
         LMEM_ZEROINIT, (WORD) len+1 ) ) == NULL ) {
        sprintf( str, "File %s is too big (%ld bytes)", fname, len+1 );
        MessageBox( ed->hwnd, str, EditTitle, MB_OK );
        return;
    }

    /*
     * read into temp. buffer, then copy to edit area
     */
    if( fname[0] != 0 ) {
        buff = MemAlloc( len + 1 );
//      rc = _dos_read( h, buff, len, &bytes );
   bytes = read(h, buff, len);
   close( h );
//      if( rc || bytes != len ) {
        if( bytes != len ) {
            sprintf( str,"Could not read file %s", fname );
            MessageBox( ed->hwnd, str, EditTitle, MB_OK );
            LocalFree( hbuff_new );
            MemFree( buff );
            return;
        }
        _fmemcpy( MK_LOCAL32( LocalLock( hbuff_new ) ), buff, len );
        LocalUnlock( hbuff_new );
        MemFree( buff );
    }

    /*
     * clear out old buffer, and set new one
     */
    hbuff_old = SendMessage( ed->editwnd, EM_GETHANDLE, 0, 0L );
    LocalFree( hbuff_old );
    SendMessage( ed->editwnd, EM_SETHANDLE, hbuff_new, 0L );
    NewFileName( ed, fname );
    ed->needs_saving = FALSE;

} /* FileEdit */



I don't need a fix or something for this since I solved the problem. I just
like to adress you of the problem, cause maybe it is a bug somewhere.

/ Moonsea

*** See also #1940.


From:    Mans Agevik                            Rec'd
To:      Dan Cummins                            Msg #1918, Nov-19-93 09:53AM
Subject: Free memory

 MA> When I use _memavl() (which according to the manual
 MA> should work with DOS/32)
 MA> it reports 4004 bytes left when there actually is
 MA> more than 30MB left...

 DC> functions are not supported in the 32-bit library.  The
 DC> information you are looking for will probably not be
 DC> provided by these library functions.

Yes, I realize that but is there some other way to get the memory
amount (short of allocating and calculating how much you end up with)?
I have grown quiet attached to the new and delete operators
and I would hate to have to go through the DPMI interface...

//MCA

*** This is a reply to #1913.  *** See also #1922.


From:    Christer Palm                          Rec'd
To:      Phil Duvalsaint                        Msg #1919, Nov-19-93 09:55AM
Subject: Autocad ads_command troubles

I tried to duplicate your problem. But here it just went fine.
The error message you got is typical when you try to do ads_cmd or ads_command
when a dialog box is on-screen.

Looking at your code, however, reveals some secondary errors:

First, the angle should be declared as an ads_real (which is typedef'd to
double), and not float. However since the compiler always pushes a double for
floating-point values in a variable argument list, this is not a problem in
your case.

Secondly, you shouldn't do strdup() on the strings passed to ads_buildlist(),
since ads_buildlist does this for you.

        /Christer Palm
         TeamCAD AB

*** This is a reply to #1885.


From:    Christer Palm                          Rec'd
To:      Kevin Kitsemetry                       Msg #1920, Nov-19-93 10:08AM
Subject: WVIDEO and A level patch

Finally, I've now got my hands on the A-level patches..
However, after I applied the patches, WVIDEO started to behave strange.
I use a secondary monochrome adapter for WVIDEO debugging AutoCAD ADS programs.
When first activated, and while loading AutoCAD, WVIDEO looks like before. But
when WVIDEO traps into my program, part of the screen turns into reversed
video(!), and I get horizontal lines all over the screen.
We have two completely different systems set up here, and both behaves the
same way after applying the patch.

It seems like WVIDEO fiddles with the character generator or some MDA
registers in the wrong way.

Very annoying!

  /Christer Palm
   TeamCAD AB

*** See also #1941.


From:    Dan Cummins                            Rec'd
To:      Kip Compton                            Msg #1921, Nov-19-93 11:24AM
Subject: NT Stuff

 KC> I recently bought your compiler mostly for NT work...I
 KC> have a few comments/questions:

 KC> (1) I can't seem to call some of the Win32 functions.  I noticed that
 KC> most of the header files aren't there.  Do I need to
 KC> buy some extra SDK to be able to call Win32 functions?
 KC>  It seems that some of the API is there (in particular
 KC> the console API -- is part of the SDK there and not
 KC> the rest?)  If I do buy the Win32 SDK, what parts do I
 KC> use with WATCOM?  I know that it comes with the
 KC> Microsoft compiler, or at least the pre-release
 KC> version did.

We only provide the WINDOWS.H and WINCON.H.  The rest of the header files come
from Microsoft.  You will have to purchase the NT SDK if you don't have it
already.

 KC> (2) I compiled a program where I had forgotten the )
 KC> on a call to malloc and right after wpp386 spit up the
 KC> error NT claimed that wcpp386 had attempted to read
 KC> memory location 0...

We would need a short example that reproduces the problem
as well as the compile and link options you used to build it.

 KC> (3) When will patch level B be available?  I noticed
 KC> that you said in a msg that problems with wmake and
 KC> long paths will be fixed in them.

The B-level patches must still go through the proper builds and QA stages.
They are targeted for "the next few weeks",but I can't give any guarantees as
to the time frame.

 KC> Thanks,
 KC> Kip

Dan Cummins
WATCOM Languages Supoprt

*** This is a reply to #1915.


From:    Dan Cummins                            Rec'd
To:      Mans Agevik                            Msg #1922, Nov-19-93 11:55AM
Subject: Free memory

 MA> When I use _memavl() (which according to the manual
 MA> should work with DOS/32)
 MA> it reports 4004 bytes left when there actually is
 MA> more than 30MB left...

 DC> functions are not supported in the 32-bit library.  The
 DC> information you are looking for will probably not be
 DC> provided by these library functions.

 MA> Yes, I realize that but is there some other way to get the memory
 MA> amount (short of allocating and calculating how much you end up with)?
 MA> I have grown quiet attached to the new and delete operators
 MA> and I would hate to have to go through the DPMI interface...

 MA> //MCA

Unfortunately the answer is... not that I know of.  If you have to allocate-
and-calculate, start with a very large amount and allocate succesively smaller
chunks until you get a successful malloc (or something along those lines).

Do not do it the other way (allocating successively larger chunks until you
run out) or it will appear that you will not be able to allocate all of your
memory (due to behavioural issues of our memory mamager).

Dan Cummins
WATCOM Languages Support

*** This is a reply to #1918.


From:    Michael Hung
To:      Watcom                                 Msg #1923, Nov-19-93 07:10PM
Subject: Computer hangs

I have been using WatcomC 9.5a to compile some raytracing programs,
I used the /fpi option.  The program work fine in 386 machines but
DOS4GW received an "Unexpected Interrupt" before the program starts on
the other machine with a 387.  Also, when tried to run the program
compiled with /4r /7 option on a 486 machine, the situation also
happened.  Is anyone experienced that ?  The program worked fine with
all the machines without math-coprocessor I tried.  (386-33, 386-25, and
a 386SX-16)

Thanks
Michael

*** See also #1931.


From:    Tom Hollins
To:      C/C++32 9.5 Tech Support               Msg #1924, Nov-19-93 10:32PM
Subject: Linking Watcom C libs into Watcom C++ progs

I am not sure as to what the exact problem is, except that it looks like the C
libraries for Desqview/X cannot be recognized by the C++ compiler (unknown
record length during link). Is this the problem I am having? I have "fixed" my
code to work with the Watcom 9.5a C++ compiler and when I finally get all of
the modules "fixed" then I get a link error message stating that the records
cannot be recognized.
The exact message is "invalid record type 0x002f" then the next line is
"premature end of file".
Can you guys and quartedeck figure this out? Is there a fix in the works, or
are you writing off the compiler for Quarterdeck operations. I really need to
know, because if you are writing it off then I have to port the C++ code I've
already written back into C.
I have to say this has been a terrible lesson to learn. My development
schedule just got hacked a full week by switching to your compiler. Something
I thought would take two days (programmer days, not man days).
Thank you for your time.
-T-

*** See also #1932.


From:    Jason Blochowiak                       Rec'd
To:      Dan Cummins                            Msg #1925, Nov-20-93 06:37AM
Subject: Locking for VM

 Ok, that makes sense - thanks. Actually, it make so much sense, I'm
embarassed I didn't think of it... :)

 Will that work for DS as well? Will it only work before doing a malloc(), or
does malloc() even mess with DS's limit? Remember, I'm only interested in
locking down the predefined data.

 Thanks again,
  Jason

*** This is a reply to #1899.  *** See also #1944.


From:    John Hamilton
To:      Tech Support                           Msg #1927, Nov-21-93 12:53AM
Subject: Allocating all memory

I'm attempting to allocate the largest available block as reported
by DPMI function 500h.  I'm using DPMI function 501h to allocate
the memory.  The largest available chunk reported by 500h cannot
be allocated.  I've tried various ways to try and find out
the actual amount, but none are reliable.  How can I determine
the actual largest available chunk?

Thanks,

John Hamilton

*** See also #1933.


From:    Stephen Baum
To:      All                                    Msg #1928, Nov-21-93 10:30AM
Subject: DOS4GW and OS/2

I have a shipping product which runs under the Rational extender. A few
customers use it in a DOS box under OS/2. Configuration is something of a
bear, but they can generally get it to work well enough. The application
drives a variety of scanners and does OCR. One customer is reporting that
sometimes when he starts scanning (he's using an HP IIC scanner, which I drive
using HPII.SYS) the program exits with a Transfer Stack Overflow message. If
he successfully completes the first scan, the product will behave itself
thereafter. He has been unable to discern any real pattern to it other than
that.

Can anyone give me a hint as to what I should look for?

Stephen Baum

*** See also #1934.


From:    Mans Agevik
To:      Tech support                           Msg #1929, Nov-22-93 10:33AM
Subject: Exception

Hi!
When I try to use WCValSListIter::current() it throws an exception back
at me and the manual does not say which exceptions it can throw or what
causes the exceptions, could you help me? By the way, is the RTL source
available for purchase?

//MCA

*** See also #1935.


From:    Kevin Kitsemetry
To:      Brian Burton                           Msg #1930, Nov-22-93 06:08PM
Subject: Windows NT exception handling

 BB> Could you please share the current status with the rest of us?
 BB> Is there any preliminary estimate of when NT style exceptions
 BB> will be supported?
 BB>
 BB> Thanks

I talked with the C++ development team, but they could only tell me that it
was on the list of things to do.  So no time estimate yet.


Kevin Kitsemetry
WATCOM TECHNICAL SUPPORT

*** This is a reply to #1914.


From:    Kevin Kitsemetry                       Rec'd
To:      Michael Hung                           Msg #1931, Nov-22-93 06:21PM
Subject: Computer hangs

 MH> I have been using WatcomC 9.5a to compile some raytracing programs,
 MH> I used the /fpi option.  The program work fine in 386 machines but
 MH> DOS4GW received an "Unexpected Interrupt" before the program starts on
 MH> the other machine with a 387.  Also, when tried to run the program
 MH> compiled with /4r /7 option on a 486 machine, the situation also
 MH> happened.  Is anyone experienced that ?  The program worked fine with
 MH> all the machines without math-coprocessor I tried.  (386-33, 386-25, and
 MH> a 386SX-16)

I haven't head of this happending with the A-level patches.  This is the
default option (/fpi) if no other floating point option is specified. Can you
send us a sample that reproduced the problem?


Kevin Kitsemetry
WATCOM TECHNICAL SUPPORT

*** This is a reply to #1923.


From:    Kevin Kitsemetry                       Rec'd
To:      Tom Hollins                            Msg #1932, Nov-22-93 06:31PM
Subject: Linking Watcom C libs into Watcom C++ progs

 TH> I am not sure as to what the exact problem is, except
 TH> that it looks like the C libraries for Desqview/X
 TH> cannot be recognized by the C++ compiler (unknown
 TH> record length during link). Is this the problem I am
 TH> having? I have "fixed" my code to work with the Watcom
 TH> 9.5a C++ compiler and when I finally get all of the
 TH> modules "fixed" then I get a link error message
 TH> stating that the records cannot be recognized.
 TH> The exact message is "invalid record type 0x002f" then
 TH> the next line is "premature end of file".
 TH> Can you guys and quartedeck figure this out? Is there
 TH> a fix in the works, or are you writing off the
 TH> compiler for Quarterdeck operations. I really need to
 TH> know, because if you are writing it off then I have to
 TH> port the C++ code I've already written back into C.

It sounds from your message like you have been talking to someone,but I am not
sure who and I don't recognize the kind of errors that you are running into.
What have the people at Quaterdeck told you?


Kevin Kitsemetry
WATCOM TECHNICAL SUPPORT

*** This is a reply to #1924.  *** See also #1938.


From:    Kevin Kitsemetry                       Rec'd
To:      John Hamilton                          Msg #1933, Nov-22-93 06:38PM
Subject: Allocating all memory

 JH> I'm attempting to allocate the largest available block as reported
 JH> by DPMI function 500h.  I'm using DPMI function 501h to allocate
 JH> the memory.  The largest available chunk reported by 500h cannot
 JH> be allocated.  I've tried various ways to try and find out
 JH> the actual amount, but none are reliable.  How can I determine
 JH> the actual largest available chunk?

There are a couple of files relating to memory issues with the Rational DOS
extender in File Area 10.  Specifically, take a look at the file called
RSIMEM.C.  It is an example of how to allocate the largest available block of
memory with the Rational extender.


Kevin Kitsemetry
WATCOM TECHNICAL SUPPORT

*** This is a reply to #1927.  *** See also #1936.


From:    Kevin Kitsemetry                       Rec'd
To:      Stephen Baum                           Msg #1934, Nov-22-93 06:44PM
Subject: DOS4GW and OS/2

 SB> I have a shipping product which runs under the Rational extender. A few
 SB> customers use it in a DOS box under OS/2.
 SB> Configuration is something of a bear, but they can
 SB> generally get it to work well enough. The application
 SB> drives a variety of scanners and does OCR. One
 SB> customer is reporting that sometimes when he starts
 SB> scanning (he's using an HP IIC scanner, which I drive
 SB> using HPII.SYS) the program exits with a Transfer
 SB> Stack Overflow message. If he successfully completes
 SB> the first scan, the product will behave itself
 SB> thereafter. He has been unable to discern any real
 SB> pattern to it other than that.

I am not sure why the problem would be so intermittent.  Usually,this error is
causes by a recursive interrupt overloading the transfer stack (a small stack
maintained by DOS/4GW to pass data between real and protected mode) or by an
attemp to long jump out of your own handler (contrary to DPMI spec.).


Kevin Kitsemetry
WATCOM TECHNICAL SUPPORT

*** This is a reply to #1928.  *** See also #1937.


From:    Kevin Kitsemetry
To:      Mans Agevik                            Msg #1935, Nov-22-93 06:49PM
Subject: Exception

 MA> Hi!
 MA> When I try to use WCValSListIter::current() it throws an exception back
 MA> at me and the manual does not say which exceptions it can throw or what
 MA> causes the exceptions, could you help me? By the way, is the RTL source
 MA> available for purchase?

Send us a small example that demonstrates the problem and we will try to
reproduce it here.


Kevin Kitsemetry
WATCOM TECHNICAL SUPPORT

*** This is a reply to #1929.


From:    John Hamilton                          Rec'd
To:      Kevin Kitsemetry                       Msg #1936, Nov-22-93 11:19PM
Subject: Allocating all memory

Thanks.  Rsimem.c had the answer.

*** This is a reply to #1933.


From:    Dan Teven                              Rec'd
To:      Kevin Kitsemetry                       Msg #1937, Nov-23-93 04:27PM
Subject: DOS4GW and OS/2

Which version of DOS/4GW?

Dan Teven
Rational Systems

*** This is a reply to #1934.


From:    Tom Hollins                            Rec'd
To:      Kevin Kitsemetry                       Msg #1938, Nov-23-93 11:08PM
Subject: Linking Watcom C libs into Watcom C++ progs

I have a direct line into Quarterdeck DVX support. THey understand that C++
Watcom should not be used because of problems, but the C compiler definitely
works (which I agree with). Well the point is moot currently since we will be
porting the current code back into C and will have to stick with C from now on.
Most of the research into the problems I have found I have done with some
additional info from Qdeck support.
Also, I have heard that the C compiler 9.5 is supposed to be at rev level "c".
Is this for the genereal public (like me?). If it is on the board as of the
last few days I haven't looked yet and I will download it if I find it, but
could only find rev level "a" stuff.
Thank you for your time.
-T-

*** This is a reply to #1932.  *** See also #1943.


From:    Dan Cummins                            Rec'd
To:      Mats Manhav                            Msg #1940, Nov-24-93 12:42AM
Subject: reading files and Watcom 9.5

 MM> Hallo Watcom,

 MM> In the file %WATCOM%\src\win\edit\efile.c there is a
 MM> function FileEdit. In that function you open a file
 MM> with open(), and read it with _dos_read().

 MM> I have an editor where I open a file with OpenFile()
 MM> and read it with read().

 MM> This worked fine in WATCOM C386 9.01d with patch level
 MM> e applied. It does not work under 9.5.

 MM> If I instead use OpenFile() and _dos_read() it works.

 MM> Here is the function FileEdit edited to not work under 9.5

 MM> void FileEdit( LPEDATA ed, BOOL openfile )
 MM> {
 MM>     LOCALHANDLE hbuff_new,hbuff_old;
 MM>     char        fname[_MAX_PATH];
 MM>     char        str[128];
 MM>     long int    len=0;
 MM>     char        _FAR *buff;
 MM>     int  rc;
 MM>     int  h;
 MM>     unsigned    bytes;

 MM>     if( !CheckFileSave( ed ) ) return;
 MM>     if( openfile ) {
 MM>         if( !GetFileName( ed, FILE_OPEN, fname ) ) return;
 MM>     } else {
 MM>         fname[0] = 0;
 MM>     }

 MM>     /*
 MM>      * get file size, and get a buffer
 MM>      */
 MM>     if( fname[0] != 0 ) {
 MM> //      h = open( fname, O_RDONLY | O_BINARY );

 MM>    h = OpenFile( fname, (LPOFSTRUCT)&OfStruct, OF_READ);

 MM>         if( h < 0 ) {
 MM>             sprintf( str,"Could not open file %s", fname );
 MM>             MessageBox( ed->hwnd, str, EditTitle, MB_OK );
 MM>             return;
 MM>         }
 MM>         len = filelength( h );
 MM>     }
 MM>     if( len >= 0xFFFFL || (hbuff_new = LocalAlloc( LMEM_MOVEABLE |
 MM>          LMEM_ZEROINIT, (WORD) len+1 ) ) == NULL ) {
 MM>         sprintf( str, "File %s is too big (%ld bytes)", fname, len+1 );
 MM>         MessageBox( ed->hwnd, str, EditTitle, MB_OK );
 MM>         return;
 MM>     }

 MM>     /*
 MM>      * read into temp. buffer, then copy to edit area
 MM>      */
 MM>     if( fname[0] != 0 ) {
 MM>         buff = MemAlloc( len + 1 );
 MM> //      rc = _dos_read( h, buff, len, &bytes );
 MM>    bytes = read(h, buff, len);
 MM>    close( h );
 MM> //      if( rc || bytes != len ) {
 MM>         if( bytes != len ) {
 MM>             sprintf( str,"Could not read file %s", fname );
 MM>             MessageBox( ed->hwnd, str, EditTitle, MB_OK );
 MM>             LocalFree( hbuff_new );
 MM>             MemFree( buff );
 MM>             return;
 MM>         }
 MM>         _fmemcpy( MK_LOCAL32( LocalLock( hbuff_new ) ), buff, len );
 MM>         LocalUnlock( hbuff_new );
 MM>         MemFree( buff );
 MM>     }

 MM>     /*
 MM>      * clear out old buffer, and set new one
 MM>      */
 MM>     hbuff_old = SendMessage( ed->editwnd, EM_GETHANDLE, 0, 0L );
 MM>     LocalFree( hbuff_old );
 MM>     SendMessage( ed->editwnd, EM_SETHANDLE, hbuff_new, 0L );
 MM>     NewFileName( ed, fname );
 MM>     ed->needs_saving = FALSE;

 MM> } /* FileEdit */



 MM> I don't need a fix or something for this since I
 MM> solved the problem. I just like to adress you of the
 MM> problem, cause maybe it is a bug somewhere.

 MM> / Moonsea

Thanks, I will log your problem report.  If I have any
problems reproducing it, etc. I'll let you know.

Dan Cummins
WATCOM Languages Support

*** This is a reply to #1916.


From:    Dan Cummins                            Rec'd
To:      Christer Palm                          Msg #1941, Nov-24-93 12:44AM
Subject: WVIDEO and A level patch

 CP> Finally, I've now got my hands on the A-level patches..
 CP> However, after I applied the patches, WVIDEO started to behave strange.
 CP> I use a secondary monochrome adapter for WVIDEO
 CP> debugging AutoCAD ADS programs.
 CP> When first activated, and while loading AutoCAD,
 CP> WVIDEO looks like before. But when WVIDEO traps into
 CP> my program, part of the screen turns into reversed
 CP> video(!), and I get horizontal lines all over the
 CP> screen.
 CP> We have two completely different systems set up here, and both behaves
 CP> the same way after applying the patch.

 CP> It seems like WVIDEO fiddles with the character
 CP> generator or some MDA registers in the wrong way.

 CP> Very annoying!

 CP>   /Christer Palm
 CP>    TeamCAD AB

I haven't heard of this problem.  It sounds like we would
need an example from you to reproduce it here.

Dan Cummins
WATCOM Languages Support

*** This is a reply to #1920.  *** See also #1981.


From:    Kevin Kitsemetry                       Rec'd
To:      Edward Palandri                        Msg #1942, Nov-24-93 01:47PM
Subject: 32 bit Fortran Windows DLL, ok with Fortran 9.01, fails with 9.5a

 EP> Problem with Watcom Fortran 32 bit DLL's compiled using Fortran/386 9.5a
 EP> ========================================================================
 EP>
 EP>
 EP> I have recently attempted to upgrade to C and Fortran 9.5 and I have
 EP> run into a problem.
 EP>
 EP> Basically the 32 bit DLL's that I compile and run successfully using
 EP> Fortran and C 9.01e do not work or work erratically if I compile them
 EP> using Fortran and C 9.5a.
 EP>
 EP> Please let me know if there is some obvious modification I need to
 EP> make to get this to work under 9.5a

A couple of things have to be changed.  Our development team did find a
problem in one of the startup modules for DLL's.  I have placed this in the
secret file area as per the voice message I left for you.  Just link this
object file in with the DLL source when creating the DLL.

Secondly, you must modify either the 16-bit caller or the 32-bit DLL to ensure
that the size of the parameters (16-bit vs 32-bit integers) match.  If you
wish to change the 16-bit C code, make the integers being passed to the DLL
'LONG'.  Alternatively, you can make the DLL accpet INTEGER*2.


Kevin Kitsemetry
WATCOM TECHNICAL SUPPORT

*** This is a reply to #1733.


From:    Kevin Kitsemetry                       Rec'd
To:      Tom Hollins                            Msg #1943, Nov-24-93 01:44PM
Subject: Linking Watcom C libs into Watcom C++ progs

 TH> I have a direct line into Quarterdeck DVX support.
 TH> THey understand that C++ Watcom should not be used
 TH> because of problems, but the C compiler definitely
 TH> works (which I agree with). Well the point is moot
 TH> currently since we will be porting the current code
 TH> back into C and will have to stick with C from now on.
 TH> Most of the research into the problems I have found I
 TH> have done with some additional info from Qdeck support.

It sounds like they will have to contact us directly to get support going for
our C++ compiler.  I am sure the C++
development team would be willing to help them get through
any snags they may have hit.


 TH> Also, I have heard that the C compiler 9.5 is supposed to be at rev
 TH> level "c". Is this for the genereal public (like me?).
 TH> If it is on the board as of the last few days I
 TH> haven't looked yet and I will download it if I find
 TH> it, but could only find rev level "a" stuff.
 TH> Thank you for your time.

Version 9.5 is currently at patch level 'a'.  The previous version (9.01) was
at level 'e'.


Kevin Kitsemetry
WATCOM TECHNICAL SUPPORT

*** This is a reply to #1938.  *** See also #1947.


From:    Dan Cummins                            Rec'd
To:      Jason Blochowiak                       Msg #1944, Nov-24-93 02:24PM
Subject: Locking for VM

 JB>  Ok, that makes sense - thanks. Actually, it make so
 JB> much sense, I'm embarassed I didn't think of it... :)

 JB>  Will that work for DS as well? Will it only work
 JB> before doing a malloc(), or does malloc() even mess
 JB> with DS's limit? Remember, I'm only interested in
 JB> locking down the predefined data.

 JB>  Thanks again,
 JB>   Jason

I asked our development team for more information regarding this problem.
Here's the response:
-------------------------------
Dan,

The code and data both start at offset 0 of their respective segments. (cs and
ds)

The end of initialized data can be found by looking at the _edata symbol.

The end of the code can be found by using the 'lsl' assembly instruction. Note
that the 'lsl' instruction is only available from protected mode. (i.e.
protected mode 286 or 386)

For example:

extern unsigned _get_cs_limit( void );
#ifdef __386__
#pragma aux _get_cs_limit = \
        "push   ebx"            /* save ebx */ \
        "xor    eax,eax"        /* clear eax */ \
        "mov    ax,cs"          /* get current code selector */ \
        "lsl    ebx,eax"        /* get segement limit */ \
        "mov    eax,ebx"        /* move segment limit to ax */ \
        "pop    ebx"            /* restore ebx */ \
        value [eax];
#else
#pragma aux _get_cs_limit = \
        "push   bx"             /* save bx */ \
        "mov    ax,cs"          /* get current code selector */ \
        "lsl    bx,ax"          /* get segement limit */ \
        "mov    ax,bx"          /* move segment limit to ax */ \
        "pop    bx"             /* restore bx */ \
        value [ax];
#endif

*** This is a reply to #1925.  *** See also #1957.


From:    Tim Anderson                           Rec'd
To:      Dan Cummins                            Msg #1946, Nov-26-93 03:22PM
Subject: problem 11298

When running under windows we are haveing a bunch of multiple instance
problems.

First, if there are two EXE's, but one has some 'changes' and we are trying to
run the old and new side by side - we only get multiple copies of the first
one that was executed. I'm doing the wsprintf(cClassName,
"Class%d",hInstance); stuff as per the doc's. This does NOT appear to be
enough to force multiple instances correctly. Also, when running one instance
plain and then starting the debugger up on the other WVIDEO gets confused. It
starts asking which <subroutine_name> that I want, and lists two references to
the exact same address. This leads me to beleive that multiple instances
really are sharing code (when they are not supposed to...).

Second, both applications call one single 16bit dll. All information is passed
by pointers into the DLL. It seems that repeated calls into the DLL with one
of the pointers starts using information out of the other pointers data area.
COLORREF values that are stored in the transfered pointer information start
referencing the palette that is set for the other instance of our application.
It's really quite strange...

Anyway, I want to be able to force multiple different instances, but it
doesn't work. Any suggestions?

*** See also #1955.


From:    Tom Hollins                            Rec'd
To:      Kevin Kitsemetry                       Msg #1947, Nov-24-93 10:38PM
Subject: Linking Watcom C libs into Watcom C++ progs

Hey Kevin,
The C vs C++ library linking problem I had was a programmer error. My link
list were ".c" instead of ".obj" that is why the "bad record" was being
reported. Your compiler works fine.
Thanks for your help.
If anyone is into DVX development the following changes need to be made to the
Watcom environment:
1) copy \dvx\xstub.exe \watcom\binb\wstub.exe
2) Create the following include file and include it BEFORE any of the X
libraries (header files).
/*
 * File: watincl.h
 * Purpose: Watcom's C++ implementation cannot support nested structures
 *   Therefore include this file BEFORE ALL X11 includes
 * NOTE: Use extern "C" {} on this file and the X11 files
 *   -T-
 *
 */

struct _XDisplay;
struct XKeytrans;
struct _XrmHashBucketRec;
struct _XSQEvent;

#define XTFUNCPROTO
3) All C libraries/header files must have extern "C" { (library files) }
around them otherwise the linker will fail (pretty standard stuff).
4) The C++ compiler is extremely picky so you will have to implement (void
*)calloc(...  on all of your callocs. Also pointer conversion is a no-no in
C++. void * is NOT a conversion type is is implemented as an actual type (the
previous void *calloc will work in the C compiler only).

Any additional problems should be posted maybe I could help I'm not as stupid
as the above mistake makes me out to be.

-T-

*** This is a reply to #1943

From:    Kevin Blenkinsopp
To:      Kevin K / Anthony Scian                Msg #1948, Nov-26-93 03:46PM
Subject: Prototyping hole

KK> Internal Report #11426


Guys, this snippet compiles without error under 9.5a. The Sun and some other
PC compiler rightly flag an error on the "???" line.

class JimHandle;

typedef void (*fn)(JimHandle *pJH, int nClient);

class JimHandle {
public:
        JimHandle();
        static fn mgpfn;
};

class FredHandle : public JimHandle {
public:
        FredHandle();
};

FredHandle::FredHandle() : JimHandle()
{
        mgpfn();         // ??? What about my args ???
}

The weird thing is that if you call it with "mgpfn(32)" it realises that it
can't convert 32 to a JimHandle, so why doesn't it realise that there are args
missing? Anyway, please look into it when you get a chance. PS, any idea when
the b-level is coming out? I really want that zero-sized array trick back!

Cheers,

Kevin

*** See also #1951.


From:    Kevin Kitsemetry                       Rec'd
To:      Kevin Blenkinsopp                      Msg #1951, Nov-26-93 04:06PM
Subject: Prototyping hole

KK> Internal Report #11426


 KB> Guys, this snippet compiles without error under 9.5a.
 KB> The Sun and some other PC compiler rightly flag an
 KB> error on the "???" line.

 KB> class JimHandle;

 KB> typedef void (*fn)(JimHandle *pJH, int nClient);

 KB> class JimHandle {
 KB> public:
 KB>         JimHandle();
 KB>         static fn mgpfn;
 KB> };

 KB> class FredHandle : public JimHandle {
 KB> public:
 KB>         FredHandle();
 KB> };

 KB> FredHandle::FredHandle() : JimHandle()
 KB> {
 KB>         mgpfn();         // ??? What about my args ???
 KB> }

 KB> The weird thing is that if you call it with
 KB> "mgpfn(32)" it realises that it can't convert 32 to a
 KB> JimHandle, so why doesn't it realise that there are
 KB> args missing? Anyway, please look into it when you get
 KB> a chance. PS, any idea when the b-level is coming out?
 KB> I really want that zero-sized array trick back!

 KB> Cheers,

 KB> Kevin

This problem has been fixed (as well has the one for the
zero sized array).  What you can do is give me a call
at 1-519-886-3700 and I will set you up with a pre
'b' level version of the compiler for you to try out (rather than waiting two
or three more weeks for the patches).


Kevin Kitsemetry
WATCOM TECHNICAL SUPPORT

*** This is a reply to #1948.


From:    Jim Ehrismann                          Rec'd
To:      Kevin Kitsemetry                       Msg #1952, Nov-26-93 04:03PM
Subject: Diamond Viper

I have a customer with a Diamond Viper card. When he runs our software
using your graphics library, it appears to be able to set the video mode
however "the image is scrunched, taking up the top 1/8 of the screen",
using his words. Do you know if your library supports this card?

                        Thanks,

                                Jim (Handle)

*** See also #1953.


From:    Kevin Kitsemetry                       Rec'd
To:      Jim Ehrismann                          Msg #1953, Nov-26-93 04:23PM
Subject: Diamond Viper

 JE> I have a customer with a Diamond Viper card. When he runs our software
 JE> using your graphics library, it appears to be able to set the video mode
 JE> however "the image is scrunched, taking up the top 1/8 of the screen",
 JE> using his words. Do you know if your library supports this card?

I am not sure if it does or not.  What you can do is have him run the
VGAINFO.C program available on this BBS (in the general file area). Also, we
will be adding support for VESA graphics cards in the B-level patches to the
compiler, so you will want to make sure that you get them when they come out!
(two to three weeks, hopefully).


Kevin Kitsemetry
WATCOM TECHNICAL SUPPORT

*** This is a reply to #1952.  *** See also #1954.


From:    Dan Cummins
To:      Tim Anderson                           Msg #1955, Nov-29-93 09:26AM
Subject: problem 11298

 TA> When running under windows we are haveing a bunch of
 TA> multiple instance problems.

 TA> First, if there are two EXE's, but one has some 'changes' and we are
 TA> trying to run the old and new side by side - we only
 TA> get multiple copies of the first one that was
 TA> executed. I'm doing the wsprintf(cClassName,
 TA> "Class%d",hInstance); stuff as per the doc's. This
 TA> does NOT appear to be enough to force multiple
 TA> instances correctly. Also, when running one instance
 TA> plain and then starting the debugger up on the other
 TA> WVIDEO gets confused. It starts asking which
 TA> <subroutine_name> that I want, and lists two
 TA> references to the exact same address. This leads me to
 TA> beleive that multiple instances really are sharing
 TA> code (when they are not supposed to...).

 TA> Second, both applications call one single 16bit dll. All information is
 TA> passed by pointers into the DLL. It seems that
 TA> repeated calls into the DLL with one of the pointers
 TA> starts using information out of the other pointers
 TA> data area. COLORREF values that are stored in the
 TA> transfered pointer information start referencing the
 TA> palette that is set for the other instance of our
 TA> application. It's really quite strange...

 TA> Anyway, I want to be able to force multiple different
 TA> instances, but it doesn't work. Any suggestions?

Tim,

I checked with our development team for any tips, as you asked. It looks like
we will need an example to investigate the problem.

Dan Cummins
WATCOM Languages Support

*** This is a reply to #1946.


From:    Roman Lewkow                           Rec'd
To:      Dan Cummins                            Msg #1957, Nov-29-93 03:25PM
Subject: Finding adresses & stuff

Dan, for some reason you seem to reply to these messages about VM
locking,address finding and stuff. I wonder if you could advise me if and how
I can find a physical address associated with a pointer ( malloc-ed ) under
4GW. My app needs to progran
program ( damn this editor ) a DMA controller with a bunch of starting
addresses for lines in my frame buffer ( some 40 to 50 MB, roughly 4500 lines,
12k each ). One solution would be to hardwire DMA ctrlr to make it blast all
data somewhere high and then man "somewhere high" into linear selector via
DPMI 800h. But this is ugly and hardly portable. PharLap API has function
DosGetPhysAddr which does just that, yet I was told before ( by
Watcom/Rational team ) this is not possible under DPMI. I have a feeling you
might know otherwise, if so please let me know ASAP since I have PO ready for
signing next week to purchase PharLap TNT. I would rather stay with 4GW than
change to PHAPI calls.

thanks, Roman

*** This is a reply to #1944.  *** See also #1964.


From:    Paul Tletski                           Rec'd
To:      Kevin Kitsemetry                       Msg #1958, Nov-30-93 12:34PM
Subject: bimodal interrupt & linking

Kevin,

I'm having trouble getting an executable which has a bimodal interrupt to run.
The program I am running is similar to that which is in the
_Commonly_Asked_Questions_and_Answers_ book with one exception.  Rather than
copying down the interrupt handler into a DOS memory block I am attempting to
run in place.  I am using the Phar Lap 386asm assembler.

The error that I am getting occurs at runtime.  The following messages are
displayed.

"LINEXE: Unhandled alias16 reference to unaliased object"
"DOS/4GW Fatal Error: Loader Failed.  Unable to resolve external refernces"

My link is clean, i.e., no warnings or errors.  Any idea what is up?

Thanks,

Paul Tletski
Allen-Bradley Co. Inc.
Highland Hts., OH

*** See also #1959.


From:    Kevin Kitsemetry                       Rec'd
To:      Paul Tletski                           Msg #1959, Nov-30-93 03:29PM
Subject: bimodal interrupt & linking

 PT> Kevin,

 PT> The error that I am getting occurs at runtime.  The
 PT> following messages are displayed.

 PT> "LINEXE: Unhandled alias16 reference to unaliased object"
 PT> "DOS/4GW Fatal Error: Loader Failed.  Unable to
 PT> resolve external refernces"

There was a reported problem with the latest version (1.92) of DOS/4GW that
caused this error message to appear.  This will be fixed in the next version
of the DOS extender.  You can also use the previous version in the meantime
(1.9).  Finally,
one other person observed that the problem went away if he
changed one of his MASM options from /ZI to /ZD.


Kevin Kitsemetry
WATCOM TECHNICAL SUPPORT

*** This is a reply to #1958.


From:    Kevin Blenkinsopp                      Rec'd
To:      Kevin Kitsemetry                       Msg #1960, Nov-30-93 03:51PM
Subject: Real mode stuff

Kevin,

Couple of quick questions:

1) This explodes. Any ideas why?

#include <Dos.H>
#include <IOStream.H>

#include "Defs.H"

Void main(Count cArg, Strz azArg[])
{
   union REGS regs;
   struct SREGS sregs;

   regs.w.ax = 0x7A00;
   int386x(0x2F, ®s, ®s, &sregs);

   if (regs.h.al == 0xFF) {
      cout << "IPX installed\n";
   } else cout << "IPX not installed\n";
}


2) This call returns the address of a real-mode function is ES:BP. How can I
call it?

Thanks,

Kevin

*** See also #1961.


From:    Kevin Kitsemetry                       Rec'd
To:      Kevin Blenkinsopp                      Msg #1961, Nov-30-93 04:01PM
Subject: Real mode stuff

 KB> Kevin,

 KB> Couple of quick questions:

 KB> 1) This explodes. Any ideas why?

 KB> #include <Dos.H>
 KB> #include <IOStream.H>

 KB> #include "Defs.H"

 KB> Void main(Count cArg, Strz azArg[])
 KB> {
 KB>    union REGS regs;
 KB>    struct SREGS sregs;

 KB>    regs.w.ax = 0x7A00;
 KB>    int386x(0x2F, ®s, ®s, &sregs);

 KB>    if (regs.h.al == 0xFF) {
 KB>       cout << "IPX installed\n";
 KB>    } else cout << "IPX not installed\n";
 KB> }

Try using DPMI function 300h to issue the real mode interrupt. There is an
example of using this function on the BBS called RINTCALL.C in one of the file
areas.


 KB> 2) This call returns the address of a real-mode
 KB> function is ES:BP. How can I call it?

Same as above.


Kevin Kitsemetry
WATCOM TECHNICAL SUPPORT

*** This is a reply to #1960.


From:    Dan Teven                              Rec'd
To:      Kevin Kitsemetry                       Msg #1962, Nov-30-93 03:55PM
Subject: realloc() under DOS4G Professional

Another customer asked me about your reply to Skip Fedanzo's message,
so I thought I would clarify.  The bug we've documented is that
when you realloc() a block of memory, and grab more memory from the
operating system (us), you don't return the previously used memory to
the operating system.  No DOS extender is going to be able to combine
small chunks of memory into large chunks if the blocks are in use,
which they are in this case (your heap manager still owns them, though
the application program isn't using them any longer).

Fragmentation is going to happen with any run-time library heap
manager under some conditions; one can always invent a pattern of
allocations and frees that causes gaps in the free list, and causes
large allocations of contiguous memory to fail even if there's enough
total memory available to satisfy the allocation request.  The
particular case I've discussed before shows up when you use realloc()
to grow a large block (or blocks) repeatedly.  If you don't use
realloc(), it won't bite you.  There may be other situations under
which fragmentation will occur, but there's nothing the DOS extender
can do to solve those situations, either.  Fragmentation of the
memory managed by the run-time library is most probably caused
by unusual allocate/free patterns in the application program, and
the best way to avoid it is for the application programmer to
be aware of the possibility...

Dan

*** This is a reply to #1864.  *** See also #1968.


From:    Robert Baker
To:      Watcom Tech Support                    Msg #1963, Nov-30-93 04:33PM
Subject: fread() in C32 for DOS

I have a large application that we compile using C32 for DOS to get a DOS
Extended version and also with MS C/C++ 7.00 to get a real mode version.  We
have a problem with reading (using fread) data from a file in that the fread
returns correctly but does not read the correct data.  It works fine under MS.
 I saw msg 1671 about reading across the 0x1000 boundary and checked our data.
 The point in the file we are reading is at 4118 and we are trying to read 9
bytes (ie - fread (buf, 9, 1, fp)).  Our C32 system is patched to level A.  My
customers are not happy, so any help would be greatly appreciated...

*** See also #1966.


From:    Dan Cummins                            Rec'd
To:      Roman Lewkow                           Msg #1964, Nov-30-93 05:28PM
Subject: Finding adresses & stuff

 RL> Dan, for some reason you seem to reply to these
 RL> messages about VM locking,address finding and stuff. I
 RL> wonder if you could advise me if and how I can find a
 RL> physical address associated with a pointer ( malloc-ed
 RL> ) under 4GW. My app needs to progran
 RL> program ( damn this editor ) a DMA controller with a bunch of starting
 RL> addresses for lines in my frame buffer ( some 40 to 50
 RL> MB, roughly 4500 lines, 12k each ). One solution would
 RL> be to hardwire DMA ctrlr to make it blast all data
 RL> somewhere high and then man "somewhere high" into
 RL> linear selector via DPMI 800h. But this is ugly and
 RL> hardly portable. PharLap API has function
 RL> DosGetPhysAddr which does just that, yet I was told
 RL> before ( by Watcom/Rational team ) this is not
 RL> possible under DPMI. I have a feeling you might know
 RL> otherwise, if so please let me know ASAP since I have
 RL> PO ready for signing next week to purchase PharLap
 RL> TNT. I would rather stay with 4GW than change to PHAPI
 RL> calls.
 RL>
 RL> thanks, Roman

It's true that under DPMI you can't ask for physical addresses from linear
ones because of the paging mechanism.

I believe DPMI 800h is the way to go.  There is an example
of using such calls on this BBS.  It's called ACCMEM.C and
it's under the WATCOM C file area.  The numbers in this
example are bogus, but you'll have to change them anyway
for your application.  The example just serves as a skeleton.

I looked up Phar Lap's "Convert Linear Address to Physical Address" function,
which is called _dx_tophys() in my manual.  As expected,it always returns an
error code if called while running under DPMI.

Dan Cummins
WATCOM Languages Support

*** This is a reply to #1957.


From:    Jason Blochowiak                       Rec'd
To:      Dan Cummins                            Msg #1965, Dec-01-93 09:53AM
Subject: Locking for VM

 I appreciate the response. I tried getting/decoding the selector data, and
(for C/C++ v9.5a under DOS/4GW 1.92) the base was 0, and the limit was
something very large (~4Gb, if memory serves). In retrospect, this makes
sense, given the context of the "flat" memory model. What I ended up doing to
get some values that I could use was poking through the asm startup code, and
finding the "special" symbols that denote the boundaries of the various
regions (code/initialized data/bss). I used their addresses for the locking
functions, and everything seemed to work fine - I ran my test app in a DOS box
under Windows 3.1 with VM enabled, and it no longer croaks.

 So, unless I'm doing something heinously wrong (always a possibility :), it
looks like this problem is no more. Thanks again for your help,

 Jason

*** This is a reply to #1944.


From:    Kevin Blenkinsopp                      Rec'd
To:      Robert Baker                           Msg #1966, Dec-01-93 01:59PM
Subject: fread() in C32 for DOS

I had the same problem. I went for a brute force solution and used open and
read instead of fopen and fread, which worked fine. There wasn't any
noticeable performance hit.

*** This is a reply to #1963.


From:    Kevin Blenkinsopp                      Rec'd
To:      Kevin Kitsemetry                       Msg #1967, Dec-02-93 09:34AM
Subject: More real mode stuff

KK> Internal Report #11809


Thanks for the help. I still have a problem with part two though...

extern Word InitSPX(Void (*func)(Void));
#pragma aux InitSPX = \
        "push   bp"             \
        "mov    ebx, 0x10"      \
        "call   eax"            \
        "pop    bp"             \
        parm [eax] modify [ebx ecx edx];

Void main(Count cArg, Strz azArg[])
{
        .
        .
        .

        // use DMPI to issue the DOS interrupt
        regs.w.ax = 0x0300;
        regs.h.bl = 0x2F;
        regs.h.bh = 0;
        regs.w.cx = 0;
        sregs.es = FP_SEG(&rmi);
        regs.x.edi = FP_OFF(&rmi);
        int386x(0x31, ®s, ®s, &sregs);
        // this now returns nicely and gives the right results
        // the next thing to do is initialise the SPX driver by
        // setting bx to 16 and calling the real-mode function
        // that was just returned in es:di
        // This is the bit I still have a problem with

        typedef Void (*PFN)(Void);
        if ((rmi.eax & 0xFF) == 0xFF) {
         PFN pfn = (PFN)MK_FP(rmi.es, (rmi.edi & 0xFFFF));
         cout << "IPX installed - Call address is " << pfn << endl;
         // nuclear holocaust now ensues...
         cout << "SPX Init returned " << InitSPX(pfn) << endl;
        } else cout << "IPX not installed\n";
}

Because the IPX/SPX calling mechanism is so obnoxious, I'm guessing that I
have to use a code burst like the one above. I've got that "out of my depth"
feeling here, so I'm going to ask you to bail me out again! I've been coming
down with something over the last couple of days, so I may not be thinking too
clearly right now. I'll be out for the rest of the week, so I don't need an
answer on this immediately.

Thanks,

Kevin

*** See also #1994.


From:    Kevin Kitsemetry                       Rec'd
To:      Dan Teven                              Msg #1968, Dec-01-93 06:12PM
Subject: realloc() under DOS4G Professional

 DT> to grow a large block (or blocks) repeatedly.  If you don't use
 DT> realloc(), it won't bite you.  There may be other situations under
 DT> which fragmentation will occur, but there's nothing the DOS extender
 DT> can do to solve those situations, either.  Fragmentation of the

This sounds logical to me.  I understand that the problem has been rectified
for the next level of patches anyway.  But I still don't understand why other
extenders (such as Pharlap) don't encounter this problem?

Kevin

*** This is a reply to #1962.  *** See also #1969.


From:    Dan Teven                              Rec'd
To:      Kevin Kitsemetry                       Msg #1969, Dec-01-93 08:32PM
Subject: realloc() under DOS4G Professional

I believe it's because your library support for those extenders
uses a different interface, not int 31h calls.  The problem is
in the way those int 31h calls are used (actually, not used),
not how the extender responds to the int 31h calls.

Dan

*** This is a reply to #1968.


From:    Dan Cummins
To:      Donald Tevault                         Msg #1970, Dec-02-93 12:43PM
Subject: WMAKE

DC> Internal Report #10428

 DT> # Hi Kevin!
 DT> #       I made the makefile for the Calendar.cpp file as you said, and
 DT> it # does invoke the C++ compiler without any problem.
 DT>  I then tried playing around # some more with this
 DT> zipcode.mak file, but no matter what I tried, I still
 DT> got # the same results.  That is, it just dumps me out
 DT> to DOS without invoking the # C++ compiler.  It's not
 DT> that it can't find the compiler,because even when I #
 DT> move the compiler to the same directory as this
 DT> makefile, it still does the # same thing.  If you can
 DT> figure out a way to make it work, I will be very #
 DT> grateful.
 DT> #        Many thanks in advance.
 DT> #                Donald Tevault
 DT> #
 DT> #
 DT> #
 DT> #       MakeFile Frame For Watcom C++ or better
 DT> # ~1 = APPNAME, ~2 = APPNAMEdlg, ~3 =  APPNAMEm,
 DT> # ~4 = APPNAMEdb, ~5 = APPNAMEini
 DT> # ~6 = Include Directory, ~7 = Library Directory
 DT> # ~8 = Source Directory
 DT> .EXTENSIONS: .CPP
 DT> SD = C:\DB4W\SOURCE\\

 DT> FILES = charf.obj pictures.obj ZIPCODDD.obj ZIPCODMM.obj\
 DT> dllutil.obj stdfile.obj database.obj toolbar.obj
 DT> specscrl.obj\ stdquery.obj linkman.obj memof.obj
 DT> combo.obj dialogs.obj\
 DT> table.obj query.obj stdidx.obj lexer.obj parser.obj
 DT> symbol.obj\ decor.obj static.obj keyfilt.obj
 DT> checkbox.obj btree.obj file.obj



 DT> INCLUDEDIR = C:\DB4W\SOURCE
 DT> LIBDIR   = C:\WATCOM\LIB386;C:\WATCOM\LIB386\WIN\\

 DT> COM = WIN386 1
 DT> CC = wpp386

 DT> # Most Compiler-Specific Items are in the following 7 lines # Almost any
 DT> Windows C++ compiler that uses a MAKEFILE can be #
 DT> supported here # COMPILER = LINKER   = wlink
 DT> RC        = wrc
 DT> RFLAGS   = /r /i=$(SOURCEDIR)
 DT> #CFLAGS  = /c /GW
 DT> CPPFLAGS = -zW -oaxt -d1 -d -w4 -fpc -i=$(INCLUDEDIR)
 DT> LFLAGS   = /Lw
 DT> LFILES   = ZIPCODE.def

 DT> .cpp.obj:
 DT>        $(CC) $[*.cpp $(CPPFLAGS)

 DT> #.c.obj:
 DT> #       $(COMPILER) $(CFLAGS) $^.

 DT> ZIPCODE.res: ZIPCODE.rc
 DT>         $(RC) $(RFLAGS) ZIPCODE.rc

 DT> ZIPCODE.EXE: ZIPCODE.obj $(FILES) ZIPCODE.rc  ZIPCODE.def
 DT>         $(LINKER) $(LFLAGS) $(FILES) $(LFILES)
 DT>         wbind ZIPCODE -R -31 ZIPCODE.res
 DT> #       rc -t -K ~1

 DT> #       Dependencies
 DT> CHARF =         $(SD)charf.hpp
 DT> DATABASE =      $(SD)database.hpp
 DT> PICTURES =      $(SD)pictures.hpp
 DT> GLOBAL =        $(SD)global.hpp
 DT> DLLUTIL =       $(SD)dllutil.hpp
 DT> FRAME =         $(SD)frame.hpp
 DT> STATBAR =       $(SD)statbar.hpp
 DT> MEMOF =         $(SD)memof.hpp
 DT> COMBO =         $(SD)combo.hpp
 DT> TOOLBAR =       $(SD)toolbar.hpp
 DT> SPECSCRL =      $(SD)specscrl.hpp
 DT> GENERIC =       $(SD)generic.hpp
 DT> STDQUERY =      $(SD)stdquery.hpp
 DT> DIALOGS =       $(SD)dialogs.hpp
 DT> LINKMAN =       $(SD)linkman.hpp
 DT> QUERY =         $(SD)query.hpp
 DT> TABLE =         $(SD)table.hpp
 DT> STDIDX =        $(SD)stdidx.hpp
 DT> STDFILE =       $(SD)stdfile.hpp
 DT> LEXER =  $(SD)lexer.hpp
 DT> PARSER =         $(SD)parser.hpp
 DT> SYMBOL =         $(SD)symbol.hpp
 DT> DECOR =  $(SD)decor.hpp
 DT> STATIC =         $(SD)static.hpp
 DT> KEYFILT =       $(SD)keyfilt.hpp
 DT> CHECKBOX =      $(SD)checkbox.hpp
 DT> BTREE    =      $(SD)btree.hpp
 DT> FILE     =      $(SD)file.hpp

 DT> stdidx.obj      : $(SD)stdidx.cpp $(STDIDX)
 DT> charf.obj       : $(SD)charf.cpp  $(CHARF) $(DLLUTIL)
 DT> $(DATABASE) pictures.obj : $(SD)pictures.cpp
 DT> $(PICTURES)
 DT> ZIPCODE.obj      : ZIPCODE.cpp $(STDFILE) $(GLOBAL)
 DT> $(FRAME) $(DATABASE) $(STATBAR)\
 DT>                  $(TOOLBAR) $(SPECSCRL) $(CHARF) $(NUMF) $(COMBO)
 DT> $(MEMOF) $(DLLUTIL) ZIPCODE.cpp ZIPCODE.res      :
 DT> ZIPCODE.rc ZIPCODE.h ZIPCODE.stb ZIPCODDD.obj     :
 DT> ZIPCODDD.cpp $(GENERIC) $(CHARF) $(DATABASE)
 DT> ZIPCODE.cpp ZIPCODMM.obj     : ZIPCODMM.cpp $(FRAME)
 DT> $(STDFILE) $(GLOBAL) $(DATABASE) $(STATBAR)\
 DT>                  $(TOOLBAR) ZIPCODDD.hpp ZIPCODE.h
 DT> $(GENERIC) $(DIALOGS) dllutil.obj     :
 DT> $(SD)dllutil.cpp $(DLLUTIL)
 DT> stdfile.obj     : $(SD)stdfile.cpp $(DLLUTIL)
 DT> $(STDQUERY) $(STDFILE) $(MKTREE)\
 DT>         $(PICTURES)
 DT> database.obj : $(SD)database.cpp $(DATABASE) $(GLOBAL)
 DT> $(GENERIC) $(FRAME)\
 DT>         $(STATBAR) $(CHARF) $(DLLUTIL) $(SPECSCRL)
 DT> $(DIALOGS) toolbar.obj : $(SD)toolbar.cpp $(TOOLBAR)
 DT> $(DATABASE)
 DT> statbar.obj     : $(SD)statbar.cpp $(STATBAR)
 DT> specscrl.obj : $(SD)specscrl.cpp $(SPECSCRL)
 DT> stdquery.obj : $(SD)stdquery.cpp $(STDQUERY) $(DLLUTIL)
 DT> linkman.obj     : $(SD)linkman.cpp $(LINKMAN)
 DT> $(GLOBAL) $(PICTURES) memof.obj
 DT>       : $(SD)memof.cpp $(MEMOF) $(DLLUTIL) $(DATABASE) combo.obj       :
 DT> $(SD)combo.cpp $(COMBO) $(DLLUTIL) $(DATABASE)
 DT> dialogs.obj     : $(SD)dialogs.cpp $(DIALOGS)
 DT> $(STDFILE) $(GLOBAL) $(GENERIC) table.obj       :
 DT> $(SD)table.cpp $(TABLE)
 DT> query.obj       : $(SD)query.cpp $(QUERY)
 DT> lexer.obj       : $(SD)lexer.cpp $(LEXER)
 DT> parser.obj      : $(SD)parser.cpp $(PARSER)
 DT> symbol.obj      : $(SD)symbol.cpp $(SYMBOL)
 DT> decor.obj       : $(SD)decor.cpp $(DECOR)
 DT> static.obj      : $(SD)static.cpp $(STATIC)
 DT> keyfilt.obj      : $(SD)keyfilt.cpp $(KEYFILT)
 DT> checkbox.obj : $(SD)checkbox.cpp $(CHECKBOX)
 DT> btree.obj       : $(SD)btree.cpp $(BTREE)
 DT> file.obj         : $(SD)file.cpp $(FILE)

At first I thought when you said 'dumped out to DOS' you
meant that WMAKE was somehow not being invoked or crashing
somehow.  A member of our development team pointed out that in your makefile,
the first target defined.

If you invoke wmake without specifying a target, it will
default to the first target.  Hence in your case if ZIPCODE.RES is up to date,
then make has nothing to do.

You should put ZIPCODE.EXE as the first target, and have it depend on
ZIPCODE.RES (in your file it depends on ZIPCODE.RC).  The ZIPCODE.RES rule
should appear after this.

Dan Cummins
WATCOM Languages Support

P.S. To make a specific target, you can use 'wmake <targetname>' on the
command line.


*** This is a reply to #1886.


From:    Jim Ehrismann                          Rec'd
To:      Kevin Kitsemetry                       Msg #1971, Dec-02-93 10:04AM
Subject: Diamond Viper

 KK> I am not sure if it does or not.  What you can do is
 KK> have him run the VGAINFO.C program available on this
 KK> BBS (in the general file area). Also, we will be adding
 KK> support for VESA graphics cards in the B-level patches
 KK> to the compiler, so you will want to make sure that you
 KK> get them when they come out! (two to three weeks,
 KK> hopefully).

VGAINFO recognized the Viper card as an S3. Setting the video
modes was not the problem, putting images was. I will wait for the
VESA support and try again then. Thanks.

                Jim Ehrismann

*** This is a reply to #1953.  *** See also #1982.


From:    Jerry Rice                             Rec'd
To:      Jim Ehrismann                          Msg #1972, Dec-05-93 04:44AM
Subject: Diamond Viper

JE> KK> I am not sure if it does or not.  What you can do is
JE> KK> have him run the VGAINFO.C program available on this
JE> KK> BBS (in the general file area). Also, we will be adding
JE> KK> support for VESA graphics cards in the B-level patches
JE> KK> to the compiler, so you will want to make sure that you
JE> KK> get them when they come out! (two to three weeks,
JE> KK> hopefully).

JE>VGAINFO recognized the Viper card as an S3. Setting the video
JE>modes was not the problem, putting images was. I will wait for the
JE>VESA support and try again then. Thanks.

JE>                Jim Ehrismann


      First, I don't  think the viper is an  S3. The Stealth
cards  are S3's.  I think  it's a  Weitech. Why its "saying"
that  it  is  an  S3,  I  don't  know. Memory structuring is
definitely different. Second, if it  is an S3 it has changed
considerably since  the Stealth versions  which had 1Meg  of
memory.  (The  S3  driver  from  Watcom  works well with the
Stealth  cards  using  the  S3  chipset)  What  you formerly
described is the classical  paging problem. What your client
is actually  displaying on is  the first 64k  chunk of video
memory.  Knowing  where  and  how  to  set  the  page select
register  is  where  the  difficulty  is.  Its  not  able to
select(activate) the proper page  number for continued video
display. That it  is scrunched and only 1/8th  of the screen
indicates this.  Only every 8th line  is being displayed and
in the wrong place, at  that. Its writing to A000:0000 every
8th line, which  will work with most cards,  but when it has
to  change to  the next  page to  continue, the  page select
register is not being set correctly. Sort of like this: line
one of the display,is on page  one; Line 2 of the display is
on page 2,  etc. So every 8th line will  be on page one, and
that's  all that's  being activated.  VESA should  work, but
realize that  it will be  slower. I have  an S3 Stealth  and
Watcom drivers  are 3-4 times faster  with their direct mode
than  the  equivalent  VESA  drivers,  even  though the VESA
support is  on ROM! It has  to go through a  second layer of
instructions  every time  it  writes.  Because the  Viper is
probably the  most popular 'fastest'  card on the  market, I
hope that  Watcom will support  it in direct  mode. But they
will have to get one first  and 'play' with it. Many Many of
the VL Bus video systems are  being sent with the Viper card
as standard. For instance, Zeos and Gateway.


                                    Jer
___
 X SLMR 2.1a X

*** See also #2005.


From:    Jerry Rice                             Rec'd
To:      Kevin Kitsemetry                       Msg #1973, Dec-05-93 04:44AM
Subject: Diamond Viper

JE> KK> I am not sure if it does or not.  What you can do is
JE> KK> have him run the VGAINFO.C program available on this
JE> KK> BBS (in the general file area). Also, we will be adding
JE> KK> support for VESA graphics cards in the B-level patches
JE> KK> to the compiler, so you will want to make sure that you
JE> KK> get them when they come out! (two to three weeks,
JE> KK> hopefully).

JE>VGAINFO recognized the Viper card as an S3. Setting the video
JE>modes was not the problem, putting images was. I will wait for the
JE>VESA support and try again then. Thanks.

JE>                Jim Ehrismann


      First, I don't  think the viper is an  S3. The Stealth
cards  are S3's.  I think  it's a  Weitech. Why its "saying"
that  it  is  an  S3,  I  don't  know. Memory structuring is
definitely different. Second, if it  is an S3 it has changed
considerably since  the Stealth versions  which had 1Meg  of
memory.  (The  S3  driver  from  Watcom  works well with the
Stealth  cards  using  the  S3  chipset)  What  you formerly
described is the classical  paging problem. What your client
is actually  displaying on is  the first 64k  chunk of video
memory.  Knowing  where  and  how  to  set  the  page select
register  is  where  the  difficulty  is.  Its  not  able to
select(activate) the proper page  number for continued video
display. That it  is scrunched and only 1/8th  of the screen
indicates this.  Only every 8th line  is being displayed and
in the wrong place, at  that. Its writing to A000:0000 every
8th line, which  will work with most cards,  but when it has
to  change to  the next  page to  continue, the  page select
register is not being set correctly. Sort of like this: line
one of the display,is on page  one; Line 2 of the display is
on page 2,  etc. So every 8th line will  be on page one, and
that's  all that's  being activated.  VESA should  work, but
realize that  it will be  slower. I have  an S3 Stealth  and
Watcom drivers  are 3-4 times faster  with their direct mode
than  the  equivalent  VESA  drivers,  even  though the VESA
support is  on ROM! It has  to go through a  second layer of
instructions  every time  it  writes.  Because the  Viper is
probably the  most popular 'fastest'  card on the  market, I
hope that  Watcom will support  it in direct  mode. But they
will have to get one first  and 'play' with it. Many Many of
the VL Bus video systems are  being sent with the Viper card
as standard. For instance, Zeos and Gateway.


                                    Jer
___
 X SLMR 2.1a X

*** See also #1978.


From:    John Hamilton
To:      Tech Support                           Msg #1974, Dec-05-93 07:08PM
Subject: Freeing memory under DOS/4GW

Is it necessary to free allocated memory when exiting a program
written using DOS/4GW?  It appears that the memory I've allocated
is already being given back.

*** See also #1979.


From:    Mike Brennen
To:      Tech Support                           Msg #1976, Dec-06-93 09:31AM
Subject: C++32 B level patches

In response to 1909, when will B level patches be available?  I don't see them
in the file areas.   Thanks...

*** See also #1980.


From:    Kevin Kitsemetry                       Rec'd
To:      Jerry Rice                             Msg #1978, Dec-06-93 10:21AM
Subject: Diamond Viper

Thanks for the information, I will pass it on to the developer in charge of
the graphics library right away.


Kevin Kitsemetry
WATCOM TECHNICAL SUPPORT

*** This is a reply to #1973.  *** See also #1990.


From:    Kevin Kitsemetry                       Rec'd
To:      John Hamilton                          Msg #1979, Dec-06-93 10:26AM
Subject: Freeing memory under DOS/4GW

 JH> Is it necessary to free allocated memory when exiting a program
 JH> written using DOS/4GW?  It appears that the memory I've allocated
 JH> is already being given back.

It is not necessary, but it is always a good programming practice!


Kevin Kitsemetry
WATCOM TECHNICAL SUPPORT

*** This is a reply to #1974.


From:    Kevin Kitsemetry                       Rec'd
To:      Mike Brennen                           Msg #1980, Dec-06-93 10:28AM
Subject: C++32 B level patches

 MB> In response to 1909, when will B level patches be
 MB> available?  I don't see them in the file areas.

Although there is no set date, we hope to have them
released in about two weeks.


Kevin Kitsemetry
WATCOM TECHNICAL SUPPORT

*** This is a reply to #1976.  *** See also #2030.


From:    Christer Palm                          Rec'd
To:      Dan Cummins                            Msg #1981, Dec-06-93 12:15PM
Subject: WVIDEO and A level patch

 DC> I haven't heard of this problem.  It sounds like we would
 DC> need an example from you to reproduce it here.

Actually, no example is needed. I discovered later that the problem wasn't
related to AutoCAD or the program I debug, it's always there.
As I said before, it looks like WVIDEO is redefining the MDA character set or
something, horizontal lines all over the screen and reverse video.
NOTE that everything looks great until the source code pops into the window..

As I also said before, I have two different systems setup here, with different
brands of MDAs, and the problems are exactly the same on both systems.

I just tried to rename config.sys and autoexec.bat to be absolutely certain
that nothing there caused the trouble, but the problem remained. I also ran
WVIDEO 9.01e (Which I also had installed), it ran just fine, but i KNOW that
9.5 didn't behave like that before I applied the A-level patches.

/ Christer

*** This is a reply to #1941.  *** See also #1996.


From:    Christer Palm                          Rec'd
To:      Jim Ehrismann                          Msg #1982, Dec-06-93 12:37PM
Subject: Diamond Viper

I have encountered that problem on S3 adapters using AMIs BIOS with other
drivers. For me the problem occured when switching from HI-RES (1024x768+) to
text and then to 640x480 (i.e shelling out of Windows to run a DOS graphics
app). It seems like the BIOS doesn't reset some registers properly, this can
be fixed in software however. I suggest you guys at Watcom check this out with
S3 for a workaround on this.

 / Christer

*** This is a reply to #1971.


From:    Kevin Kitsemetry                       Rec'd
To:      Mike Brennen                           Msg #1983, Dec-06-93 02:43PM
Subject: C++32 B level patches

 MB> In response to 1909, when will B level patches be
 MB> available?  I don't see them in the file areas.

At least two more weeks.  Keep an eye on the Bulletins
when you login for the announcement.


Kevin Kitsemetry
WATCOM TECHNICAL SUPPORT

*** This is a reply to #1976.


From:    Nicos Skouras                          Rec'd
To:      Kevin Kitsemetry                       Msg #1984, Dec-08-93 11:27AM
Subject: W9.5a function problem

KK> Internal Report #12307


Please reference file STRERR.ZIP uploaded in the file area
with str.c & the result of it.
In short: the strtol () function does not recognize a hex
valua as signrd but treats it as unsigned.
Thanks
Nicos Skouras

*** See also #2032.


From:    Joseph Schachner
To:      Kevin Kisemetry                        Msg #1985, Dec-08-93 11:44AM
Subject: Locking for VM

KK> Internal Report #12313


I've followed the "Locking for VM" discussion with interest - locking the
entire code and static data segment is exactly what I want to do, to.

So I wrote a little test program to see if I could figure out what to lock.
The program did the following:
1) called segread and printed out sregs.cs and sregs.ds
2) Did DPMI function 6 to get the base address for cs and ds 3) Printed out
the address of an initialized array and an uninit'd
   variable, just by doing (for example) printf("inited is at %08X\n",
   inited );
4) Printed out &_edata and &_end (symbols assigned in the startup file). 5)
Did DPMI function 0x0B to get the LDT entry for sregs.cs and sregs.ds.
   Printed out the seglimit field.
Note: I checked regs.x.cflag after each DPMI call, there were no errors.

The results were:
1) cs was 0227 and ds was 022F, on every run.  Looks OK to me. 2) base address
reported was 0 for both cs and ds, on every run. OK. 3) "inited is at
80A9D160" and "uninit is at 80A9D4B0"
    (Over 2G?  must be something I don't understand about these values.) 4)
"_edata is at 80A9D4B0" and "_end is at 80A9D4D4"
5) "cs seglimit (in bytes) is 64256" and "ds seglimit (in bytes) is 62208"
    This doesn't look OK: cs seglimit > ds seglimit???  Also, I expected
    the G bit to be set (4K pages), but it wasn't.

I added a declaration of an array of 8192 ints, and the address of uninit and
the address of _end went up by 32768.  Perfect.  But, cs and ds's seglimits
did not change.

I then added a little extra code.  As I expected, the addresses of
inited,uninit, _edata and _end all went up by a a few dozen bytes.  However,cs
and ds seglimits were still unchanged.

Could someone explain to me what the value that got printed for &_end means?
Remember, the goal is to lock all of cs and ds.  We know they start at 0,but
they sure don't end at above 2G.  How I get from this value to a linear
address, so I can call the DPMI function to lock memory?

Also, here's the piece of C code from my program which gets ds's LDT and
prints its seglimit.  I welcome any corrections and comments. Note: ldtbuff is
declared unsigned int ldtbuff[2].  seglimit is unsigned.

    ldtbuff[0] = 0;           /* make sure value is due to assignment */
    ldtbuff[1] = 0;
    regs.w.ax = 0x0B;         /* DPMI function 0Bh: get LDT */
    regs.w.bx = sregs.ds;
    sregs.es = FP_SEG(&ldtbuff);
    regs.x.edi = FP_OFF(&ldtbuff);
    int386x( 0x31, ®s, ®s, &sregs );
    if (regs.x.cflag)
        printf("*** Get ldt failed!\n");
    seglimit = ldtbuff[0] & 0xF0000;
    seglimit += ldtbuff[1] & 0xFFFF;
    if (ldtbuff[0] & 0x800000)
    {
        printf(" Seglimit was in pages!\n");
        seglimit *= 4096;
    }
    printf("ds seglimit (in bytes) is %d\n", seglimit );

Thank you, WATCOM tech support, for any response.
Joe Schachner, LeCroy Corp, voice [phone] x2282.  FAX [phone].

*** See also #2029.


From:    Chris Boogmans                         Rec'd
To:      Kevin Kitsemetry                       Msg #1986, Dec-07-93 03:45AM
Subject: Warning problem in C32/9.5a

// Kevin, the WatCom C32 compiler version 9.5a is mistaken with regard to
// it's 'Warning! W200' messages on the code below.  It issues this warning
// on the call of WatComFunc2(), which is correct, but it issues the same
// warning on the call of MscFunc2(), i.s.o. on the call of MscFunc1().
// Since the MscFuncs are declared 'cdecl', arguments are stacked in the
// order right to left.
// It is no big deal ofcourse, but it's best if a compiler only issues
// warnings when there are any.  Regards, Chris.

#include <stdio.h>
#include <stdlib.h>

unsigned AssignValueTo(void *Variable);

// following 2 functions will be assumed to use WatCom calling convention :
void WatComFunc1(unsigned, void (*)(void));
void WatComFunc2(void (*)(void), unsigned);

// and these 2 will be assumed to use MSC calling convention :
void cdecl MscFunc1(unsigned, void (*)(void));
void cdecl MscFunc2(void (*)(void), unsigned);

void main(void)
{
        void (*Function1)(void);
        void (*Function2)(void);
        void (*Function3)(void);
        void (*Function4)(void);

        WatComFunc1(AssignValueTo(&Function1), Function1);
        WatComFunc2(Function2, AssignValueTo(&Function2));

        MscFunc1(AssignValueTo(&Function3), Function3);
        MscFunc2(Function4, AssignValueTo(&Function4));
}


*** See also #1987.


From:    Anthony Scian                          Rec'd
To:      Chris Boogmans                         Msg #1987, Dec-07-93 10:29AM
Subject: Warning problem in C32/9.5a

 CB> // Kevin, the WatCom C32 compiler version 9.5a is mistaken with regard to
 CB> // it's 'Warning! W200' messages on the code below.
 CB> It issues this warning
 CB> // on the call of WatComFunc2(), which is correct, but it issues the same
 CB> // warning on the call of MscFunc2(), i.s.o. on the call of MscFunc1().
 CB> // Since the MscFuncs are declared 'cdecl', arguments are stacked in the
 CB> // order right to left.
 CB> // It is no big deal ofcourse, but it's best if a compiler only issues
 CB> // warnings when there are any.  Regards, Chris.

 The arguments are being analysed by the compiler as they are being seen
 in the source file.  This is consistent behaviour.  The __cdecl attribute
 is a runtime attribute of the call, it doesn't suddenly cause the compiler
 to parse and check expressions differently.  Furthermore, there is no
 guarantee that the compiler will evaluate the expressions in *any* order
 (even for __cdecl!).  Correct portable code should not have arguments
 that depend on side-effects of other arguments being evaluated.  The warning
 is correct in that the compiler is analysing arguments in left to right
 order regardless of the calling convention.

 CB>
 CB> #include <stdio.h>
 CB> #include <stdlib.h>
 CB>
 CB> unsigned AssignValueTo(void *Variable);
 CB>
 CB> // following 2 functions will be assumed to use WatCom
 CB> calling convention :
 CB> void WatComFunc1(unsigned, void (*)(void));
 CB> void WatComFunc2(void (*)(void), unsigned);
 CB>
 CB> // and these 2 will be assumed to use MSC calling convention :
 CB> void cdecl MscFunc1(unsigned, void (*)(void));
 CB> void cdecl MscFunc2(void (*)(void), unsigned);
 CB>
 CB> void main(void)
 CB> {
 CB>         void (*Function1)(void);
 CB>         void (*Function2)(void);
 CB>         void (*Function3)(void);
 CB>         void (*Function4)(void);
 CB>
 CB>         WatComFunc1(AssignValueTo(&Function1), Function1);
 CB>         WatComFunc2(Function2, AssignValueTo(&Function2));
 CB>
 CB>         MscFunc1(AssignValueTo(&Function3), Function3);
 CB>         MscFunc2(Function4, AssignValueTo(&Function4));
 CB> }
 CB>

*** This is a reply to #1986.


From:    Kevin Blenkinsopp                      Rec'd
To:      Kevin Kitsemetry                       Msg #1990, Dec-07-93 02:03PM
Subject: Diamond Viper

Kevin,

I've been doing some work with the Viper board for a while: what you need to
do is get a hold of Craig Rush at Diamond (he's in charge of third-party
stuff) and see what help he can give you. Diamond will release technical specs
and sample code to you, but only under a non-disclosure agreement.

Kevin

*** This is a reply to #1978.  *** See also #1998.


From:    Hal Schwab
To:      Tech Support                           Msg #1991, Dec-07-93 02:15PM
Subject: _dos_setvect in protect mode.

I am porting some real mode code to protect mode with the 9.5 compiler.
I am currently using the borland setvect() to set the address of my
isrs. Does the Watcom _dos_setvect() set the real and protect mode vectors ?

*** See also #1999.


From:    Jason Fesler
To:      All                                    Msg #1992, Dec-07-93 05:42PM
Subject: Video mode switch time?

Does anyone know why the following code fragment takes one and a half
seconds under Rational Systems's extender?  Is it because of the extender,
the compiler, or my source code (g)?

 ..
_setvideomode(_TEXTC80);
_settextrows(_MAXTEXTROWS);
 ..

Also, has anyone had any luck running fossil communications drivers while
in protected mode?  Or, does anyone have a pointer to interrupt-driven
serial port communications?

Thanks!



... Two most common elements in the universe: Hydrogen & Stupidity.
___ Blue Wave/QWK v2.12

*** See also #2000.


From:    Chris Boogmans                         Rec'd
To:      Kevin Kitsemetry                       Msg #1993, Dec-08-93 11:57AM
Subject: _scrolltextwindow

Kevin,
the function call _scrolltextwindow(_GSCROLLUP) runs 4 to 5 times slower under
version 9.5 (level a) than under version 9.01 (level d and e).  For detailed
info about the selected video mode, pls see the sources. The following things
have no influence on this difference : - wether you'r in a Windows DOS box or
in DOS itself
- the DOS4GW version
- VMM or not
- the drivers and/or TSR you've loaded
- the PC you run it on (tried on an Intel, a Compaq, an Acer & a white product)
I uploaded a file called 'SCROLL.ZIP' which contains a very simple example of
it.  Try running it under version 9.5a, but be sure you have enough coffee at
hand !  Could you guys please have a look at it, cuz it just is too slow ...
Thanks, Chris.

*** See also #2001.


From:    Kevin Kitsemetry                       Rec'd
To:      Kevin Blenkinsopp                      Msg #1994, Dec-08-93 10:23AM
Subject: More real mode stuff

KK> Internal Report #11809

I only looked at it briefly, but if the interrupt is returning a real mode
address in ES:DI, you need to convert it to a protected mode address, which
will be given by CS:((ES << 4) + DI) -- convert the real mode segment in ES to
a linear address, add the offset, then the linear address is equivalent to a
near pointer.

Note that having a protected mode function pointer and being able to CALL the
pointer are two different things.  The function has to be able to run in
protected mode; it has to understand the WATCOM 386 calling conventions; it
has to do the appropriate kind of return.  In general, you CAN'T call a real
mode function from a DOS/4GW application -- you'd have to write your own real
mode code to call the function, install your code as a real mode interrupt
handler, and signal a real mode interrupt.  You'd probably want to use your
own buffer in low memory to stash parameters that the real mode function
needed.

*** This is a reply to #1967.


From:    Christer Palm                          Rec'd
To:      Dan Cummins                            Msg #1996, Dec-08-93 12:03PM
Subject: WVIDEO and A level patch

 CP> As I said before, it looks like WVIDEO is redefining
 CP> the MDA character set or something, horizontal lines
 CP> all over the screen and reverse video.

Perhaps I should make myself even a bit more clear about this.. Actually the
horizontal lines are not really all over the screen, only on the characters
making up the window frame. It came to my mind that this has to be WVIDEO
writing the wrong attributes, causing the window frame characters to be
underlined, and the area inside the windows to be reverse video. I recall that
the colors cand be redefined, this might be a workaround ?? Anyway, it still
behaves differently than before I applied the B-patch, and it certainly
doesn't behave they way I want it.

 / Christer

*** This is a reply to #1981.


From:    Kevin Kitsemetry                       Rec'd
To:      Kevin Blenkinsopp                      Msg #1998, Dec-08-93 11:51AM
Subject: Diamond Viper

 KB> Kevin,

 KB> I've been doing some work with the Viper board for a
 KB> while: what you need to do is get a hold of Craig Rush
 KB> at Diamond (he's in charge of third-party stuff) and
 KB> see what help he can give you. Diamond will release
 KB> technical specs and sample code to you, but only under
 KB> a non-disclosure agreement.

Thanks for the info.  We are working on this issue, and
getting the necessary information to support this card.


Kevin Kitsemetry
WATCOM TECHNICAL SUPPORT

*** This is a reply to #1990.


From:    Kevin Kitsemetry
To:      Hal Schwab                             Msg #1999, Dec-08-93 11:52AM
Subject: _dos_setvect in protect mode.

 HS> I am porting some real mode code to protect mode with the 9.5 compiler.
 HS> I am currently using the borland setvect() to set the address of my
 HS> isrs. Does the Watcom _dos_setvect() set the real and
 HS> protect mode vectors ?

It does, as long as it is in the autopassup range.  See the User's Guide for
details.


Kevin Kitsemetry
WATCOM TECHNICAL SUPPORT

*** This is a reply to #1991.


From:    Kevin Kitsemetry                       Rec'd
To:      Jason Fesler                           Msg #2000, Dec-08-93 11:55AM
Subject: Video mode switch time?

 JF> Does anyone know why the following code fragment takes one and a half
 JF> seconds under Rational Systems's extender?  Is it
 JF> because of the extender,
 JF> the compiler, or my source code (g)?

 JF>  ..
 JF> _setvideomode(_TEXTC80);
 JF> _settextrows(_MAXTEXTROWS);
 JF>  ..

Most likely, it has to do with the switching between protected mode and real
mode DOS during the interrupt.  Are you implying that it is faster with other
extenders?


Kevin Kitsemetry
WATCOM TECHNICAL SUPPORT

*** This is a reply to #1992.


From:    Kevin Kitsemetry                       Rec'd
To:      Chris Boogmans                         Msg #2001, Dec-08-93 11:59AM
Subject: _scrolltextwindow

 CB> I uploaded a file called 'SCROLL.ZIP' which contains a
 CB> very simple example of it.  Try running it under
 CB> version 9.5a, but be sure you have enough coffee at

I could not find this file on our system.  Did you upload
it?  We do not have any record of it being uploaded.


Kevin Kitsemetry
WATCOM TECHNICAL SUPPORT

*** This is a reply to #1993.  *** See also #2006.


From:    Tom Makowski
To:      Tech Support                           Msg #2002, Dec-09-93 10:02AM
Subject: AllocHugeAlias16 Problem

KK> Internal Report #12413


Our 32bit Windows application, in order to save time, caches 16:16 pointer
aliases to 32bit pointers which are then passed to a 16bit DLL. We were using
the AllocHugeAlias16() function to create the 16:16 pointers until a bug was
discovered in it when large buffers (~1Mbyte) were aliased. A patch for the
compiler came to late to get in the release.

To fix this, we created our own 16:16 alias using DPMI calls.  The problem is
that the linear base address of the 32bit pointers appears to change under
certain circumstances (mallocs?) causing our 16:16 alias to become invalid
causing Page Faults or corrupting memory.  The 16:16 aliases created by the
AllocHugeAlias16() get their linear base addresses correctly updated when the
16:32bit pointers base address changes.

I know the current version of the AllocHugeAlias16() function has been fixed
in the current version of the compiler, but we are trying to get a patch out
to our current customers.  So, is there some other function we can call to
prevent the linear base address from changing on the 16:32 pointer.  Or is
there some way to get our 16:16 alias to be updated when the base address of
the 16:32 pointer changes?

       Thanks. Tom

*** See also #2008.


From:    Christer Palm                          Rec'd
To:      Kevin Kitsemetry                       Msg #2003, Dec-08-93 01:12PM
Subject: Serious bug in stream I/O

In my work with a binary file I/O class, based on fstream, I encountered
some very strange bugs.  After about 2 days of debugging I began to
suspect that there was something wrong with the stream I/O.

I put together some very small test programs; mktest.cpp, which creates a
90000 bytes long file filled entierly with 0xaa's - test.cpp which tries
to read that file and display its contents to the screen - and test.c which
does the same thing in plain C.

Sometimes, when I run test (I often have to run it about 10-30 times),
strange things happens. Typical sympthoms are lost characters, total
hangup, exception throws (C++), general protection faults or failure
to detect EOF. The plain C version seems to crash more seldom though.

To test wheather DOS4GW is the problem, I compiled test.c/test.cpp with
Borland C and also with WATCOM linking for PharLap. Both seemed to work
fine, so the problem is probably with DOS4GW although, because of the
intermittent nature of the problem, cannot tell 100%.

 / Christer

// C/C++32 9.5a
// Compile & link: wcl386 [-cc++] [-l=pharlap] [*.c|*.cpp]

// mktest.cpp:
// -----------
#include <fstream.h>

void main( void )
{
  ofstream Stream;

  Stream.open( "test.dat", Stream.out | Stream.binary );
  for( int n = 0; n < 90000; n++ )
    Stream.put( (unsigned char)0xaa );
  Stream.close();
}

// test.cpp:
// ---------
#include <fstream.h>

void main( void )
{
  ifstream Stream;

  Stream.open( "test.dat", Stream.in | Stream.binary | Stream.nocreate );
  while( !Stream.eof())
    cout << hex << Stream.get();
  Stream.close();
}

/* test.c: */
/* ------- */
#include <stdio.h>

void main( void )
{
  FILE *fp = fopen( "test.dat", "rb" );

  while( !feof( fp ))
    printf( "%x", getc( fp ));
  close( fp );
}

*** See also #2022.


From:    Denis Dyack
To:      All                                    Msg #2004, Dec-08-93 02:47PM
Subject: Net Bios Help

Hello,

Has anyone out there done some net bios code.  If so you please point me
in the direction of a good book and perhaps some sample source.

All I really need to do is establish a connection between two
nodes and pass some info back and forth.

Another question as well:

I decided to use net bios so I can support both lantastic and novell.
Was this a good choice?

Thanks, Denis.

*** See also #2019.


From:    John Miles
To:      Jerry Rice                             Msg #2005, Dec-09-93 12:17AM
Subject: Diamond Viper

Newer Diamond Vipers use the Weitek 9XXX chipset, which may be identified
as an older 5186 chip.  Needless to say, there's no backward-compatibility
mode (at least not one that comes up automatically), so
older 5186 code is liable to fail.

The chip is supposedly hot under Windows, but, as has become a custom
among narrow-minded, market-ignorant chipset makers, it's a dog under
DOS.  You will never notice a significant speed increase for chipset
access with this card vis-a-vis VESA, unless the code is poorly
structured enough to perform repeated, redundant, or misplaced bank
access.  There's no point writing chip-specific drivers, due to the
disposable, chip-of-the-week design mentality that currently holds sway
over the market.

Of course, by the time you read this, the Viper cards will probably be
using a different chipset that does happen to work with an older
driver..... :)

-- john

*** This is a reply to #1972.


From:    Chris Boogmans                         Rec'd
To:      Kevin Kitsemetry                       Msg #2006, Dec-09-93 03:08AM
Subject: _scrolltextwindow

Now, i indeed forgot to upload it.  I'll do that now.
Thanks.

*** This is a reply to #2001.  *** See also #2007.


From:    Kevin Kitsemetry                       Rec'd
To:      Chris Boogmans                         Msg #2007, Dec-09-93 10:18AM
Subject: _scrolltextwindow

 CB> Now, i indeed forgot to upload it.  I'll do that now.
 CB> Thanks.

I have reproduced the problem and will have to investigate
further.  This is incident report #12416.


Kevin Kitsemetry
WATCOM TECHNICAL SUPPORT

*** This is a reply to #2006.  *** See also #2009.


From:    Julian Ayling                          Rec'd
To:      Kevin Kitsemetry                       Msg #2009, Dec-09-93 11:51AM
Subject: _scrolltextwindow


*** This is a reply to #2007.


From:    Donald Macmillan                       Rec'd
To:      Kevin Kitsemetry                       Msg #2010, Dec-09-93 04:17PM
Subject: DDE, WATCOM 9.5, PENTIUM, WINDOWS 3.1

Over the last two years we have developed a large (25K lines) C programme
using the Rational DOS Extender. It works and all is well.
Now, I wish to link it to a Windows 3.1 application running under
OS/2 2.1
Is there Watcom expertize in this area? ie a routine to add DDE capability to
my former DOS programme. More than likely, I will recompile my software with
the OS2 switch...but I am still concerned with the DDE link.

*** See also #2013.


From:    Kevin Kitsemetry                       Rec'd
To:      Donald Macmillan                       Msg #2013, Dec-10-93 10:41AM
Subject: DDE, WATCOM 9.5, PENTIUM, WINDOWS 3.1

 DM> Now, I wish to link it to a Windows 3.1 application running under
 DM> OS/2 2.1
 DM> Is there Watcom expertize in this area? ie a routine
 DM> to add DDE capability to my former DOS programme. More
 DM> than likely, I will recompile my software with the OS2
 DM> switch...but I am still concerned with the DDE link.

Using version 9.5, you should recompile the source with the appropriate /bt
option.  You can link the programme for OS2V2 or WIN386 and (unless you have
any DOS specific calls, ie. to graphics routines) then it should work for you.
 We provide a default Windowing system for Windows 3.x which will create stdin
and stdout Windows for you.  Under OS/2,the application will run in text mode,
unless you convert it to a PM application.


Kevin Kitsemetry
WATCOM TECHNICAL SUPPORT

*** This is a reply to #2010.


From:    Tj Bandrowsky
To:      Jerry Rice                             Msg #2017, Dec-11-93 07:42PM
Subject: Watcom C32 for Dos

Is it possible to generate a list of chipsets by looking at the functions
in the graphics library?  I am new to this watcom world, and am trying
to port a video game that uses an undocumented svga mode to watcom.
During a furious session, I noticed there are a set of functions:
pagetseng3_  pagetseng4 that seem to deal with a bank select issue that tends
to vary from card to card.  The drivers seem to deal with chipsets,
not cards, so am I right in guessing that whether or not a card is
supported is a watcom customer service issue and not a graphics driver
issue.

*** This is a reply to #1324.  *** See also #2020.


From:    Tj Bandrowsky
To:      Chris Guerra                           Msg #2018, Dec-13-93 10:07AM
Subject: re: hires video modes

KK> Internal Report #12628


Chris,
In my wanderings, and for the benefit of everyone who is looking and not
finding the file mentioned in Dan's message, I stumbled accidently,and
certainly not in violation of my license, a set of functions in the graphics
library for 9.5 c/c++ 32 that seem to do this switching.

They are in the form pageXXXX where XXXX seems to be the name of the chipset
manufacturer.  Egs pageTseng3_ pageTseng4_ etc.

Now, is there any chance Watcom could cobble together some sort of docs for
these things and post them for those of us such as myself that need to do
custom blits...

OR, if you could stick these three functions in your next patch set...
blitPixelsThatDontMatchColor()
blit32()
Get32()
All of which work in pixels and obey no mapping modes or other such things
that would detract from shareware video game development glory.

I have the functions, and have the bank select for trident, but all those
folks out there I'm sure would appreciate the ability to use all of those
sweet card details already handled by your library.  I know such low calling
make it hard to make sweeping changes, but this functionality is a key to a
lot of interesting vga stuff.

Help us Obi Watcomenobi, your our only hope.

*** This is a reply to #851.  *** See also #2023.


From:    Chris Boogmans
To:      Denis Dyack                            Msg #2019, Dec-13-93 03:42AM
Subject: Net Bios Help

Denis,
i have indeed done some NetBIOS programming.  That was under 16 bit DOS, the
port to WatCom C + DOS/4GW will follow mid 1994.  Regarding your questions :
1- since NetBIOS is a standard, i think it's certainly not a bad choice; i
   chose it for the same reason.
2- (in my opinion) a very good reference work regarding the various network
   interfaces (including NetBIOS) is the 'LanSmart Programmer's Reference',
   from D-Link.  But it may be possible that it is not for sale separately,
   (bundled with their SDK), and it is a reference work, NOT a tutorial.
   There doesn't seem to exist a LanTastic equivalent, and moreover, Artisoft
   does not officially provide customer support for NetBIOS programming (but i
   faxed them twice, and on both occasions they gave me immediate & accurate
   answers anyway, including the remark that they officially don't do that).
   A work that i do NOT like, is 'Inside NetBIOS'.  It tells less (technical)
   details about more things.
3- if you plan to exchange messages between network stations, try to group the
   messages if possible.  During my tests, i experienced that sending short
   frames took a good part off the throughput.
Best regards, Chris.

*** This is a reply to #2004.


From:    Kevin Kitsemetry
To:      Tj Bandrowsky                          Msg #2020, Dec-13-93 10:02AM
Subject: Watcom C32 for Dos

 TB> Is it possible to generate a list of chipsets by looking at the functions
 TB> in the graphics library?  I am new to this watcom world, and am trying
 TB> to port a video game that uses an undocumented svga mode to watcom.
 TB> During a furious session, I noticed there are a set of functions:
 TB> pagetseng3_  pagetseng4 that seem to deal with a bank
 TB> select issue that tends
 TB> to vary from card to card.  The drivers seem to deal with chipsets,
 TB> not cards, so am I right in guessing that whether or not a card is
 TB> supported is a watcom customer service issue and not a graphics driver
 TB> issue.

Take a look at the VGAINFO.C program in the General File area.  This should
give you what you are looking for.


Kevin Kitsemetry
WATCOM TECHNICAL SUPPORT

*** This is a reply to #2017.


From:    Mike Brennen
To:      Tech Support                           Msg #2021, Dec-13-93 10:15AM
Subject: 9.5 b patches

I'm probably one of many wondering when the B patches will be out; until they
come out wildargv won't compile...

*** See also #2025.


From:    Kevin Blenkinsopp
To:      Christer Palm                          Msg #2022, Dec-13-93 11:38AM
Subject: Serious bug in stream I/O

I think that it's a problem with fread etc, not the stream stuff - see other
recent mail for details.


*** This is a reply to #2003.


From:    Kevin Blenkinsopp
To:      Tj Bandrowsky                          Msg #2023, Dec-13-93 12:41PM
Subject: re: hires video modes

VESA 2.0 - It's great. Call them at 408 435 0333 for the specs.


*** This is a reply to #2018.


From:    Garry Taylor
To:      All                                    Msg #2024, Dec-13-93 02:32PM
Subject: Calling 16 bit TSR from 32 bit Dos C++

Hi,
   I am trying to make calls to the driver for my sound card (SBFMDRV.COM)
from a C program, but am having little luck.  The sample program I have seems
to work okay when compile with my old Turbo C compiler, and I thought I had
made appropriate conversions, as suggested by the FAQ that comes with the
compiler, for calling real mode interrupts from Watcom C++, but so far the
most I can say is that my program doesn't crash.  If anyone out there could
offer me some hints, suggestions, or even sample code of some sort, I would be
most grateful!

                            Thanks,
                             Garry

*** See also #2026.


From:    Kevin Kitsemetry
To:      Mike Brennen                           Msg #2025, Dec-13-93 03:12PM
Subject: 9.5 b patches

 MB> I'm probably one of many wondering when the B patches
 MB> will be out; until they come out wildargv won't
 MB> compile...

We are testing them now.  I will let you know when they are available by
placing a bulletin when you first loggon.


Kevin Kitsemetry
WATCOM TECHNICAL SUPPORT

*** This is a reply to #2021.


From:    Kevin Kitsemetry
To:      Garry Taylor                           Msg #2026, Dec-13-93 03:14PM
Subject: Calling 16 bit TSR from 32 bit Dos C++

 GT> Hi,
 GT>    I am trying to make calls to the driver for my sound card
 GT> (SBFMDRV.COM) from a C program, but am having little
 GT> luck.  The sample program I have seems to work okay
 GT> when compile with my old Turbo C compiler, and I
 GT> thought I had made appropriate conversions, as
 GT> suggested by the FAQ that comes with the compiler, for
 GT> calling real mode interrupts from Watcom C++, but so
 GT> far the most I can say is that my program doesn't
 GT> crash.  If anyone out there could offer me some hints,
 GT> suggestions, or even sample code of some sort, I would
 GT> be most grateful!

Did you at least get the example program working, using
DPMI function 300h?  What other problems are you running
into?


Kevin Kitsemetry
WATCOM TECHNICAL SUPPORT

*** This is a reply to #2024.


From:    Kevin Kitsemetry
To:      Tj Bandrowsky                          Msg #2027, Dec-13-93 03:47PM
Subject: re: hires video modes

KK> Internal Report #12628


 TB> They are in the form pageXXXX where XXXX seems to be
 TB> the name of the chipset manufacturer.  Egs pageTseng3_
 TB> pageTseng4_ etc.

 TB> Now, is there any chance Watcom could cobble together
 TB> some sort of docs for these things and post them for
 TB> those of us such as myself that need to do custom
 TB> blits...

 TB> OR, if you could stick these three functions in your
 TB> next patch set... blitPixelsThatDontMatchColor()
 TB> blit32()
 TB> Get32()

The _PageXXXX functions could be called directly, but this
is not their intended use. Some of the information in these functions came
from the following books:

    Advanced Programmer's Guide to SuperVGAs (by Sutty and Blair)
    Programmer's Guide to the EGA and VGA Cards, Second Edition (by Ferraro)

There currently are no plans to document these functions, or to add the
functions you mentioned, at this time.

Kevin Kitsemetry
WATCOM TECHNICAL SUPPORT

*** This is a reply to #2018.


From:    Nancy Zentner                          Rec'd
To:      Dan Cummins                            Msg #2028, Dec-13-93 07:14PM
Subject: linker bug report

I am uploading a file "12711.zip" with a linker bug report example.
I am going to try to upload it into area 12


From:    Joseph Schachner
To:      All                                    Msg #2029, Dec-14-93 11:23AM
Subject: Locking for VM - msg 1985

Since no answer to message 1985 has appeared here, I'll answer my own message!
First of all: There were several errors in the code I included in message
1985.  I misunderstood the order of bytes in the descriptor,and I neglected to
fill in 1's when I multiplied by 4096.  When corrected,both code and data
segments have base of 0 and seglimit of 4 Gigabytes.

All that is really irrelevant, however.  What I wanted to do was lock all of
the code and data segment into physical memory, and I was concerned that &_end
was larger than I expected.  I sent this question to Rational Systems,and got
back a fax containing a demo program showing how to lock all of code and data,
which I have duplicated below.

The cover page said, "It's easier than you think..."  To make a long story
short, Rational makes sure they know the first and last labels in the code
segment, and the first label in the data segment.  They use &_end (defined in
the startup file) for the end of the data segment. WATCOM tech support
verified that CODE and DATA segments are contiguous in linear address space,so
I believe locking from &___begtext to &_end will lock all the code and data;
in that case it's not necessary to make dummy labels.  And the very large
values are fine: it's the difference that counts.  (These symbols are defined
in the startup file,and can be referenced even though they don't appear in the
.MAP file, as shown below).  Now, here's Rational System's demo program:

/*
    LOCK.C - The following program demonstrates how to determine where
    the code and data segments have been loaded in memory, which you
    may need to know in order to lock various pieces.
*/
#include <stdio.h>
#include <dos.h>
#include <i86.h>

/*
    The basic problem is to figure out, at run time, where the code and
    data objects have been loaded.  Code is generally in link object 1, data
    in object 2.

    WATCOM provides several convenient symbols for locating different
    types of data in memory.  However, you must provide some of your
    own labels to get the complete picture.  Use your link map to make
    sure your labels correctly mark the beginning and end of code
    and data.

    Link address        Memory

                +-------+
                | HEAP  |
    _STACKTOP    +-------+
                | STACK |
    _end         +-------+
                | BSS   |
    _edata       +-------+
                | DATA  |
    2:0         +-------+

    1:?         +-------+
                | CODE  |
    1:0         +-------+
*/

char begdata = 0;               /* Label for start of inited data */
                        /* (link this datum at 2:0) */
extern char _edata;             /* Label for end of DATA */ extern char _end;
              /* Label for end of BSS */
extern INT _STACKTOP;           /* Label for end of STACK */

void begcode (void)             /* Label for start of code */
    {                   /* (link this function at 1:0) */
    }
void endcode (void);            /* Forward reference */

int lock_region (void *address, unsigned length)
    {
    union REGS regs;
    unsigned linear;

    printf ("Locking %u bytes at %p: ", length, address);
    linear = (unsigned) address;

    regs.w.ax = 0x600;          /* DPMI Lock Linear Region */
    regs.w.bx = (linear >> 16);  /* Linear address in BX:CX */
    regs.w.cx = (linear & 0xFFFF);
    regs.w.si = (length >> 16);         /* Length in SI:DI */
    regs.w.cx = (length & 0xFFFF);
    int386 (0x31, ®s, ®s);

    if (regs.w.cflag)
        {
        printf ("FAILED\n");
        return(0);
        }
    else
        {
        printf ("succeeded\n");
        return(1);
        }
    }

void main (void)
    {
    static char somedata[100] = { 0 };

    printf ("Memory map:\n");
    printf ("CODE           %p\n", begcode);
    printf ("            to %p\n", endcode);
    printf ("DATA           %p\n", &begdata);
    printf ("            to %p\n", &_edata);
    printf ("BSS         to %p\n", &_end);
    printf ("STACK       to %p\n", _STACKTOP);
    printf ("HEAP begins at %p\n\n", malloc (1));

    lock_region ((void *) &begdata, &_end - &begdata);
    lock_region ((void *) &begcode, (char *) endcode - (char *) begcode);
    }

void endcode (void)             /* Label for end of code */
    {                   /* (link at end of code segment) */
    }

/* end */


From:    Ron Smith                              Rec'd
To:      Kevin Kitsemetry                       Msg #2030, Dec-14-93 08:17AM
Subject: C++32 B level patches

We were told almost a month ago that the B-Level patches would be available in
two weeks!!!  We are in desperate need of one of thoses patches.  Your
compiler is generating bogus code and the linker is broken too (as of the A-
Level patches).  Can someone give me a straight answer???

*** This is a reply to #1980.  *** See also #2031.


From:    Kevin Kitsemetry
To:      Ron Smith                              Msg #2031, Dec-14-93 11:23AM
Subject: C++32 B level patches

 RS> We were told almost a month ago that the B-Level
 RS> patches would be available in two weeks!!!  We are in
 RS> desperate need of one of thoses patches.  Your
 RS> compiler is generating bogus code and the linker is
 RS> broken too (as of the A-Level patches).  Can someone
 RS> give me a straight answer???

We are testing the patches right now.  When they become
available, there will be a message placed in the bulletins
when you loggon.

We could have released them a week ago, but QA testing found problems that we
felt were best resolved before they are
released.


Kevin Kitsemetry
WATCOM TECHNICAL SUPPORT

*** This is a reply to #2030.


From:    Kevin Kitsemetry
To:      Nicos Skouras                          Msg #2032, Dec-14-93 12:10PM
Subject: W9.5a function problem

KK> Internal Report #12307


 NS> Please reference file STRERR.ZIP uploaded in the file area
 NS> with str.c & the result of it.
 NS> In short: the strtol () function does not recognize a hex
 NS> valua as signrd but treats it as unsigned.

I have taken a look at the file, and I am not sure there is a problem.  What
output do you expect from this program?


Kevin Kitsemetry
WATCOM TECHNICAL SUPPORT

*** This is a reply to #1984.


From:    Kevin Blenkinsopp
To:      Kevin Kitsemetry                       Msg #2033, Dec-14-93 01:32PM
Subject: System(NULL)

Kevin,

I think I'm a bit confused about something - I can't get system(NULL) to work.
It's supposed to go looking for the command interpreter if you don't give it a
real arg, but it never seems to find it, even if I run it from c:\
Comspec is set right. I'm using msdos 6.0, with the b-level pre-release of
wpp386. I'll try and dig out my 9.5a backup and see if it works under that,
but could you please look into this at your end?

Cheers,

Kevin


From:    Robert Klein
To:      All                                    Msg #2034, Dec-14-93 01:47PM
Subject: Graphics

I'm a new Watcom C/C++32 user and I have a few problems.  First of all,
The Watcom graphics functions do not see I my adapter as SVGA.  I've got
a Compudyne 486DX266 Active Matrix notebook that uses the Cirrus Logic
VGA chip set with 512k RAM.  Also, Video modes I require are not supported
such as 320x240x256, 320x400x256, 640x400x256.  Even with the 320x200x256,
_getvideoconfig reports only one video page q

I don't understand `Q'.


[2034 / 2034]  Msg.area 12 ... WATCOM C/C++32 9.5 Problems and Fixes
               Type message number, or press <enter> for NEXT msg.

MESSAGE:
A)rea Change        N)ext Message       P)revious Message   E)nter Message
R)eply to a messag  C)hange a message   =)read_non-stop     -)read_original
+)read_reply        L)ist (brief)       M)ain Menu          J)ump to file area
G)oodbye (log off)  K)ill (Delete) Msg  U)pload a message   F)orward (copy)
B)rowse messages    *)ReadCurrent       T)ag areas          ?)help
Select: g

Disconnect [Y,n,?=help]? y

Leave a message to Kevin Kitsemetry [y,N,?=help]? n

Quote for the day:

Arcana Coelestica:
  Archbishop - A Christian ecclesiastic of a rank superior to
  that obtained by Christ.
  Puritanism - The haunting fear that someone, somewhere,
  may be happy.



So long, Robert.  Please call again!


NO CARRIER