No announcement yet.

PB 3.5 compiler weirdness woes.

  • Filter
  • Time
  • Show
Clear All
new posts

  • Guest's Avatar
    Guest replied
    It appears that rebooting Windows 98 may have possibly solved
    this issue. I can not recreate the problem today with the same
    code I zipped and sent to Lance. I just tried it. I HAVE added
    a little bit of software to Windows, but that should not have altered how a
    DOS window's environment behaves.

    It would be nice if this is the "fix". It appeared to be a
    compiler problem because shuffling things around would make
    things work again/behave differently, but the real problem
    seems to lie in Windows 98. I'll continue to do development
    work in Win98 in hopes of finding another ill-compiled program
    combination, then reboot to test my hypothesis and let
    everyone know.

    I rebooted to DOS on Friday when I had these problems and the
    code compiled sucessfully and ran, so I've been developing
    in DOS only since then. I just recently tried to recreate the
    problem again by compiling under a Win98 DOS prompt with the
    zipped file I sent, and can not.

    Have I stumbled onto something? Has any users who have had
    these problem ever experienced it in pure DOS (not a DOS window)?
    If so, would rebooting not let you recompile sucessfully? Did
    you try it?

    I can recall one time when I had these problems. I was
    screwing around for hours without luck of getting any code
    combination to run. When I did get the code to run, I tried
    "breaking" it, and found I couldn't anymore. I couldn't
    explain it at the time, but perhaps I rebooted???



    Leave a comment:

  • Jerry Fielden

    If I put these 3 new variables in a new file called
    "globals2.bas", and $INCLUDE this after the $INCLUDE for
    "globals.bas", it crashes.

    Now this is what's really weird. If I comment out these 3 new
    variables, so that "globals2.bas" is essentially 3 comment lines,
    The program will crash as well.

    That seems correct to me. I always thought that commented lines
    were included in on the size, I could be wrong. If I am, somebody
    will correct me.


    Leave a comment:

  • Mel Bishop
    I've run across this problem once or twice. The problem is that
    some of your segments are right on the ragged edge of being too
    big for a segment. All that it takes to push it over the edge
    is, in your case, adding one or two statements and the compile
    goes south.

    I solved this problem by removing every $SEGMENT statement in
    the source code (starting with a clean sheet, so to speak) then
    try compiling the program. When it reaches the EXCEEDS 64K (or
    something like that) error message, just add in a $SEGMENT
    statement at an earlier, appropriate, entry point.


    Leave a comment:

  • Tom Hanlin
    We're not going to get far wandering around in the dark. If you could
    submit the code to tech support, we will have a chance to offer more
    useful advice. mailto:[email protected][email protected]</A>

    I see that the program appears to have hardware interrupt service
    routines-- an easy way to get to the fabled Land of Weird Errors.
    Do make sure that you have only asm code, not PB code, in the
    interrupt handlers. The PowerBASIC runtime routines are not reentrant.

    Tom Hanlin
    PowerBASIC Staff

    Leave a comment:

  • Guest's Avatar
    Guest replied
    Here are the segments for a version that doesn't run, with
    the GLOBALS2.BAS $INCLUDEd after GLOBALS.BAS - The 3 variables
    are NOT commented out at this time.

    Start Stop Length Name

    00000H 00000H 00000H LSEG1
    00000H 0809FH 080A0H LSEG2
    080A0H 0863FH 005A0H LSEG3
    08640H 086BFH 00080H LSEG4
    086C0H 087DFH 00120H PowerBasicSeg01
    087E0H 088FFH 00120H PowerBasicSeg02
    08900H 08D5FH 00460H PowerBasicSeg03
    08D60H 1464FH 0B8F0H PowerBasicSeg04
    14650H 2197FH 0D330H PowerBasicSeg05
    21980H 2D03FH 0B6C0H PowerBasicSeg06
    2D040H 3A27FH 0D240H PowerBasicSeg07
    3A280H 3C72FH 024B0H PowerBasicSeg08
    3C730H 3CE4FH 00720H PCL_DATA
    3CE50H 3DECFH 01080H PCL_TEXT
    3DED0H 3DEDFH 00010H _TEXT
    3DEE0H 3DEEFH 00010H _DATA
    4BE80H 4C53FH 006C0H LBSVGA
    4C540H 526DFH 061A0H LBSVGA2
    526E0H 526E0H 00000H VSEG
    526E0H 526EFH 00010H RSEG
    526F0H 54B4FH 02460H SSEG
    54B50H 6244FH 0D900H DATA

    When I place GLOBALS.BAS in the following place, with
    variable declarations uncommented, it works fine. Here's
    my declarations in the order that work.

    $DIM ALL
    $STACK 14000

    $include "c:\source\pb35\svgaprog\include\SVGAPB.BI"
    $link "c:\source\pb35\svgaprog\lib_pb35\SVGAPB.PBL"

    $LINK "PCL4PB2.OBJ" 'Interrupt driven serial port I/O

    $INCLUDE "GLOBALS.BAS" 'Global Variables DIM Statements
    $INCLUDE "SCR_DIMS.BAS" 'Screen variables DIM statements automatically
    $INCLUDE "DBG_DIMS.BAS" ' Debugging Dim Statements
    ' generated by Visual Basic form
    $INCLUDE "SCR_VARS.BAS" 'Screen definition variables automatically
    ' generated by Visual Basic form.
    $INCLUDE "DBG_VARS.BAS" ' Debugging Variables
    $INCLUDE "SCRNCLRS.BAS" 'Sets all the Screen Object's Colors
    $INCLUDE "DBG_CLRS.BAS" 'Sets all the debug screen object's colors

    $INCLUDE "XMEM.BAS" 'Handles XMS Functions
    $INCLUDE "PCXPAL.BAS" '.PCX file handler and palette functions
    $INCLUDE "CORRECTI.BAS" 'Routines for applying correction factor
    ' and maps to raw data
    $INCLUDE "SCREEN.BAS" 'Screen Handler functions for labels,
    ' pictureboxes, etc.
    $INCLUDE "PC104PSWD.BAS" ' Verifies Password to enter PC104 Command Line
    $EVENT OFF ' Make sure UEVENT doesn't try to run when performing DIO
    ' as the Uevent routine uses DIO functions as well, and might
    ' get triggered in the middle of one of these routines,
    ' causing the result to be incorrect.

    $INCLUDE "QUEUE.BAS" 'Handles queueing of scan trigger positions
    $INCLUDE "DIO.BAS" 'Digital I/O code
    $INCLUDE "STATS.BAS" 'Computes the statistics for scans/event/roll
    $INCLUDE "PC7266.BAS" 'Code which deals with the PC7266 encoder board
    $INCLUDE "ISR.BAS" 'Interrupt Service Routines for triggering
    'print "Start"
    $INCLUDE "INIT.BAS" 'Initialized variables to known states
    $INCLUDE "MAINFUNC.BAS" 'Main User interface functions.
    $INCLUDE "PC104CMD.BAS" 'Processes keystrokes for PC104 Command line prompt.
    $INCLUDE "KEYPRESS.BAS" 'Processes keystrokes for various screens
    $INCLUDE "DUMMY.BAS" 'Produces Dummy data to store as scans (for testing)
    $INCLUDE "GLOBALS2.BAS" ' This is a test here.
    $INCLUDE "DISKIO.BAS" 'Anything Disk related--reading in data from
    ' Excel .csv file, reading playback data from
    $INCLUDE "DISKIO2.BAS" 'Anything Disk related--reading in data from
    $INCLUDE "UEVENT.BAS" 'UEvent code which executes 18.2 times per second
    $INCLUDE "PROCESS.BAS" 'Processes scan data that has come in.
    $INCLUDE "DEBUG.BAS" 'Shows Debug information, and also Scanner states
    ' on the bottom of all screens
    $INCLUDE "PROALARM.BAS" 'Profile Alarm code.

    The Segment locations and lengths are all the same as before.
    (I double checked this)

    I can not normally run with $ERROR ALL ON because of the size
    of the program (as I have to shell out to the command prompt to
    do DOS commands, and I have network drivers loaded as well to
    transfer data collected from the app to a networked drive).
    But I did compile it with $ERROR ALL ON to see what it would
    complain on for this version that doesn't run, since it doesn't
    seem to get very far at all before erroring out. Here's what
    I got this time.

    Error 244 at pgm-ctr: 335473
    244 is Missing library
    You excluded a library in the library stripping menu and you used
    a function in your program that is contained in that library.

    This address corresponds to this line:
    lbl_DecimetersPerRevolution.Caption = USING$("#.###",DecimetersPerRevolution(%T1))

    This isn't informative either, as when the program does start
    up correctly, this statement executes just fine.

    For now, I am simply $INCLUDE(ing) the new variables where they
    are show in the code above, so I can continue. But it still
    really bothers me that I am having to deal with these problems.

    Any more ideas?

    Thanks. I know this is a screwy/tough one.


    Leave a comment:

  • Mike Luther
    James ..

    You'll find my Email address below. If you like, you can reply to it
    and get a path started. I guarantee you are not alone from the replies
    to all this which are here inbound to it and from substantial discussion
    going back years here on at least some of what you post.

    I'd like to see the replies here from others before I post anything
    here in open reply. Just because I think that things are relevant based
    on what I can see here doesn't mean they are so. If there's been anything
    more found by someone else important, it's better to see what is offered
    here to from other posts are before anything else I post here.

    Looking on what is posted by others here, I'll offer you what all that
    seems important here over all this.. But let's get others to talk up
    before here, OK?

    Mike Luther
    [email protected]

    Leave a comment:

  • Joep van Steen
    What are the sizes for the segments?
    Do you compile with $Error all on?

    Kind regards,


    Leave a comment:

  • Guest's Avatar
    Guest started a topic PB 3.5 compiler weirdness woes.

    PB 3.5 compiler weirdness woes.

    I have a large application, 18000+ lines long. I've been
    fighting problems that I can not understand. It seems that
    when I move code around, or place a $SEGMENT compiler directive
    in a different place, the weirdness will disappear, at least
    for a while. I thought all of this was behind me and I could
    make code changes at will, without worrying about weird problems.
    But now, I have another problem occuring. I'd like to
    understand this.

    If I add 3 new variables to my large global declarations file,
    called "globals.bas", my application crashes before even getting
    started (with an error 5 at 393215). It won't even print the
    first print at the beginning of the program.

    If I comment out these 3 new variables, the program runs.

    If I put these 3 new variables in a new file called
    "globals2.bas", and $INCLUDE this after the $INCLUDE for
    "globals.bas", it crashes.

    Now this is what's really weird. If I comment out these 3 new
    variables, so that "globals2.bas" is essentially 3 comment lines,
    The program will crash as well.

    And if I comment out the $INCLUDE "globals2.bas", the program
    will run.

    The executable file size (call it "Executable A")
    when compiling with
    $INCLUDE "globals2.bas"
    (which is filled with three comment lines) is the same as when
    I compile (call this "Executable B") with
    '$INCLUDE "globals2.bas"

    This is to be expected. The actual compiled statements are the
    same. Yet the compiler code which is output is different.
    Executable A crashes, and Executable B runs.

    When looking at differences between the two executable files,
    with a binary file difference analyzer, there are NUMEROUS

    If I try to use the compiler to find address 393215, it can not
    find it. Interestingly enough, 393215 in hex is 5FFFF.

    I have assumed that I must be executing code inadvertently in one
    of my numerous $INCLUDE statements, so I have tried putting a
    print "start" between $INCLUDE sections to see if my code at
    least gets there, since my print statement at where I THINK
    is the beginning of my code does not execute. The print
    statement between $INCLUDEs does indeed print before giving
    me the error 5. But again, here is some weirdness.

    If I put the print after the last include before one particular
    $SEGMENT, I get the "start" message, then error 5. If I put
    the print after the $SEGMENT statement, Windows tells me I've
    executed an illegal instruction and terminates the application.
    If I put the print after the next $INCLUDE in the next
    $SEGEMENT, the program will run! Since when should a properly
    placed PRINT statement fix the ability of an application to run?

    Can ANYONE provide me with insight as to what I may be doing
    wrong to cause such weirdness? I am baffled. I can not
    apply traditional debugging techniques to these problems.

    Thanks in advance.