No announcement yet.

Do different PB 3.5's for DOS produce different sized exe's?

  • Filter
  • Time
  • Show
Clear All
new posts

  • Do different PB 3.5's for DOS produce different sized exe's?

    Do the different releases of PB 3.5 for DOS produce different
    size executables for the same source, the same operating sustem,
    the same memory manager, and the exact same setup parameters
    or compiler parameters if you want to call them that?

    Here are two variations on the theme.

    PB EXE 350827 12-18-97 3:50a
    PB EXE 350603 12-16-97 3:50a

    It is my understanding that the 350827 byte size is a later
    version of the compiler. It appears, to initial research,
    that the executables produced from it are about 20 or 30 odd
    bytes larger in size than the smaller one.

    However that's not a positively known point. With many miles of
    travel required between sites to test this, it will be a week or
    so before I can absolutely synchronize the PB platform to double
    check the compiled executable size from site to site for debug

    This issue arises over trying to track down executable instabiliy
    on various boxes for test purposes for unhandled DOS exceptions
    that do not leave any trace data one can use for debugging with
    very large programs and main modules above 63K in size.

    Thank you ..

    Mike Luther
    [email protected]
    Mike Luther
    [email protected]

  • #2
    Yes, it is quite likely since the last few updates have effected change to the runtime library which is included in all compile EXE's, and will therefore affect their size to some small degree. Also, compiler changes may also mean slightly different compiled code is generated, so that too could affect the size of compiled EXE, PBC and PBU modules.

    Note that the current release is dated 12/19/97, so you may need to request an update from mailto:[email protected][email protected]</A>

    Please remember to include your serial number in your request!


    PowerBASIC Support
    mailto:[email protected][email protected]</A>
    mailto:[email protected]


    • #3
      Thanks, Lance ..

      I'll do that..

      Mike Luther
      [email protected]
      Mike Luther
      [email protected]


      • #4
        There's a simple reason (maybe more than 1) for PB 3.5 for DOS
        producing different size exe's - especially if it includes PBUs.
        Compile any unit in a given directory and note its size. Then
        compile the same unit in another directory (on the same computer)
        with a longer pathname - the PBU file will be larger.

        The EXE file size, in turn, varies according to the size of
        associated PBUs.



        • #5
          Thanks Paul..

          But the exact same PBU's are use, byte for byte. Further the exact
          same directory name and path are used, box for box. Lance has
          given the suggestion that the various versions of the compiler do
          in fact provide differeent executables from the same source.

          I think I need to be comparing apples to apples before this goes
          any further ..

          Mike Luther
          [email protected]
          Mike Luther
          [email protected]


          • #6
            the exe size depends on many things.. type of math package you use,
            debugging turned on or off, type of cpu selected, error checking
            bounds checking, com buffer or not, rest of the Lib's pulled in.



            • #7
              Yes, Barry ...

              and they are all EXACTLY the same .. precisely.

              They aren't now because the two instances of the actual PBC are
              different. The teest platform I needed was taken from the earlier
              version of the compiler, not the one that I had that produced the
              executable from my normal development box.

              I've done an OS/2 COMP which is a byte-for-byte comparison on the
              EXE files produced and I can tell you exactly at what offset in the
              executable the disparity and the EXTRA bytes or CHANGED bytes are.

              But again, until I can get to doing exactly what Lance asks and
              make absolutely sure we are seeing a difference in compiled size
              for what is exactly known to be the same thing, this isn't really
              a fair discussion ...

              other than what you and others bring up as can contribute
              to differences in compiled executables.

              What you posted is totally correct and fair ...

              Mike Luther
              [email protected]

              [This message has been edited by Mike Luther (edited August 20, 2001).]
              Mike Luther
              [email protected]


              • #8
                Mike, just be aware that the compiled disk image (EXE file) may contain some abitrary differences in byte _values_ between two successive compiles with the same compiler version - this is nothing to be alarmed about as these bytes typically consititute "uninitialized data" and this is quite normal.

                However, the absolute length of the compiled file should be identical when compiled with the same compiler version (and obviously providing that the RTL libraries selected are identical).

                PowerBASIC Support
                mailto:[email protected][email protected]</A>
                mailto:[email protected]


                • #9
                  Thank you Lance ..

                  Version -19 is in house and has been used to update the entire suite
                  of 120 active libaries and executables for test purposes.

                  Mike, just be aware that the compiled disk image (EXE file) may
                  contain some abitrary differences in byte _values_ between two
                  successive compiles with the same compiler version - this is
                  nothing to be alarmed about as these bytes typically consititute
                  "uninitialized data" and this is quite normal.
                  As a matter of fact .. a random sample of two passes at this shoes
                  absoutely no difference in byte comparisons between executables
                  produced in a sequential auto-comple run for the entire suite.

                  Hold that thought for a moment, please!

                  However, the absolute length of the compiled file should be
                  identical when compiled with the same compiler version (and
                  obviously providing that the RTL libraries selected are
                  Of interest, the total suite compile run between verions 18 of
                  the compile and version 19 produces *EXACTLY* the same byte
                  size executable files for every single one of the executables
                  and modules now spanning over 24 MB of operational code an
                  about 1,140,000 line of PB source..

                  Interestingly a COMP byte analysis run in native OS/2 shows
                  two things of interest.

                  Every single library module produced in the multiple pass sweep
                  produces a byte for exact byte .PBU file between these two
                  compiler products .. (at least PBC, which is used in the sweep
                  of the suite!).

                  That, I think is critically important to note. It tells us that
                  whatever goes right - or wrong - in this case, is going to be
                  exactly the same as to any dependency on .PBU's created by either
                  of the two versions of the toolset.

                  I've checked a fiar number of the executables and actually looked
                  inside them byte wise as well..

                  For those, every single executable produced by either -18 or -19 has
                  byte differences in the executables, viz a viz -18 vs. -19, despite
                  the fact that the entire collage for all of them ... is precisely
                  the same size file for file!

                  Don't ask about operational results .. grin. Nor, about site to
                  site possible differences as I won't get to the other site that
                  started this question until Sunday night local time.

                  Nor have I any experience at all with -19 as to any difference it
                  may or may not make as to DEBUG line sync or 611-type errors at

                  However, in that respect, I feel *MUCH* better, emotionally, now,
                  knowing that at least the LIBRARY units appear to be stable for
                  whatever they are going to be ..

                  It is *NOT* fun chasing instability issues no matter why they take
                  place in any large suite. Knowing that the version difference has
                  little chance of variation in the libraries is a very comforting
                  thing to contemplate ...


                  Mike Luther
                  [email protected]
                  Mike Luther
                  [email protected]


                  • #10
                    Originally posted by Lance Edmonds:
                    Note that the current release is dated 12/19/97, so you may need to request an update ..........

                    Mine is dated 12/14/97. Is it a pre-release, perhaps?

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

                    Egbert Zijlema, journalist and programmer (zijlema at basicguru dot eu)
                    *** Opinions expressed here are not necessarily untrue ***


                    • #11
                      Nope, you just do not have the most recent update... IIRC, the initial PB3.5 release would have been dated 12/01/97 where the 01 portion signified the 1st release version.

                      To update your compiler, send your request for an update to mailto:[email protected][email protected]</A>

                      Please remember to include your serial number in your request.

                      Also, you can check the current version of all PowerBASIC products by the date stamps listed on the Support page of the web site at

                      I hope this helps!

                      PowerBASIC Support
                      mailto:[email protected][email protected]</A>
                      mailto:[email protected]


                      • #12
                        Greetings All!

                        I took the advice of Lance last week and sent a message to Sales and they hooked me up with the latest version.

                        I didn't have any problems with the version I owned; but, I figured I'd take it for kicks. Little did I know that I would receive an added boon. The archive that I downloaded also includes the User's Guide and Reference in Acrobat PDF form.

                        Kudos to PowerBasic for providing such a useful tool in allowing me to conduct searches on text and such.

                        Don Ewald
                        mailto:[email protected][email protected]</A>
                        Donnie Ewald
                        [email protected]


                        • #13
                          We aim to please, and we are sure happy to hear you are happy with the update.

                          PowerBASIC Support
                          mailto:[email protected][email protected]</A>
                          mailto:[email protected]


                          • #14

                            I'm now in possession of some more very interesting data on this issue
                            of same sized executables produced by the same version of the compiler,
                            that are not the same. I have, at least here, a real belief that there
                            really is something not well known about what that 'uninitialized data'
                            is capable of doing. DAYLOG.EXE is a large source file multiple .PBU
                            PB 3.5 compiled executable. The executable from the development box
                            fails totally with an OS/2 SYS3170 error. It fails after the entire
                            program is loaded, is executed, has initialized the COMM port, has opened
                            all the normal files, and is beginning a log entry after checking the
                            existing log file for the previous data for a given site response.
                            This error is an "Unhandled DOS Raise Exception" error. Interestingly,
                            a compile run on the remote site box from exactly the same platform,
                            with only one difference that I can determine, produces a perfectly
                            good running and functioning executable, that not only works there, but
                            works elsewhere too, when the development box compiled code does not!

                            Consider the following data:

                            DAYLOG EXE 344557 8-27-01 3:17a Built by remote site box Try 1
                            DAYLOG NEW 344557 8-27-01 3:30a Built by remote site box Try 2
                            DAYLOG NOW 344557 8-22-01 7:13p Built by development box "X"
                            DAYLOG DIF 1266 8-27-01 3:21a OS/2 Byte compare Try1 to "X"
                            DAYLOG DI1 1266 8-27-01 3:34a OS/2 Byte compare Try2 to "X"

                            DIF and DI1 are exactly the same. Hold that thought for a moment.

                            Compare file C:daylog.EXE and file C AYLOG.NOW.

                            A COMPARE error occurred at OFFSET 14BE
                            Mismatching byte of file 1 = 6E

                            Mismatching byte of file 2 = FD

                            A COMPARE error occurred at OFFSET 14BF
                            Mismatching byte of file 1 = 4

                            Mismatching byte of file 2 = 10

                            A COMPARE error occurred at OFFSET 14C2
                            Mismatching byte of file 1 = D8

                            Mismatching byte of file 2 = 22

                            A COMPARE error occurred at OFFSET 14C3
                            Mismatching byte of file 1 = 13

                            Mismatching byte of file 2 = 11

                            A COMPARE error occurred at OFFSET 14D4
                            Mismatching byte of file 1 = 64

                            Mismatching byte of file 2 = 27

                            A COMPARE error occurred at OFFSET 14D5
                            Mismatching byte of file 1 = 1

                            Mismatching byte of file 2 = 2

                            A COMPARE error occurred at OFFSET 14D6
                            Mismatching byte of file 1 = 64

                            Mismatching byte of file 2 = 27

                            A COMPARE error occurred at OFFSET 14D7
                            Mismatching byte of file 1 = 1

                            Mismatching byte of file 2 = 2

                            A COMPARE error occurred at OFFSET 12B30
                            Mismatching byte of file 1 = D

                            Mismatching byte of file 2 = 0

                            A COMPARE error occurred at OFFSET 12B31
                            Mismatching byte of file 1 = 73

                            Mismatching byte of file 2 = 15

                            There were 10 or more mismatches in comparing
                            the files. The system is ending the COMPARE command.

                            Now, lets make sure I've stated the compile forum correctly. Each
                            box has precisely the same:

                            Operating system,
                            Version Level,
                            Fixpack level,
                            All device drivers, except one variance in devices,
                            Memory level and upper memory handling,
                            Hard disk general size and type,
                            Precisely the same exact path,
                            Precisely the same environment SET variables,
                            Precisely the same cache and video modes,
                            The EXACT same PB files, including all .CFG's (They byte compare.),
                            The EXACT same source and library files. (They byte compare.),
                            Exactly the same allotted upper memory for each DO-VDM session,
                            Exactly the same DOS-VDM session setting options for everything,
                            Exactly the same CONFIG.SYS file for the critical things here,
                            Precisely the same AUTOEXEC.BAT file for the tests done,
                            Precisely the same memory is reported available for each,
                            Cache and available memory do *NOT* change during compile or load,

                            We have reasonable proof that nothing is thus changing in the memory
                            footprint such as being brought in and out of cache during the tests.

                            There are two significant differences in the boxes. One box has a
                            very early 95Mhz Pentium which has the known F0 Bug in it and driver
                            to suppress any error calls to that register. The other has a later
                            much faster non-affected Intel Pentium. The remote site box also
                            has a Logitec Buss Mouse on a lower IRQ, as opposed to a Logitec
                            RF serial mouse. The differences in the actual driver load and memory
                            locations result in 6K less main memory at the remote site than the
                            general development box. In that the program is mouse enabled, that
                            might make a difference as to something relative to that port, but
                            really, shouldn't, I would expect, cause this.

                            The *ONLY* difference in the code is the difference in those bytes
                            you note are 'uninitialized data.'

                            It is exactly this same sort of thing that completely dishevels client
                            boxes, at times, in these very large programs, where simply changing
                            from a single line form of an IF/THEN statement from a multi-line
                            form of it with a formal END IF will break this, for example.

                            I'd like to know just what 'uninitialized data' means. It's obvious to
                            me from what is happening that I now have solid evidence of here at
                            my end, that something that is thought to be 'uninitialized data', has
                            to be germane to how this happens.

                            I offer you one thought, based on long experience. OS/2 in creating
                            the memory space for the object which becomes your DOS-VDM session,
                            does NOT, to my knowledge, clear that memory block and set it to null
                            on creation of the object. That's based on my experience that if you
                            use the old Norton DOS virus scan tools, and find a virus in a file,
                            a very interesting thing happens! Close down that DOS-VDM session and
                            immediately re-open it, and attempt to run SCAN again. You'll find that
                            SCAN will find fragments of the signature file in memory left over from
                            the cleaning operation previously! It will usually be the signature
                            fragment from not the virus you found, but the one on either side of it
                            in the signature list!

                            Thus, to YOU folks, it may be 'uninitialized data.' But to the BOX, it
                            may well look like continuation of code that produces a wrong execution
                            during run time, in my humble thought.

                            Two other things are important. First, I changed the memory footprint
                            between TRY #1 and TRY#2 to make sure we had a fresh, but same size block.
                            I forced OS/2 to assign different memory and hopefully disk space, by
                            doing a number of other things between TRY #1 and TRY #2 as well, It
                            made no difference in the 'uninitialized data', as the DIF file shows.

                            But, the biggest thing of all relative to this is that I simply CANNOT tell
                            you anything about exactly where this fails.

                            The entire PBD debugger doesn't properly handle COMM routines in it.
                            Thus again, because the tool set doesn't work, I'm trapped. I can't
                            even find out what line in the code evokes the exception error!

                            Where do we go now? I'm still waiting for any communication as to what
                            is know about any of this at all.

                            Mike Luther
                            [email protected]

                            [This message has been edited by Mike Luther (edited August 26, 2001).]
                            Mike Luther
                            [email protected]


                            • #15
                              The "uninitialized data" is exactly that... arbitrary values at points in the disk image that either become initialized during app load/initialization (ie, for internal variables, etc), or are simply arbitrary bytes added for padding/alignment and are never actually executed.

                              However, one point: you have noted that these two boxes have slightly different levels of conventional memory available, right? That means that the compiler is much more likely to need to use EMS/XMS during the compile on the box with the lower memory spec. Herein lies a potential problem if the memory manager is not performing 100% since the compiler gives the memory manager a <U>real</U> workout.

                              Beyond that, you'd need to discuss the matter with R&D and Bob Zale. Basically (no pun intended), you are getting to depths are beyond the scope of Tech Support...

                              You can contact Bob directly via [email][email protected][/mail], but please be sure to include all the evidence and source code necessary for R&D to be able to duplicate the problem.

                              PowerBASIC Support
                              mailto:[email protected][email protected]</A>
                              mailto:[email protected]


                              • #16
                                Lance, the likelihood of the smaller one requiring significant use of
                                of upper memory is very, very small. Each box has approximately this
                                with which to work:

                                    752640 bytes total memory
                                    752640 bytes available for DOS
                                    682448 largest executable program size
                                   8781824 bytes total EMS memory
                                   8388608 bytes free EMS memory
                                   4128768 bytes total XMS memory
                                   4128768 bytes available XMS memory
                                         0 bytes available contiguous extended memory
                                           DOS resident in High Memory Area
                                           High Memory Area in use
                                I had to dispose of TSR's in upper memory in years gone by that I didn't
                                write, but needed to shoot in the foot. So I used a small utility that
                                would let you create a pointer in memory to just prior to the load of
                                that TSR, Later you could return to that pointer and actually dispose
                                of the effects of the TSR. It was used for voice/fax/data on the same
                                phone line after three different TSR applications had done their job
                                as needed for the calls a long time ago. The memory analysis tool from
                                that tool set shows the following for the development box:

                                MAPMEM 3.5, Copyright 1993 TurboPower Software
                                Psp  Cnt   Size Name       Command Line   Hooked Vectors
                                ---- --- ------ ---------- -------------- ----------------------------
                                023C  2   5,232 COMMAND                   22 23 24 2E E0
                                      1     192 ---free---
                                      1     544 ---free---
                                03B5  1     336 OSTSR      n/a            2F
                                03CB  1   2,336 TAME       n/a            10 14 16 17 21 28 EE
                                045E  1  51,680 PMSWITCH   n/a            15 CC CF D0 D6 DA DE E3 EB F9
                                                                          FC FD FF
                                      1   3,472 ---free---
                                1122  2 679,536 ---free---
                                        743,488 ---total--
                                The PBC compiler notes the following:

                                15851 statements, 18192 lines
                                Compile time: 00:04.3 Compilation speed: 253800 lines/minute
                                233776 bytes code, 16512 bytes data, 2048 bytes stack
                                Segments(11): 37k/1k/1k/7k/41k/9k/21k/58k/34k/15k/13k

                                The smaller memory footprint is only about 678K instead of 682K free in
                                main memory. It would be very interesting to see the smaller one is
                                working out the EMS in any horribly different way than the larger one!
                                However, as we both know, all it takes is one bite for disaster! I
                                actually had a cousin who graduated from Texas A&M as a vet, got bit on
                                the first week on the job, died from the shots and the dog recovered,
                                but that's a long time ago. Pity; there were only, IIRC, seven graduates
                                from vet school here in 1942, his class picture out there is very small.

                                In fairness to you folks, I need to run the MAPMEM at the remote site
                                and check to make sure we are duplicating the footprint as accurately as
                                possible. If I can prove that altering the development box to match the
                                remote box makes a difference, it will be very important to know which
                                witch is hawking Halloween early this year. I have no interest in anyone
                                taking shots and the problem not being real. I would be extremely happy
                                to find this is a privy problem we can each do without.

                                There is a core level change in keyboard I/O master library that will have
                                to be made to accommodate a new exit format for grunged date entry formats
                                early this next week. I busted it in moving to the W/S type keyboard
                                entry operations and it got caught! It will change virtually every single
                                module in the above and every single one of the 120 executables when it
                                is made. Thus we will likely loose the focus on this the instant that is
                                made, if my experience at all this is correct. But we might get lucky and
                                can freeze it. I'll make the needed drive back to that remote site to
                                get the data to prove this up before we think about what else to do before
                                I make the master library changes. If a loader profile is the difference,
                                and I can change it here to cure this, then I'll have to go back out the
                                second time to research it to prove it.

                                But as this family's found out a long time ago; in for a penny, in for a
                                pound. At least you can't say we all haven't done our very best. This
                                is not, as you know, an easy job.

                                Mike Luther
                                [email protected]
                                Mike Luther
                                [email protected]


                                • #17

                                  Your problem reminds me of a problem I was having
                                  with the windows versions of the Power Basic compiler back
                                  in 1999.

                                  I would compile the same source file over and over again
                                  and I would get different sized EXE files and slightly different
                                  values in the EXE.

                                  The bad values would lead to random crashes.

                                  The problem was caused by arrays in UDT. Once I
                                  removed the arrays from my UDT's the problems completely
                                  vanished and my programs have been 100% stable every since.




                                  • #18
                                    I'm 99.999% sure the problems Timm refers to (arrays within a UDT) were fixed many builds ago, which would make sense if the problems were encountered in 1999. There have been quite a few updates to the compiler since 1999.

                                    Thanks for the suggestion though...

                                    PowerBASIC Support
                                    mailto:[email protected][email protected]</A>
                                    mailto:[email protected]


                                    • #19
                                      Lance ..

                                      As a suggestion, it would be *SO* helpful if PowerBASIC would just
                                      post a complete list of what was found to be a problem when they
                                      make a change in a tool and create a fix or new version.

                                      Over and over I see discussions which take on a 'past life' here
                                      for things that are perceived to be problems and may (or may not!)
                                      have been 'fixed' or thought to be fixed.

                                      There are two sides to this story, emotionally and professionally
                                      from a management standpoint. One way to look at not divulging what
                                      may have been wrong but what was found and 'fixed' or 'changed' says
                                      that, 'If nobody knows, I have less risk of being taken to the cleaners!'
                                      The other side of that is, "If everyone knows, I have less risk of
                                      being taken to the cleaners! At least there is evidence in public
                                      that I did my best." In my view, your clients pick up on that.

                                      I fall back to OS/2 for an example. Now I may not like how IBM has
                                      handled this or that in respect to it. The 16 times open and smash
                                      Netscape rpoblem that was finally after years, linked to a table
                                      over-run in the base OS/2 code is a good example of, "Gee guys,
                                      we've told you and told you ... gloom." But on the other side of
                                      this with IBM, just look at the APAR's published as found and fixed!
                                      We're closing in on what, sequence numbers of 34,000 plus now? So
                                      I walk away thinking, well, look what they did already find and fix!
                                      You know, even simple things like a table over-run here and that
                                      exactly same sort table over-run for your other guy's problem with
                                      a driver that was involved in the WIN arena are examples! You
                                      go away thinking, "Well, some things are like that!" And everyone,
                                      mostly, grin, smiles over the deal and forgets it!

                                      That's sobering. What's important about that is simple. IBM does
                                      have, and does *PUBLISH* what is fixed and has been taken care of
                                      in every single fixpack and re-issue of a particular product. You
                                      can research and search every single issue in the database and get
                                      pointers to at least the fixed issues. Thousands and thousands of ]
                                      them, Lance.

                                      I still hold the position that most all prograams have bugs. I
                                      really doubt that very many folks who use PowerBASIC have any idea
                                      at all how complex even simple functions which most users just take
                                      for granted. Robert Traister wrote an excellent overviewistic
                                      'tutorial', in my view, called, "Leaping from BASIC to C++", you
                                      can find as ISBN 0-12697421-7. I quote from Page 19 as one of my
                                      best recalled points, "The C++ program appears to be very compact
                                      and simple. This belies its complexity. Writing to the cout stream
                                      is a very detailed operation thata requires lengthy code." . ...

                                      What then follows is pages 20, 21, 22, 23, 24, 25, 26, 27, 28, 29
                                      30, 31, 32, 33 and 34; which is what the compiler 'sees' when you
                                      ask to simply .. in our world .. somewhat to say .. PRINT (USING).

                                      Yeah, thousands of lines of code just to print to the screen!

                                      Until you have tried to leap from what we here with PowerBASIC take
                                      so as ho hum, like PRINT USING, or DIM A$(25, 50) into an array into
                                      a UDT into C or C++, for example, you will have no real respect for
                                      what Gordon Letwin, Bob Zale and a few others have really done for
                                      a programmer. The work is awesome and it is filled with pitfalls.

                                      The College Board here in the USA decided to abandon C++ in favor
                                      of JAVA as a standard language for all college prefessionals as
                                      rapidly as possible! One of the major reasons cited is that there
                                      has never been an acceptable solution to array corruption in C/C++
                                      that has ever been practical to implement in that language! Never
                                      mind what comes out of the sand box. Pay closer attention to what
                                      Microsoft wants from C#, folks. A more automated way of resolving
                                      the corruption problems and buffer over-runs in C/C++, but which,
                                      as I recall, they claim, "This will be beyond the ability of lower
                                      level Visual Basic Programmers."

                                      Sound familiar?

                                      Thank you Bob Zale for your contribution and efforts, with all our
                                      hearts .. signed, your users.

                                      And .. what follows is *NOT* in criticism of you or the product, OK?
                                      It's a genuine attempt for me, a very low level user and awareness
                                      person, to deal with what is far more complex than I can now understand
                                      here, Sir.

                                      This issue of problems with arrays inside UDT's in PowerBASIC, if my
                                      memory is correct, and what errors may leap upon us if they do or do
                                      not fall out on exact divisible by two length UDT's, and how they may
                                      or may not relate to SUB's and so on, has been going on here for
                                      at least two years that I know about. And of course the divide by
                                      two game, or divide by four game, is fine if what is inside the UDT
                                      is, as I see it, A%(2, 4) or B&(3, 6, 2). But if DIM C as STRING * 13
                                      is involved, or worse, a two dimension array of that, and what to do
                                      with that, to my wonderment, just where do we blow up if we really need
                                      to wind up on an even 2 or 4 byte boundary for a UDT. Do we have to?

                                      I know my code suddenly took a great improvement in reliability, for
                                      some reason, when I went in and made sure every UDT was, in
                                      theory, divisible in size by two. ?

                                      More than my inquiring mind wants to know per a sizeable Email base
                                      to me over it.

                                      As well, the argument that we shouldn't error trap in UDT's has been
                                      made too, in that the overhead and speed burden is just too much
                                      for the product line has also been made, if my recall is correct.
                                      Fine, so where do we go when this DOES produce and error, and worse
                                      yet, we over-run code that collapses the entire task in a multi-session
                                      operating system with the "Unhandled DOS Raise Exception Error" that
                                      then appears to result? Plus you can't single step the code in
                                      the PBD accurately, line by line, to trace exactly where we go
                                      over the edge for line sync problems? Of course, recall it's
                                      happening in these arrays within UDT's, right?

                                      So, more than one person has noted, make pointers of your arrays! For
                                      .ultiple dimension string data as well, across nested library modules
                                      too? Try that one in C++ if you like, yourself, before you criticise
                                      Bob Zale and PowerBASIC over his treatment of these issues. I think
                                      the buzz word for this in the C (Sea of whatever!) trade is now called
                                      a Vector Class? Coleridge was correct in the Ancient Mariner, "A
                                      sadder but a wise man he rose the morrow morn."

                                      Neither I, nor Tim, nor the relatively few others that have seen
                                      and daily face this problem can really go forward unless we have
                                      access to more of what either has or has not been done in the shop
                                      to find this. And the potential for damage in the released code
                                      that is used by our clients can be serious. It would help in my
                                      personal view, if we could point to work which has been done to
                                      find it and what is really known of that. But that's just one kid's
                                      view of the marble court.

                                      It isn't that I don't want the help. I also have to be educated
                                      on how to interact with the fix-me arena to help. And that
                                      includes a fair display of what has been found and known, even
                                      if the shop can't explain it. Maybe one of us can, if that
                                      were know. Every pig finds an acorn once and a while

                                      No Lance, what we really need from PowerBASIC, in my humble view,
                                      is a meaningful database and publicly available roster of what has
                                      been done with what was FIXED in these tools, version by version.

                                      As well, we need a confirmation receipt of what happens to what was
                                      sent in to PowerBASIC and what became of it. Yes, every one. I know
                                      you folks do have a record of some kind.


                                      Mike Luther
                                      [email protected]
                                      Mike Luther
                                      [email protected]


                                      • #20
                                        Mike, such lists have never been published or released by R&D... sorry!

                                        PowerBASIC Support
                                        mailto:[email protected][email protected]</A>
                                        mailto:[email protected]