PowerBuilder generates executables
in two formats machine (also known as c-code) and interpreted (also known
as p-code).The project painter includes options for machine code generation
and "Incremental and Full Rebuild" functionality to ensure the integrity of
the objects before generating the executable. For this document 'machine code'
and 'c-code' are used interchangeably as are 'interpreted code' and 'p-code'
General EXE generation problems:
Problem: At times I may need to upload my application on another system to run a parallel exe creation. It's a lot of work to make sure the connections to the database and the tables exist on the other system as well so PowerBuilder can do the SQL verification during the exe creation process. Can this be made simpler?
Resolution: Here is where we dispel a big myth about exe generation. Building an executable requires a connection to ANY database - not a specific database.... What you see in the microhelp is the development environment connecting to the database as it hits a datawindow or embedded SQL and you assume it's validating either embedded or datawindow SQL - but it isn't. This means the developer can create an executable on ANY machine that has PowerBuilder software and ANY connection to ANY database even if they don't contain the tables referenced in your Powerscript or datawindows. SQL Anywhere 5.0 / Adaptive Server Anywhere (ASA) works perfectly fine and has a much smaller footprint than most other dbms's in memory, but it really doesn't matter. Connect to ANY database in the development environment before you create your exe.
Problem: Machine-Code exe creation uses up a lot of my disk space. What are some general recommendations?
Resolution: You'll need fairly large swap files and the system's TEMP directory for the generated .c files. Normally, you'll never see the .c and .tmp files unless the EXE creation terminates unexpectedly. In this case, you will find various files, and should delete all the files created in your \TEMP directory (after investigating the errors). The algorithm for naming the .c files for objects prevents collisions so even if you don't delete old files, you should never get a collision.
Problem: My application runs fine in development but I get a blank "Link Errors" messagebox while trying to generate an executable. What is causing this problem?
Resolution: It could be a number of things. Consider the components that are only referenced during the creation of the executable in the project painter. Some likely causes:
- Application .ico file. The only time this file is checked for validity is during exe creation. Make sure it's a valid .ico file and not a renamed .bmp file. If you can open this file up directly in Win95 Paint, it's not a valid Icon.
- PBTYP050.DLL is in a writable directory for the first exe compile (machine code or interpreted p-code). The compilation process tries to "regenerate" this DLL but only during the FIRST exe creation. This is a good suspect if PowerBuilder was recently installed on a network. ( PowerBuilder 6.0 and 7.0 do not have this requirement since PBTYP##.DLL isn't part of the environment.)
Machine code generation problems:
Problem: I'm building 16 bit machine code and hit a lot of these 64k segment violation errors. What are these caused by?
Resolution: This is because an object or event script is too long. You must break up the scripts to eliminate this error in 16 bit. See the .log file in the 'temp' directory for some details. You can investigate the .c file in the PowerBuilder file editor (using 'Edit/GoTo Line' is helpful). Each Powerscript line is flagged somewhat in the .c file.
1. Search backwards for a line with a @ sign. This gives you the line of Powerscript.
/*@38 Line 20 SM..../
2. Find the event/object by searching backwards for:
a. 'start of p-codes'
ex: /* SECTION.Open uo_picker_object.udo offset 427 */
A few lines after this, you
can find what Function or Event is being referenced.
/* FUNCTION loadorgzero */
PBWINAPI( INT, _fn_199_32770_108 )
You should see either the Function or Event listed near the PBWINAPI statement.
So the error is at Line 20 of object function "LoadorgZero" on uo_picker_object.
Problem: If I fix the first 64k segment error with 16 bit Machine Code I could get another error in the same PBL. Why doesn't it find all of them at once?
Resolution: The exe generation process doesn't find all of the 64k segment errors in one pass. We suggest you run 1 exe compile to find the first error. If you feel that a lot of your objects have long scripts that could cause a dozen or so of these errors, you could use the library painter "Library/Build Runtime Library" option to create individual DLLs. If your first error is on pbl 15 of 20, you won't have to wait while your machine creates DLLs for pbls 1-14 again just to find the next error in PBL 15, 16 and up.
Problem: The exes seem to run OK in interpreted ( p-code) and development but not in Machine Code. What is the next step?
Resolution: Build the DLLs with "Error Context Information" and 'Trace Information" ON. You need this in machine code in order to have the /PBTRACE work on the exe command line. If the system GPF's, you should be able to track down the line using /pbtrace. If this is a visible behavior type of problem (the background of a column doesn't change to red when it should). There are several possible causes when there is different behavior between the c-code and p-code engine. All should be reported.
Problem: The first time I ran the exe creation with machine code (32 bit), I used Full Rebuild in the project object. I received a "fatal disk error" with about 80% of my PBLs finished. Creating a p-code executable using a similar project object ran to completion.
Resolution: It could be related to a PBL in your library path not being writable. (In Novell land this is the shareable attribute). Sometimes, we forget that our class libraries are on our library path and "read-only" and by using Full Rebuild, PB will try to rebuild and regenerate ALL objects. Even if these files are copied locally for speed, they may still have 'read-only' attributes set. (ever try to delete PSDEMODB.DB?)
It could also be related to the size of your memory+swapfile if running NT. You could get an 'out of memory' type of error message. The compile process needs a lot of memory, swap file and disk space to place the .c files before compiling all the objects contained in a PBL into a DLL.
Problem: Why am I getting this error running a p-code under 32 bit?
"Error opening DLL library user.exe for external function at line 3 in clicked event of <object name> of <window name>. "The application or DLL USER.exe is not a valid windows NT image. Please check this against your installation diskette."
Resolution: The developer is probably using a Windows SDK function call specific to an OS. The 16 bit and 32 bit APIs are slightly different and the developer should be using GetEnvironment() to determine which OS the application is running on. The are several methods to ensure the correct DLL is called during runtime.
16 bit - USER.exe
32 bit - USER32.DLL
Problem: Customer is getting the error message "syntax error probable cause missing ';' ".
Resolution: This error message if flagging an error with the particular line of Powerscript that was compiled into c-code. Investigate further the line of Powerscript causing the error and report this to Powersoft.
Problem: I'm trying to have all my developers run off one set of PowerBuilder 32 bit DLLs on a read-only network drive. When they compile their machine code executables, they get the following error:
"Could not create or open file en32t.h(or en16t.h) create of exe file failed". Network drive is read-only.
Resolution: Have someone log on to the network server - the actual physical machine containing the the network PowerBuilder install - and delete the existing files (.pch and .h files) underneath the \CGEN directory. Do not delete the lib286, lib386 or H directories. Then, have this user create a simple machine code executable on the server (the machine containing the network PB installation) ONCE. This will create the .h and .pch files on the read-only drive in the \CGEN directory that are in-sync with the particular installation. They should not have to be recreated.
Common Errors while
Possible errors running 16 bit exes under 32 bit NT 4.0 and Win95
Problem: "R0014 Error opening DLL library <name>.DLL for external function" when doubleclicking on Icon for created exe.
Resolution: Windows doesn't allow you to have a DLL and EXE of the same root name (test.exe, test.DLL). The project painter, unfortunately prompts the user to create the conflict. Workaround: Fix the project object making sure the name of the exe is different than any of the DLLs in the library searchpath.
Possible errors 16 bit machine code exe under Win95
1. "One of the library
files ... is damaged".
Solution: Running 16 bit exe but picking up 32 bit runtime DLLs. Be careful when trying to run exe directly. You could have a conflict due to your PATH or the "App Path" in the Win95/NT 4.0 registry. Make sure Icon has the correct "start in" directory for properties and the 16 bit runtime is installed. Be aware of this when deploying and using Install Builder.
2. Blank "Link Errors" messagebox during compile of 16 bit machine code exe or "see <exename>.log" message. The .log file would have something like:
CGEN: Compiling 'D:\TEMP\exename.c'
D:\TEMP\a.c(13) declaration specifiers are required to declare 'INT'
D:\TEMP\a.c(12) syntax error before 'WINAPI'; probable cause: incorrectly spelled type name
Solution: Need to delete all the .h, .pch files under \Powersoft Shared\CGEN directory (Long Filenames path shown for PB 5 and PB 6; for PB 6.5 and later the CGEN directory would be found in: \Program Files\Sybase\shared\PowerBuilder\) and re-compile. Leave the directories H, lib286, lib386 alone. This probably happens most often during maintenance release upgrades.
The following errors are included for completeness.
(These operating systems are no longer supported by Microsoft or Sybase.)
Possible errors 16 bit machine code exe under NT 3.51:
Problem: "R0001 Fatal Execution Error Application Reference could not be resolved."
find the application DLL(s) created from PBLs. Make sure the DLLs are included
in the system PATH (DOS/Win 3.1 and NT 3.51 somewhat) or Registry 'App Path'
for the executable (Win95, NT 4.0) or somewhere the EXE can find them. Check
"Working Directory" under File/Properties" (Win 3.1/NT 3.51) or "Start In"
directory for Win95/NT 4.0.
Possible errors 16 bit machine code exe under Windows 3.1x or WFW 3.11:
Problem: GPF in KRNL386.EXE GPF when doubleclicking on the exe.
Resolution: This has been fixed with a patch to 5.0.01.
Problem: "R0014 Error opening DLL library <name>.DLL for external function".
Resolution: Same error as 16 bit machine code under 32 bit Win95/NT errors .
Problem: "Insufficient Memory to run this application" when doubleclicking on exe.
Resolution: In most cases, we've found that the developer did not check off ALL pbls in the project painter "pbd" (dynamic library) checkbox to be built into DLLs. Often this creates an executable that is fairly large (600k and up) when all objects in the "unchecked" pbl are copied into the exe. For creating 16 bit machine code executables, you must check off ALL pbls to be built into DLLs. This creates a very small executable that will load into conventional memory. In PowerBuilder 6.0, creating a 16 bit executable automatically checks all PBLs as PBDs so this error will not happen. The 16 bit environment is not supported with PowerBuilder 7.0.