No announcement yet.

Linked units with shared variables

  • Filter
  • Time
  • Show
Clear All
new posts

  • Linked units with shared variables

    I have created a piece of general code that I want to use with other programs. First of all I'm curious if there's any difference between linking a compiled unit and including an uncompiled unit...

    Now I'm using some global variable in the unit, which should be accessible from the main program. I'm using the following method:
    In the unit the variable are declared with:
    EXTERNAL ScreenWidth, ScreenHeight
    EXTERNAL CurrentMode
    In the main program (or include file) I use:
    DIM ScreenWidth AS SHARED INTEGER, ScreenHeight AS INTEGER
    DIM CurrentMode AS SHARED BYTE
    PUBLIC ScreenWidth, ScreenHeight
    PUBLIC CurrentMode
    It seems that I can only use integer variables, since this causes an "Unresolved EXTERNAL" error 503 for CurrentMode.
    I'm also wondering how to share a small array like this:
    DIM Lmask(0 TO 3) AS SHARED BYTE

    In other words, I'm not getting anywhere with EXTERNAL in units...
    Could anyone tell me how to use it?

    Sebastian Groeneveld
    mailto:[email protected][email protected]</A>
    Sebastian Groeneveld
    mailto:[email protected][email protected]</A>

  • #2
    Sebastian, i converted my large all-in-one PB 3.5 program into several units right now and i had to share variables like you. This was my only experience in this kind of conversion so i can' t get deep into your question, but maybe i can note something that could be made different, who knows it affects your problem.

    - I used the same metod than you (DIM MyVar followed by PUBLIC MyVar) and this makes the SHARED clause unnecessary in the DIM statement. My feeling about the real world tells me that "unnecessary" often means "harmful", especially in programming languages, although it shouldn' t.

    - Instead of having EXTERNAL MyVar in the unit, you can have PUBLIC MyVar in the unit as well, the same than in the main. This allows you to have only one include file with DIMs and PUBLICs for these vars, and this same file can be $included both in the main and in the units that share these vars. I found it very more comfortable than EXTERNAL (that is good for units only), furthermore i wouldn' t bet my head on the assumption that this can' t result in a different exe.

    - About sharing arrays, i did it the same way than non-array vars, with very large VIRTUAL arrays and i really didn' t get any problem. I simply DIMmed ald PUBLICed the arrays in the same include file i was talking above, $included from the main and from the units. This worked as fine as a clock.

    The only further difference i can see between your situation and the mine is that i wasn' t sharing any BYTE variable ("just" integers, long, words, dwords, single, double, extended, fix-length strings, var-length strings). I don' t know why but i' m sure there isn' t to mind about BYTE type.

    Davide Vecchi
    [email protected]



    • #3
      About the difference between linking a compiled unit and including an uncompiled unit, the first one that comes to my mind is the size limit of the compiled code: if you $LINK A to B, it has to be A < 64 KB and B < 64 KB, while if you $INCLUDE B into A, it has to be (A+B) < 64 KB.

      Davide Vecchi
      [email protected]



      • #4
        Sorry, i' m diesel. Last and all but least, maybe you should DIM the vars in the unit, before EXTERNAL.

        Davide Vecchi
        [email protected]



        • #5
          Davide, thank you for your great help, it works great now
          Indeed I had to put the DIM statements in the unit as well (I was already wondering how type-checking was performed when compiling the unit).
          About the arrays... I had to use brackets in the PUBLIC and EXTERNAL statements, like EXTERNAL MyArray()
          I could only test this after I had solved the first error...

          One question remains:
          Does anyone know what the difference is between:
          1) Compiling code as unit and linking it from your main program
          2) Simply including the code in your main program

          The 64k problem Davide mentioned makes sense, but is easily solved using the $SEGMENT directive at the critical location...

          Note: If anyone is interested in (source of) Yet Another Graphics unit supporting VGA mode X, easy smooth scrolling and split screens, just mail me

          Sebastian Groeneveld
          mailto:[email protected][email protected]</A>
          Sebastian Groeneveld
          mailto:[email protected][email protected]</A>


          • #6
            Sebastian ..

            The use of an internal $SEGMENT deal to, in theory, break up the
            MAIN module appears to work, and does, until the code begins to
            offer troubles from the SCREEN color changes and so on I've
            described at length here and for which I've posted source that
            does cause the debugger and smash problems.

            What I have found, is that if you use the $SEGMENT deal to gain
            larger and larger sizes in MAIN, come time to handle de-bugging
            for errors which are produced in CALLed routines that may still
            be out of MAIN, you may have a VERY difficult time trying to
            single-step the program through to find them!

            Time and again, I've tried to resort to stuffing in a $SEGMENT
            to split up main during debugging. I've left it in there in
            compiled code. Then, if for whatever reason, it comes apart,
            my own experience is that you go nuts moving it around just
            trying to stablize the program to clean it up. Time and again,
            for whatever it may be worth here, I've wound up going back to
            any of these $SEGMENT deals in MAIN and doing whatever it takes
            to get enough of the code off into formal PBU's to reduce MAIN
            to under 64K in PowerBASIC for DOS.

            As well, a great deal of the load of debugging, seemed to go away
            when I added the EXIT FAR technique, irrespective of what is
            still wrong with the IDE on line syncronization during debugging.

            Others may not feel the way I do .. I get the feeling that part
            of all this is greatly dependent of what you are asking the code
            to do, and how complex the whole program becomes. A stair-stepped
            simple, but very, very long operational program, with little
            branching, is a very different task than trying to manage some 2500
            variable, over 700 of which are genuinely global and PUBLIC, and
            hundreds and hundreds of SUBS in other libraries.

            A clean - realtivly simple - stair-stepped program, might do very
            well with many $SEGMENT breaks in main, I would think.

            Mike Luther
            [email protected]
            Mike Luther
            mike.luther[email protected]