No announcement yet.

Question About OBJ Files

  • Filter
  • Time
  • Show
Clear All
new posts

  • 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.


  • #2
    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


    • #3
      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.



      • #4
        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]
        Mike Luther
        [email protected]