mguyott@eriador.prime.com (04/03/91)
We are attempting to use Borland`s new C++ on a real "commercial"
Windows 3.0 project. We were using Zortech C++ and were very happy with it
until we attempted to use their int86x() function. This function does not
work and as we absolutly need it for our communications software we
were left with nothing we could do. Soooooo, we are trying Borland's
C++ compiler. The first problem that we ran into was that we received
an error message indicating that we had exceeded some internal compiler
table size. The message was:
Compiler table limit exceeded.
We called Borland and they told us our program was too complex and we
should make it simplier! That was a lot of help! We managed to get
it working for the moment by limiting the parts of windows.h that we
include (i.e. we defined things like NOSOUND, NOMETAFILE, etc.). This
initial problem has made it clear to us that Borland`s C++ is only a
temporary fix until we can find a real C++ compiler that works. I
really wish Zortech would fix their int86x() bug so we could go back to
their compiler (anyone from Zortech listening! (-8 )!
Anyway, at this point we were making progress. Now I have encountered
a problem that I can not work around. I would greatly appreciate any
help that anyone who has experienced this problem could provide me with!
The problem is in attempting to call MakeProcInstance(). The compiler
does not seem to recognize the dialog box function name. The compiler
appears not to recognize it despite a function prototype only a
few lines prior. At this point I have no idea how to get the compiler to
do the right thing.
The error generated is:
----
Borland C++ Version 2.0 Copyright (c) 1991 Borland International
conndlg.cxx:
Error conndlg.cxx 28: Type mismatch in parameter 1 in call to
'MakeProcInstance(int(far pascal*)(),unsigned int)' in function
ConnectDlg::ConnectDlg(unsigned int,unsigned int)
*** 1 error in Compile ***
Available memory 1048575
----
The code that generates this error is:
----
#include <windows.h>
#include "conndlg.hxx"
BOOL FAR PASCAL ConnectDlgProc(HWND, WORD, WORD, LONG);
/* Public member functions.
*/
ConnectDlg::ConnectDlg(HANDLE hInstPar, HWND hWndPar)
{
hWndParent = hWndPar;
hInstParent = hInstPar;
lpfnConnectDlgProc = MakeProcInstance(ConnectDlgProc, hInstParent);
}
/* This is the dialog box win proc. It is a friend to this class so it
** is able to access the member variables of this class.
*/
BOOL FAR PASCAL ConnectDlgProc(HWND hDlg,
WORD wMessage, WORD wParam, LONG lParam)
{
return(FALSE);
} /* End of ConnectDlg::ConnectDlgProc(). */
----
If anyone wants more information please feel free to contact me.
Wish me luck! Marc
----
Two of the worst things we teach our children are that a knowledge of science
is nice but not necessary, and a knowledge of sex is necessary but not nice.
Marc Guyott Constellation Software, Inc. (508) 620-2800
Framingham, Mass. 01701 USA Ext. 3135
mguyott@primerd.prime.com ...!{uunet, decwrl}!primerd.prime.com!mguyottmguyott@eriador.prime.com (04/04/91)
FYI:
I have found a work around for this problem by changing the typedef for
FARPROC in Borland's version of windows.h to include the HWND, unsigned,
WORD, and LONG parameters. Marc
----
Two of the worst things we teach our children are that a knowledge of science
is nice but not necessary, and a knowledge of sex is necessary but not nice.
Marc Guyott Constellation Software, Inc. (508) 620-2800
Framingham, Mass. 01701 USA Ext. 3135
mguyott@primerd.prime.com ...!{uunet, decwrl}!primerd.prime.com!mguyottjohnm@spudge.UUCP (John Munsch) (04/04/91)
In article <149000018@eriador> mguyott@eriador.prime.com writes: >We were using Zortech C++ and were very happy with it >until we attempted to use their int86x() function. This function does not >work and as we absolutly need it for our communications software we >were left with nothing we could do. Why not just fix the int86x() yourself or build a clone of its functionality using Masm? Zortech makes its source available for a reasonable fee and fixing the one function (especially if you know what is going wrong) would not seem so odious to me. I've had to do a lot worse to make projects work in the past. [Stuff Deleted] >The problem is in attempting to call MakeProcInstance(). The compiler >does not seem to recognize the dialog box function name. The compiler >appears not to recognize it despite a function prototype only a >few lines prior. At this point I have no idea how to get the compiler to >do the right thing. > >The error generated is: > Borland C++ Version 2.0 Copyright (c) 1991 Borland International > conndlg.cxx: > > Error conndlg.cxx 28: Type mismatch in parameter 1 in call to > 'MakeProcInstance(int(far pascal*)(),unsigned int)' in function > ConnectDlg::ConnectDlg(unsigned int,unsigned int) Clear cut enough. The compiler has MakeProcInstance() defined as having a FARPROC as it's first parameter, you passed it a reference to a function with a bunch of parameters (while FARPROC is defined as having no parameters). Just typecast the function to a FARPROC and your problems will probably go away. John Munsch "I hope there is a special place in hell reserved for the person or persons who decided that inews should count how many lines of original text I have in this message."
mguyott@eriador.prime.com (04/04/91)
I believe that I now have the correct solution. I have changed all window
procedures and dialog box procedures to be class memeber functions and I
have declared them as "static int FAR PASCAL _export". The part that I
was missing before was the "static" keyword. Without the "static" keyword
the compiler does not seem to be able to correctly resolve the reference.
Another problem I have run into is linking with "EXPORTED" functions listed
in the .def file. I have tried using the -W switch and listing functions in
the .def file - this did not work (linker complains about trying to export
non-public symbols). I have tried using the -WE switch with the _export
keyword and the functions listed in the .def file. The same problem occured
as before (attempting to export non-public symbols). Finally I tried
using the -WE switch with the _export keyword and nothing in the .def file.
This worked. It appears that you can not specify a function name as an
export in the .def file. This must be really convenient for people who
are writting DLLs. Am I missing something (other then my mind (-8 )?
Marc
----
Two of the worst things we teach our children are that a knowledge of science
is nice but not necessary, and a knowledge of sex is necessary but not nice.
Marc Guyott Constellation Software, Inc. (508) 620-2800
Framingham, Mass. 01701 USA Ext. 3135
mguyott@primerd.prime.com ...!{uunet, decwrl}!primerd.prime.com!mguyottmguyott@eriador.prime.com (04/05/91)
Unfortunately we do not have the knowledge in house to write a working
int86x() for Zortech. It requires quite a bit of handshaking with DPMI.
We tried. After spending 2 days and getting nowhere we switched to
Borland C++. Boy I would love to go back to Zortech. It's much better
then Borland C++. But in this case Borland C++ works and Zortech C++
does not.
If there is anyone out there with the expertise to write an int86x()
function that will allow interrupts from Windows 3.0 in protected mode
please let me know how long and how much it would take for you to
implement such a function. I'm not sure we would do it but I for one
would consider it in order to be able to use Zortech once again.
It is too bad though, I am really disappointed with the amount and
quality of the feedback and support we have received from Zortech. I
don't know why I thought they were any different then Microsoft ...
Marc
----
Two of the worst things we teach our children are that a knowledge of science
is nice but not necessary, and a knowledge of sex is necessary but not nice.
Marc Guyott Constellation Software, Inc. (508) 620-2800
Framingham, Mass. 01701 USA Ext. 3135
mguyott@primerd.prime.com ...!{uunet, decwrl}!primerd.prime.com!mguyottmlord@bwdls58.bnr.ca (Mark Lord) (04/05/91)
In article <149000018@eriador> mguyott@eriador.prime.com writes:
<
< Compiler table limit exceeded.
<
<We called Borland and they told us our program was too complex and we
<should make it simplier! That was a lot of help! We managed to get
Just break up the module that produced the message into a couple of smaller
modules. Does the error also occur when using the "x" version of the compiler?
Alternatively, one could avoid this entire mess by simply coding your own
version of the int86x() routine to replace the "broken" Zortech one. This is
a *really* simply piece of code to write.
<The error generated is:
...details omitted...
On the off chance that the compiler really *did* find an error,
try using:
... = MakeProcInstance(int(far pascal*)ConnectDlgProc,(unsigned int)hInstParent)
^
or maybe again without the star |
--
MLORD@BNR.CA Ottawa, Ontario *** Personal views only ***
begin 644 NOTSHARE.COM ; Free MS-DOS utility - use instead of SHARE.EXE
MZQ.0@/P/=`J`_!9T!2[_+H``L/_/+HX&+`"T2<TAO@,!OX0`N1(`C,B.P/.DS
<^K@A-<TAB1Z``(P&@@"ZA`"X(27-(?NZE@#-)P#-5
``
end