recompiling yields broken exe 
Author Message
 recompiling yields broken exe

I have an application that I've recompiled, after several months of the
source code just sitting, untouched and unchanged, on my development system.

Several strange things have occurred, for which I cannot account.

1) The newly compiled exe is smaller, by about 6K (the whole exe is about
1.3 meg.)

2) The newly compiled (smaller) exe, still runs on the development machine,
but when I copy it to another machine, on which the overall application is
already installed (formerly installed, with a full install routine, which
included the older exe, which is 6K bigger), the new exe won't run.  It
begins to start, and I get a message "Unspecified Error", with a red X, in a
little msgbox that has nothing in its title bar.

Now, here's the rub.

The source code itself, is absolutely the same.  It has just sat there on
the machine, untouched, in its own directory tree, since the original
compile (which created the 6K larger exe.)

Also, no additional service packs were installed to VB.  I am running the
same physical instance of VB -- the same compiler --, on the same source
code, but now get this different result.

No OS changes either.  Same OS version (though I have installed some
"Windows Update patches, little things like date format and so on, along the
way.)

The compilation process itself runs completely smoothly and flawlessly.  It
always runs without a hitch, no errors or warnings, and always NOW produces
the same, newly-sized, EXE.

And again, this exe still runs, despite its smaller size, on the development
machine.

I can exit VB, cold-start the system (so development components are cleared
from memory), and run either EXE from a different directory on a different
logical drive on this system, and they both work.

The only difference is the unexplained change in size, AND the fact that
when I copy the smaller exe to a DIFFERENT machine, on which the compiled
and installed application already resides (and works fine), then this other
installed instance (on the other machine), breaks.

In other words, I can intersubstitute the exe's on the development machine,
but not on other machines.

I am really stumped.  I have checked the source code again and again.  It's
a bit project, and I have made several archive copies of all the source
files.  I have used all of them, all have the original date and time stamps,
and file sizes unchanged.  So the ARE the original code.

Why now the different exe size? (compiling to P-code in both instances --
the original and the newly smaller case, no options changed that I can find
in the IDE).

And, why would the new exe still run on the development machine, but not on
other machines?

I am getting a little out of my depth here, but I am wondering whether the
following might have happened.

I have, in the intervening time between the first compilation, and the new
ones now, installed a number of random applications on the machine.  No
development stuff, but a new browser (moved from IE 4.x to 5.5 SP1), and
some other applications that of course distribute all kinds of files.

I am wondering if perhaps one or more of the other applications I have
installed might have installed and upgraded control, ActiveX or other
component, and changed something in maybe an internal binary class def or a
GUID.

If this happened, is it possible that VB is reading some of this (possibly
changed?) internal info, when it "Makes" the new exe... and might this
result in an new exe that still works on the development machine, but cannot
be transported to other machines, on which the full application (the
original exe, and all the DLLs and controls and components were installed)?

This is a little out of my depth here, and is only a guess.  But I am
grasping at straws.

It's a large, complex application, that uses the jet, and also makes calls
to com automation server objects (excel objects, for example), and has lots
of controls and forms.

But why the recompilation should produced a changed exe, stumps me.  And why
this exe runs on the development system, but cannot be replacement copied
onto other systems where the full application runs, is my main question.

And what to do?

Any comments would be appreciated
thanks,
David



Tue, 07 Sep 2004 22:34:41 GMT  
 recompiling yields broken exe
I think you're on the right track: you must have upgraded some critical OS
component (the OLE dlls oleaut32 and olepro32 are the first things that come
to mind), and the new exe is dependent on having these newer versions.  I
use a "clean compile" machine, dedicated to compiling VB apps: NOTHING is
ever installed or upgraded on that machine without thorough investigation
first and testing after.

Jim Deutch
MS Dev MVP

Quote:
> I have an application that I've recompiled, after several months of the
> source code just sitting, untouched and unchanged, on my development

system.


Wed, 08 Sep 2004 01:12:06 GMT  
 recompiling yields broken exe
Hi Jim,

Thanks for the reply.

On your tip I started with oleaut32, did a Find Files and found three copies
on my development machine.

There's indeed a newer one in Windows\system, which is different from the
older version my setup program has distributed.

However, in the VB setupwiz kitfiles directory, is the older version (and
the same one my setup program distributes.

If I rerun setup wizard to generate a new setup application, will setup wiz
gather references to the all the newer versions of files that, it appears,
the compiler is compiling into the exe?

Of course in kitfiles, I could make a manual change before regenerating a
setup routine, if I need to, but the question is more systemic, because I
cannot presume that the file I found, is the only one.  I have a zillion Jet
DLL's, control libraries, and so on, in the application.  It would be a
nightmare trying to check all of them manually against setup.lst.

Is setup wiz good enough to catch and synch this kind of thing?  (When I did
the development work, and created the setup routine the first time around,
it *was* a clean machine, in the sense you described in your note.  Hence, I
cannot infer too much from the fact that *that* setup routine exhibited
synchrony and worked perfectly; there was no upgrade history of dlls on the
machine that would have needed to be resolved.)

I might say that this questiuon applies to vb5, sp3.  It has worked fine
thus far for maintaining this large application, so it's stil the one I use
to make incremental fixes.

Thanks,
David

Quote:
>I think you're on the right track: you must have upgraded some critical OS
>component (the OLE dlls oleaut32 and olepro32 are the first things that
come
>to mind), and the new exe is dependent on having these newer versions.  I
>use a "clean compile" machine, dedicated to compiling VB apps: NOTHING is
>ever installed or upgraded on that machine without thorough investigation
>first and testing after.

>Jim Deutch
>MS Dev MVP


>> I have an application that I've recompiled, after several months of the
>> source code just sitting, untouched and unchanged, on my development
>system.



Wed, 08 Sep 2004 23:14:47 GMT  
 recompiling yields broken exe
David,

I've been facing an almost identical problem on my machine - so can save you
time by letting you know that the setup wizard will not find the correct
version of the files. Furthermore, I'm not entirely sure what MS's policy is
on replacing files in the "Redist" section of their dev products with newer
versions installed by app's such as IE6.

The app I'm working on builds and runs successfully on some machines and not
others. Do not assume that because it runs on the 2 machines your currently
trying to get working it will do so on all others. You will need to do
thorough testing on a whole number of machines, and then assume it will
still fail on others.

Does anyone out there no any way around these problems. Currently it looks
like I may have to rewrite my entire app in C++ as I'm beginning to give up
on this....

Rob


Quote:
> Hi Jim,

> Thanks for the reply.

> On your tip I started with oleaut32, did a Find Files and found three
copies
> on my development machine.

> There's indeed a newer one in Windows\system, which is different from the
> older version my setup program has distributed.

> However, in the VB setupwiz kitfiles directory, is the older version (and
> the same one my setup program distributes.

> If I rerun setup wizard to generate a new setup application, will setup
wiz
> gather references to the all the newer versions of files that, it appears,
> the compiler is compiling into the exe?

> Of course in kitfiles, I could make a manual change before regenerating a
> setup routine, if I need to, but the question is more systemic, because I
> cannot presume that the file I found, is the only one.  I have a zillion
Jet
> DLL's, control libraries, and so on, in the application.  It would be a
> nightmare trying to check all of them manually against setup.lst.

> Is setup wiz good enough to catch and synch this kind of thing?  (When I d
id
> the development work, and created the setup routine the first time around,
> it *was* a clean machine, in the sense you described in your note.  Hence,
I
> cannot infer too much from the fact that *that* setup routine exhibited
> synchrony and worked perfectly; there was no upgrade history of dlls on
the
> machine that would have needed to be resolved.)

> I might say that this questiuon applies to vb5, sp3.  It has worked fine
> thus far for maintaining this large application, so it's stil the one I
use
> to make incremental fixes.

> Thanks,
> David

> >I think you're on the right track: you must have upgraded some critical
OS
> >component (the OLE dlls oleaut32 and olepro32 are the first things that
> come
> >to mind), and the new exe is dependent on having these newer versions.  I
> >use a "clean compile" machine, dedicated to compiling VB apps: NOTHING is
> >ever installed or upgraded on that machine without thorough investigation
> >first and testing after.

> >Jim Deutch
> >MS Dev MVP


> >> I have an application that I've recompiled, after several months of the
> >> source code just sitting, untouched and unchanged, on my development
> >system.



Fri, 10 Sep 2004 18:52:39 GMT  
 recompiling yields broken exe
Rob,

Have you had any better success with third party installation generation
products?

Assuming our problem is that VB is now compiling-in type or class
information from later, changed DLL's , would a different install generator
catch this and fetch the right versions?

Anyone else had to resolve this?

David



Fri, 10 Sep 2004 23:38:00 GMT  
 recompiling yields broken exe
Rob,

Might the solution here be to recompile the app on a machine with the
*oldest* versions of the dll's, then?

OF course we have to find such a machine, or configure one.  BUt the
compatibility issue -- I'll speak for my own case in this instance, don't
know if it is the same for you -- seems to be running an exe compiled in the
presence of newer dll's, on machines where the older dll's are installed.

The converse is not also true.  My older exe has run fine on machines with
the newer dll's installed.

So (at least for me) the choice is to either locate and distribute the newer
dll's myself (the problem being that setup wiz can't help with that, and
even if I can hand check every file found in setup.lst and locate the newer
version, I'll also have to compress these newer ones myself, in addition to
hand edicitn setup.lst),

OR..

 move the compiler to a clean machine with only older dll's installed,
recompile and generate a setup program in that envionment, distribute the
latter, and count on the fact that newer dll's on field machines generally
support older interfaces. (OF course ensuring also in our setup routine, as
is normally one's obligation, that older dll's will not overwrite newer ones
on field machines.)

In short, the irony would be if the solution is to find *old* dll's and
compile and distrubute those, huh?

David

Quote:

>>The app I'm working on builds and runs successfully on some machines and
not
>others. Do not assume that because it runs on the 2 machines your currently
>trying to get working it will do so on all others. ....>
>Rob



Fri, 10 Sep 2004 23:50:12 GMT  
 recompiling yields broken exe
A very well-explained outline of the options, David.  The irony is not
really that ironic: stick with the oldest versions that work, because new
ones are generally backward-compatible with those.  Don't try to install new
versions of anything if you can avoid it, because although a working system
_may_ be improved by an update, it is also very possible that it will be
broken by it instead.

Personally, I find the use of a "clean-compile" machine, with very
carefully-controlled (and old as possible) versions of system dlls to be an
absolute necessity.  Our apps are distributed to a wide mix of targets,
still including W95 machines, and I have to be very conservative with how I
update our customers' computers so that they continue working or they _call_
me!  On the telephone!  To COMPLAIN!  Can you imagine??   ;-)

Jim Deutch
MS Dev MVP

Quote:
> Rob,

> Might the solution here be to recompile the app on a machine with the
> *oldest* versions of the dll's, then?

> OF course we have to find such a machine, or configure one.  BUt the
> compatibility issue -- I'll speak for my own case in this instance, don't
> know if it is the same for you -- seems to be running an exe compiled in
the
> presence of newer dll's, on machines where the older dll's are installed.

> The converse is not also true.  My older exe has run fine on machines with
> the newer dll's installed.

> So (at least for me) the choice is to either locate and distribute the
newer
> dll's myself (the problem being that setup wiz can't help with that, and
> even if I can hand check every file found in setup.lst and locate the
newer
> version, I'll also have to compress these newer ones myself, in addition
to
> hand edicitn setup.lst),

> OR..

>  move the compiler to a clean machine with only older dll's installed,
> recompile and generate a setup program in that envionment, distribute the
> latter, and count on the fact that newer dll's on field machines generally
> support older interfaces. (OF course ensuring also in our setup routine,
as
> is normally one's obligation, that older dll's will not overwrite newer
ones
> on field machines.)

> In short, the irony would be if the solution is to find *old* dll's and
> compile and distrubute those, huh?

> David

> >>The app I'm working on builds and runs successfully on some machines and
> not
> >others. Do not assume that because it runs on the 2 machines your
currently
> >trying to get working it will do so on all others. ....>
> >Rob



Sat, 11 Sep 2004 03:39:34 GMT  
 recompiling yields broken exe
Hi Jim,

I can relate .. sharing the fear of breaking a customer's machine(!)

Good advice on having a non-upgraded machine for clean compilation.  I will
prepare such a machine now... I feel like I have learned something, with the
help of your comments and others in the thread.

Thanks for your comments on the issue.

regards,
David



Sat, 11 Sep 2004 04:57:48 GMT  
 recompiling yields broken exe
Jim,

Just to say I concur with the opinions of David on this, thanks for all your
help - I'm off to start configuring a new "old" machine. Wish us both luck!

Rob


Quote:
> A very well-explained outline of the options, David.  The irony is not
> really that ironic: stick with the oldest versions that work, because new
> ones are generally backward-compatible with those.  Don't try to install
new
> versions of anything if you can avoid it, because although a working
system
> _may_ be improved by an update, it is also very possible that it will be
> broken by it instead.

> Personally, I find the use of a "clean-compile" machine, with very
> carefully-controlled (and old as possible) versions of system dlls to be
an
> absolute necessity.  Our apps are distributed to a wide mix of targets,
> still including W95 machines, and I have to be very conservative with how
I
> update our customers' computers so that they continue working or they
_call_
> me!  On the telephone!  To COMPLAIN!  Can you imagine??   ;-)

> Jim Deutch
> MS Dev MVP


> > Rob,

> > Might the solution here be to recompile the app on a machine with the
> > *oldest* versions of the dll's, then?

> > OF course we have to find such a machine, or configure one.  BUt the
> > compatibility issue -- I'll speak for my own case in this instance,
don't
> > know if it is the same for you -- seems to be running an exe compiled in
> the
> > presence of newer dll's, on machines where the older dll's are
installed.

> > The converse is not also true.  My older exe has run fine on machines
with
> > the newer dll's installed.

> > So (at least for me) the choice is to either locate and distribute the
> newer
> > dll's myself (the problem being that setup wiz can't help with that, and
> > even if I can hand check every file found in setup.lst and locate the
> newer
> > version, I'll also have to compress these newer ones myself, in addition
> to
> > hand edicitn setup.lst),

> > OR..

> >  move the compiler to a clean machine with only older dll's installed,
> > recompile and generate a setup program in that envionment, distribute
the
> > latter, and count on the fact that newer dll's on field machines
generally
> > support older interfaces. (OF course ensuring also in our setup routine,
> as
> > is normally one's obligation, that older dll's will not overwrite newer
> ones
> > on field machines.)

> > In short, the irony would be if the solution is to find *old* dll's and
> > compile and distrubute those, huh?

> > David

> > >>The app I'm working on builds and runs successfully on some machines
and
> > not
> > >others. Do not assume that because it runs on the 2 machines your
> currently
> > >trying to get working it will do so on all others. ....>
> > >Rob



Sun, 12 Sep 2004 00:56:50 GMT  
 recompiling yields broken exe


Fri, 19 Jun 1992 00:00:00 GMT  
 recompiling yields broken exe
Jim, Rob

While the tactic of using a clean machine is one I still plan to implement,
what about the following shorcut?

In my case, olepro32.dll, appears to be the one at issue.

The new version (which was installed on my system by upgrading the IE
browser, as I found out by tracing down the dll versions on the MSDN dll
resource pages), is installed in my Windows\system subdirectory.

Now, if I go into the "Project\References" submenu dialog, in the VB IDE
when my project is loaded, and scroll down to "Standard OLE Types" (which is
of course checked-selected), it shows this to be the
\Windows\system\oeolepro32.dll, as suspected.

My question is: what if I just try to redirect this item ("Standard OLE
Types") to point to the older copy of olepro32.dll (still residing in my
setup wizard \ kitfiles directory)?

Will VB compile, the next time I compile the project, against the type
library in this older version of the DLL?

I haven't actually simply tried it yet, because I wanted to ask my main
question: is trying this safe?  I don't want VB to cause some side effect in
my system's registry that I'll never disentangle.

Will the compile-time operation just look up the type library in the
(redirected) olepro32.dll, without performing some hidden read-write or
modification of the registry (or elsewhere?)

I don't know enough about what VB actually does, when it compiles (I have
looked for papers on MSDN and in KB, haven't found much other than
references to when it is best to use p-code, vs. native code with
optimizations.)

Am I on safe ground --- and secondarily, will it work?

Thanks,
Dave



Sun, 12 Sep 2004 05:15:25 GMT  
 recompiling yields broken exe
PS

I used olepro32 as an example.  In my case, perhaps Rob's as well, there are
numerous files, like MS foundation classes etc. but the example from the
"Standard OLE Types" reference serves to pose the question.

Thanks,
David

Quote:

>Jim, Rob

>While the tactic of using a clean machine is one I still plan to implement,
>what about the following shorcut?

>In my case, olepro32.dll, appears to be the one at issue.

>The new version (which was installed on my system by upgrading the IE
>browser, as I found out by tracing down the dll versions on the MSDN dll
>resource pages), is installed in my Windows\system subdirectory.

>Now, if I go into the "Project\References" submenu dialog, in the VB IDE
>when my project is loaded, and scroll down to "Standard OLE Types" (which
is
>of course checked-selected), it shows this to be the
>\Windows\system\oeolepro32.dll, as suspected.

>My question is: what if I just try to redirect this item ("Standard OLE
>Types") to point to the older copy of olepro32.dll (still residing in my
>setup wizard \ kitfiles directory)?

>Will VB compile, the next time I compile the project, against the type
>library in this older version of the DLL?

>I haven't actually simply tried it yet, because I wanted to ask my main
>question: is trying this safe?  I don't want VB to cause some side effect
in
>my system's registry that I'll never disentangle.

>Will the compile-time operation just look up the type library in the
>(redirected) olepro32.dll, without performing some hidden read-write or
>modification of the registry (or elsewhere?)

>I don't know enough about what VB actually does, when it compiles (I have
>looked for papers on MSDN and in KB, haven't found much other than
>references to when it is best to use p-code, vs. native code with
>optimizations.)

>Am I on safe ground --- and secondarily, will it work?

>Thanks,
>Dave



Sun, 12 Sep 2004 22:45:13 GMT  
 recompiling yields broken exe


Fri, 19 Jun 1992 00:00:00 GMT  
 recompiling yields broken exe
Hi folks,

Well, the bad news is I just installed a machine with NT 4.0, VB 6 SP5, and
just the components I needed in my project (MDAC_TYP.EXE 2.6, Windows Script
Components 2.7) and still have the same cyclical reboot problem. I'm now
totally stumped.

Any suggestions?

Rob



Mon, 13 Sep 2004 00:59:11 GMT  
 recompiling yields broken exe


Fri, 19 Jun 1992 00:00:00 GMT  
 
 [ 18 post ]  Go to page: [1] [2]

 Relevant Pages 

1. Recompiling library database breaks the main database?

2. Recompiling Breaks Binary Compatibility

3. .exe size is different when recompiling after restarting

4. Installutl.exe is broken?

5. upgrading to office 2000 breaks my vb exe

6. Breaking into an EXE....

7. Advise on breaking big app into dlls or smaller exe's

8. Breaking VB5 EXE Project into several DLLs

9. Breaking OBJ or EXE files

10. VB6: OCA files break compiled exe

11. prevent compatibility is broken when swithing from .exe project to .ocx project

12. IE4 breaks VB ActiveX EXE

 

 
Powered by phpBB® Forum Software