Announcement

**Lance Edmonds** · 19 Aug 2001, 09:08 PM

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!

Thanks!

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

**Mike Luther** · 19 Aug 2001, 09:14 PM

Thanks, Lance ..

I'll do that..

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

**Paul O'Kane** · 20 Aug 2001, 11:54 AM

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.

------------------

**Mike Luther** · 20 Aug 2001, 02:21 PM

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]

**Barry Erick** · 20 Aug 2001, 03:40 PM

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.

------------------

**Mike Luther** · 20 Aug 2001, 06:23 PM

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).]

**Lance Edmonds** · 20 Aug 2001, 08:02 PM

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

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

**Mike Luther** · 22 Aug 2001, 12:47 PM

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
identical).

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

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

Cheers...

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

**Egbert Zijlema** · 23 Aug 2001, 02:38 AM

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>
www.basicguru.com/zijlema/

**Lance Edmonds** · 23 Aug 2001, 03:07 AM

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 www.powerbasic.com/support

I hope this helps!

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

**Don Ewald** · 23 Aug 2001, 06:40 AM

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>

**Lance Edmonds** · 23 Aug 2001, 07:17 AM

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

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

**Mike Luther** · 26 Aug 2001, 09:59 PM

Lance,

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).]

**Lance Edmonds** · 26 Aug 2001, 10:25 PM

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.

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

**Mike Luther** · 27 Aug 2001, 05:02 AM

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:

Code:

C:\ZLOG>MEM

    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:

Code:

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:

Code:

C:\ZLOG\DAYLOG.BAS
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]

**Tim Wisseman** · 27 Aug 2001, 02:11 PM

Mike,

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.

Tim

------------------

**Lance Edmonds** · 27 Aug 2001, 10:06 PM

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

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

**Mike Luther** · 28 Aug 2001, 07:11 AM

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.

Thanks

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

**Lance Edmonds** · 28 Aug 2001, 07:18 AM

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

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

Announcement

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

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

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment