No announcement yet.

Question About OBJ Files

  • Filter
  • Time
  • Show
Clear All
new posts

  • Mike Luther
    Clay ..

    They can be called in nested fashion. Right or wrong I've done. I think
    what you are proposing. I log ago put the core level stuff in what I'll
    describe as my lowest level PBU(s). They are all bound into a single PBL.
    From there upward, collections of other PBU's go into PBL's. Work in them
    can call the lower level - lowest levels as needed. That greatly reduces
    the need for many different segments.

    One thought which I didn't understand until Lance was so kind as to point
    it out to me, was that I should be using the EXIT FAR technique. That so
    I could orchestrate the collapse of a program with an unresolved error into
    the MAIN module, where I could best ordinate work after a failure such as
    that. My life improved drasticly after that went into service.

    In planning the whole suite years ago, I reserved certain line numbers up into
    the 50,000 to 64,000 range so that I would always have hard numeric line
    numbers way off in the lowest levels of all this. In that way I am able to
    take advantage of PB's wonderful error trapping and reporting operations, even
    down into the lowest of nested levels of all this. Recall that a numeric line
    number doesn't have to exist for each line of code in respect to all this
    error work. But obiously, unless you leave some room for improvement and
    changes, you can get to a point where you need an intermediate line number
    and won't have the availability of it unless you jockey a lot of other ones
    around to make way for that new needed one.

    Look carefully at the ON LOCAL ERROR technique, combined with the EXIT FAR
    technique. That's been invaluable for me.

    The only other comment I'll may is one of these hocus pocus ones which always
    seem to get me in trouble, but I'll pass it along anyway. A rather substantial
    pocket of messages long ago and far away suggested that it might be smart to
    always configure UDT's so that the UDT falls out on a four byte boundary. Most
    of mine did by accident anyway. But just for the heck of it I modified the
    ones which did not so that they now do.

    My life has gotten a lot less frantic, especially as to tracing whatever mess
    of memory this and that malwhatever, ever since I did that. As far as I am
    concerned that little stunt has been worthwhile, even though it may not get
    much play from official quarters.

    Lastly, what I think was your previous technique is also one of mine. I reserve
    a special variable or two for use throughout the entire suite as a hand configured
    error trap trace pointer. I'll increment this pointer as needed as many of these
    nested procedures are called. If something does go wrong, and these variables are
    GLOBAL declared, I can often trace and prove the step points for things which leave
    no other way of tracing them due to memory failures, however this takes place.

    Mike Luther
    [email protected]

    Leave a comment:

  • Clay Clear
    Thanks, Tom. Unless it's already been done, do not put in my
    request for an increase. I guess I can live with the 16-segment
    limit. I'll just combine similar procedures into single OBJ files,
    and make a catchall general OBJ file for the rest.


    Leave a comment:

  • Tom Hanlin
    The number of $SEGMENT segments available is a function of the compiler.
    I will put in a request for an increase, but you might find it practical
    to simply rearrange your segment usage. Each segment can handle up to
    about 64K code so, even at half efficiency, 16 segments gives you access
    to (16 * 64K / 2) = 512K of code, which is about as much as you're going
    to be able to wedge into a DOS box, anyway.

    Tom Hanlin
    PowerBASIC Staff

    Leave a comment:

  • Clay Clear
    started a topic Question About OBJ Files

    Question About OBJ Files

    Is the 16-segment limit in PB/DOS executables a DOS thing, or
    is it a unilateral decision by the PB/DOS compiler? If it's the
    latter, is there any way to work around it within the PB/DOS
    EXE source files? Also, if it's the latter, may I suggest that
    in future releases, that this limit be greatly increased? The whole
    reason for these questions is that I had gone to a LOT of effort to convert
    95% of my PBU's to OBJ's. Well, when I finally came across the
    16-segment limit, I ended up REVERSING those 4 weeks of work, just
    so I did not have to worry about the problem again. However, I
    wish to return to porting some of my UNIT's back to OBJ's. Therefore,
    my reason for my question of whether there are any workarounds.

    Thank you very much for any replies.