Problems linking with PTC libraries in the Visual C++ IDE |
Problem
Programs built with Visual C++ and the batch
files work fine, but when they are built inside a Visual C++ project they
report many linking errors such as "XXX is already defined in YYY" and
"use /nodefaultlib".
Solution
PTC is a multithreaded library, and because
of this, the PTC libraries expect to be linked with the multithreaded versions
of the C runtime libraries. These link problems occur when the ptc library
files are linked against the wrong C runtime library. To fix this (in Visual
C++ 5), after you create your project go to Project->Settings. In here
go to the C++ Tab. Then select "Code Generation" in the drop down box.
You should now see a drop down box "Use runtime library:" here you must
select "Debug Multithreaded" if you are linking against a PTC debug.lib,
or "Release Mulithreaded" if you are linking with PTC release.lib. After
you have set up the correct run-time libraries PTC programs will link without
any problems in VC++.
Problems with PTC programs built using Watcom C++ for DOS |
Problem
Programs using PTC and built under Watcom C++
10.x for DOS crash or lock up, or display a black screen when running.
Solution
All of these problems are caused by a bug in
the Watcom C++ 10.x runtime library. The culprit is the fopen,fread,fwrite,fclose
pair of functions. To fix this, switch to another compiler or stop using
any of the buffer file i/o runtime functions (use the unbuffered open,read,write,close
functions instead, or use the PTC "File" class). Note: this bug is the
cause of all the problems with the demo Tribes by Pulse (TP97 winner).
Look for a really final release soon :)
Output problems under Win32 with GDI |
Solution
These bugs existed in PTC 0.60 and have been
fixed in version 0.61. If you are experiencing any of these problems please
upgrade to a newer version of PTC.
Old PTC programs crash when rebuilt with the new PTC |
Solution
This problem occurs because surface allocation
changed greatly in version 0.60. Surfaces can no longer be assumed to be
linear blocks of memory, now they can be either topdown or bottomup surfaces,
and may have an "advance" of x bytes between each line. To make old programs
work it is required to use the surface "pitch" to move from the start of
one line to the next. For an example of how to work with these changes
see the "rand32.cpp" example program.
PTC programs lock up or reset computer when run |
Solution
A number of things can cause this. The most
common cause is a bug in your code, check to make sure that you are staying
in bounds of surface memory and not reading/writing anywhere outside the
surface memory by mistake. Another common problem is having a stack that
is too small. PTC can get quite stack intensive so make sure you have at
least 64k of stack allocated. This is especially important with Watcom
C++ which has a very small default stack size. A less common cause is a
UniVBE bug on some cards (reported on S3 Trio 64+ with UniVBE 5.3). You
can fix this by upgrading to the latest version of SciTech Display Doctor
from www.scitechsoft.com.
Black screen on ET6000 |
Solution
This problem only occurs when the user is running
UniVBE 5.3 (SciTech Display Doctor). This is a confirmed bug in UniVBE
and is not a bug in PTC. The problem only occurs with 32bit display modes,
all other modes set correctly. The best solution is to upgrade to a more
recent version of SciTech Display Doctor (available from www.scitechsoft.com).
Another solution is disable univbe (type "univbe off") before running the
program. Alternatively the user can specify a different pixel format to
use on the command line. For example "demo RGB888" will fix the problem
by forcing a 24bit display mode, but only if the program author has allowed
command line PTC initializing (see the "image.cpp" example program to find
out how to do this).
pmode/w bug under NT |
Solution
It seems that pmode/w has bugs that cause it
to crash under NT when interfacing to the VESA bios. Programs bound with
pmode/w crash when using VESA under NT, but operate fine using VGA under
NT, and both VGA/VESA on DOS and Win95. The only way to fix this is not
to use pmode/w.
DJGPP crash under NT |
Solution
PTC uses near pointers to access VGA and VESA
display memory. DJGPP does not support near pointers under NT, and will
crash if they are used. If your programs must run under NT, consider switching
to Watcom C++ which operates perfectly under the NT dos box, or build a
native Win32 application.
Problems with DJGPP + PTC + Midas + Allegro |
Solution
Old versions of PTC used the variable "__crt0_startup_flags"
to enable near pointers under DJGPP. This caused conflicts with Midas and
Allegro, which both try to do their own setup using the same variable.
This problem was fixed in version 0.60.
Strange output window under Watcom C++ |
Solution
This problem was fixed in version 0.61. Upgrade
to a newer version of PTC.
Image loading fails under Watcom C++ 10.x |
Solution
This problem occurs because of an i/o bug in
the Watcom runtime library. This problem was fixed in PTC 0.61.
Windows are created without focus |
Solution
This problem was fixed in PTC 0.70. Upgrade
to a the latest version of PTC.
Other problems... |