software built and worked under wine but not in vista?

[Hin-Tak Leung]

I have encountered a slightly strange issue with building the windows self-extracting installer release of ghostscript (http://www.ghostscript.com/) - the self-extracting installer is created with the winzip self-extractor package, which can be manually unzipped.

The curious thing is that I can build the self-extracting installer under 32-bit wine with the win 7 SDK (on 64-bit linux). but when I tried to run the self-installer under Vista, it says %1 is not a valid win32 application. Manually unpacking the selft-extracting installer and run 'setupgs.exe' (the setup program) also gives 'setupgs.ese is not a valid win32 application' message. But the main ghostcript executable seems operational. (the setup program mostly only just copy the extracted files to "Program Files" and set up a few registry entries, but ghostscript doesn't not require those to work).

So it seems that setupgs.exe is mis-compiled under wine with win7 sdk but just happened to also work under wine. Any idea how it might happen?
I have checked things like end-of-line, but it is curious why the setupgs program works under wine but not in vista, the reverse situation compared to most.

[Saulius Krasuckas]

I sorry for stepping into Alexandre's or Dmitry's shoes, but..

* On Tue, 18 May 2010, Hin-Tak Leung wrote:
> So it seems that setupgs.exe is mis-compiled under wine with win7 sdk 
> but just happened to also work under wine. Any idea how it might happen?

... there could be a pair of bugs: one in PE image manipulation functions 
plus another in Wine PE loading mechanism(s).

I could imagine the first easily inside a IMAGEHLP, eg. functions 
ImageAddCertificate() or CheckSumMappedFile().

If you find the first one, then it should be possible to write a test to 
reveal the second one.
> I have checked things like end-of-line, but it is curious why the 
> setupgs program works under wine but not in vista, the reverse situation 
> compared to most.

Could you build the same project under real Windows?

Then I would run "winedump dump -f" or even "-x" on both files to compare 
the outputs (probably line by line) and to find the essential difference.

S.

[Hin-Tak Leung]

--- On Wed, 19/5/10, Saulius Krasuckas  wrote:
> I sorry for stepping into Alexandre's
> or Dmitry's shoes, but..
> - On Tue, 18 May 2010, Hin-Tak Leung wrote:
> > So it seems that setupgs.exe is mis-compiled under
>
> wine with win7 sdk
> > but just happened to also work under wine. Any idea
>
> how it might happen?
>
> ... there could be a pair of bugs: one in PE image
> manipulation functions 
> plus another in Wine PE loading mechanism(s).
>
> I could imagine the first easily inside a IMAGEHLP, eg.
> functions 
> ImageAddCertificate() or CheckSumMappedFile().
>
> If you find the first one, then it should be possible to
> write a test to 
> reveal the second one.
> > I have checked things like end-of-line, but it is
>
> curious why the
> > setupgs program works under wine but not in vista, the
>
> reverse situation
> > compared to most.
>
> Could you build the same project under real Windows?
>
> Then I would run "winedump dump -f" or even "-x" on both
> files to compare 
> the outputs (probably line by line) and to find the
> essential difference.

I am thinking of doing it under real windows. I built it twice under wine and the binaries are identical except for 6 bytes (probably date stamps), so if I build the same snapshot with the same compiler under Vista and the same build procedure, I would expect the the result would be similiarly differ by 6 bytes only, if the compiler/wine works the same way as compiler/vista.

I'll try it now and see how it goes.

[Hin-Tak Leung]

Saulius Krasuckas wrote:
> I sorry for stepping into Alexandre's or Dmitry's shoes, but..
> - On Tue, 18 May 2010, Hin-Tak Leung wrote:
> > So it seems that setupgs.exe is mis-compiled under wine with win7 sdk 
> > but just happened to also work under wine. Any idea how it might happen?
>
> ... there could be a pair of bugs: one in PE image manipulation functions 
> plus another in Wine PE loading mechanism(s).
>
> I could imagine the first easily inside a IMAGEHLP, eg. functions 
> ImageAddCertificate() or CheckSumMappedFile().
>
> If you find the first one, then it should be possible to write a test to 
> reveal the second one.
> > I have checked things like end-of-line, but it is curious why the 
> > setupgs program works under wine but not in vista, the reverse situation 
> > compared to most.
>
> Could you build the same project under real Windows?
>
> Then I would run "winedump dump -f" or even "-x" on both files to compare 
> the outputs (probably line by line) and to find the essential difference.

I have gone ahead and done exactly that - the correct behavior should be a msg 
box saying filelist.txt is missing, rather than setupgs.exe not a valid win32 
application.

http://www.ghostscript.com/~hintak/setupgs-vista.exe
http://www.ghostscript.com/~hintak/setupgs-wine.exe

I haven't tried the uninstaller yet, so I don't know if the wine-built 
uninstaller work:

http://www.ghostscript.com/~hintak/uninstgs-vista.exe
http://www.ghostscript.com/~hintak/uninstgs-wine.exe

To analyse the executables are a bit beyond me, but I hope somebody can do that.

under either system, if I compile the file twice quickly, the result differs 
only by the datestamp and checksum (and in two wine-compiled executable built a 
bit of time between , also a few bytes in the .text section after what looks 
like an import table in a hex editor?

[Matijn Woudt]

On Thu, May 20, 2010 at 3:54 AM, Hin-Tak Leung  wrote:
> Saulius Krasuckas wrote:
> > I sorry for stepping into Alexandre's or Dmitry's shoes, but..
> > - On Tue, 18 May 2010, Hin-Tak Leung wrote:
> > > So it seems that setupgs.exe is mis-compiled under wine with win7 sdk but
> > > just happened to also work under wine. Any idea how it might happen?
> >
> > ... there could be a pair of bugs: one in PE image manipulation functions
> > plus another in Wine PE loading mechanism(s).
> >
> > I could imagine the first easily inside a IMAGEHLP, eg. functions
> > ImageAddCertificate() or CheckSumMappedFile().
> >
> > If you find the first one, then it should be possible to write a test to
> > reveal the second one.
> > > I have checked things like end-of-line, but it is curious why the setupgs
> > > program works under wine but not in vista, the reverse situation compared to
> > > most.
> >
> > Could you build the same project under real Windows?
> >
> > Then I would run "winedump dump -f" or even "-x" on both files to compare
> > the outputs (probably line by line) and to find the essential difference.
>
> I have gone ahead and done exactly that - the correct behavior should be a
> msg box saying filelist.txt is missing, rather than setupgs.exe not a valid
> win32 application.
>
> http://www.ghostscript.com/~hintak/setupgs-vista.exe
> http://www.ghostscript.com/~hintak/setupgs-wine.exe
>
> I haven't tried the uninstaller yet, so I don't know if the wine-built
> uninstaller work:
>
> http://www.ghostscript.com/~hintak/uninstgs-vista.exe
> http://www.ghostscript.com/~hintak/uninstgs-wine.exe
>
> To analyse the executables are a bit beyond me, but I hope somebody can do
> that.
>
> under either system, if I compile the file twice quickly, the result differs
> only by the datestamp and checksum (and in two wine-compiled executable
> built a bit of time between , also a few bytes in the .text section after
> what looks like an import table in a hex editor?

There are a few differences I spotted between the two executables:
1) setupgs-wine.exe has wrong image size, changing it from 0x2b200 to
0x2b000 makes the executable working under win7.
2) setupgs-wine.exe has wrong resource size, probably related to 1),
because the size of both executables are the same.
3) The assembly in setupgs-wine.exe has only LF line endings, vista
has CRLF. This explains 2).

I don't know the reason for 3), I assume it's a bug somewhere in wine.

[Saulius Krasuckas]

* On Thu, 20 May 2010, Matijn Woudt wrote:
> On Thu, May 20, 2010 at 3:54 AM, Hin-Tak Leung  wrote:
> > I have gone ahead and done exactly that - the correct behavior should 
> > be a msg box saying filelist.txt is missing, rather than setupgs.exe 
> > not a valid win32 application.
> >
> > http://www.ghostscript.com/~hintak/setupgs-vista.exe
> > http://www.ghostscript.com/~hintak/setupgs-wine.exe
>
> There are a few differences I spotted between the two executables:
> - setupgs-wine.exe has wrong image size, changing it from 0x2b200 to
>
> 0x2b000 makes the executable working under win7.
> 2) setupgs-wine.exe has wrong resource size, probably related to 1), 
> because the size of both executables are the same.
> 3) The assembly in setupgs-wine.exe has only LF line endings, vista has 
> CRLF. This explains 2).
>
> I don't know the reason for 3), I assume it's a bug somewhere in wine.

Thus it could be a fault in Wine's msvcrt.dll (or the like: msvcr?0.dll).

To check this, it would be nice to run "winetricks vcrun6", recomple the 
app in Wine and see if the resulting exe run OK on Vista.

S.

[Hin-Tak Leung]

--- On Thu, 20/5/10, Saulius Krasuckas  wrote:
> > > http://www.ghostscript.com/~hintak/setupgs-vista.exe
> > > http://www.ghostscript.com/~hintak/setupgs-wine.exe
> >
> > There are a few differences I spotted between the two
>
> executables:
> > - setupgs-wine.exe has wrong image size, changing it
>
> from 0x2b200 to
> > 0x2b000 makes the executable working under win7.
> > 2) setupgs-wine.exe has wrong resource size, probably
>
> related to 1),
> > because the size of both executables are the same.
> > 3) The assembly in setupgs-wine.exe has only LF line
>
> endings, vista has
> > CRLF. This explains 2).
> >
> > I don't know the reason for 3), I assume it's a bug
>
> somewhere in wine.
>
> Thus it could be a fault in Wine's msvcrt.dll (or the like:
> msvcr?0.dll).
>
> To check this, it would be nice to run "winetricks vcrun6",
> recomple the 
> app in Wine and see if the resulting exe run OK on Vista.

Tried that - the binary differs by 6 bytes - just timestamp and checksum. So using native msvcrt in vcrun6 has no effect.

[Hin-Tak Leung]

--- On Thu, 20/5/10, Matijn Woudt  wrote:
> > > - On Tue, 18 May 2010, Hin-Tak Leung wrote:
> > > > So it seems that setupgs.exe is mis-compiled
>
> under wine with win7 sdk but
> > > > just happened to also work under wine. Any
>
> idea how it might happen?
> > I have gone ahead and done exactly that - the correct
>
> behavior should be a
> > msg box saying filelist.txt is missing, rather than
>
> setupgs.exe not a valid
> > win32 application.
> >
> > http://www.ghostscript.com/~hintak/setupgs-vista.exe
> > http://www.ghostscript.com/~hintak/setupgs-wine.exe
> >
> > I haven't tried the uninstaller yet, so I don't know
>
> if the wine-built
> > uninstaller work:
> >
> > http://www.ghostscript.com/~hintak/uninstgs-vista.exe
> > http://www.ghostscript.com/~hintak/uninstgs-wine.exe
> >
> > To analyse the executables are a bit beyond me, but I
>
> hope somebody can do
> > that.
> >
> > under either system, if I compile the file twice
>
> quickly, the result differs
> > only by the datestamp and checksum (and in two
>
> wine-compiled executable
> > built a bit of time between , also a few bytes in the
>
> .text section after
> > what looks like an import table in a hex editor?
>
> There are a few differences I spotted between the two
> executables:
> - setupgs-wine.exe has wrong image size, changing it from
>
> 0x2b200 to
> 0x2b000 makes the executable working under win7.
> 2) setupgs-wine.exe has wrong resource size, probably
> related to 1),
> because the size of both executables are the same.
> 3) The assembly in setupgs-wine.exe has only LF line
> endings, vista
> has CRLF. This explains 2).
>
> I don't know the reason for 3), I assume it's a bug
> somewhere in wine.

I tried uninstgs-wine.exe and it is also broken. What's more, the executable is of a different size. I am thinking 2 and 3 are probably red herrings, although it is curious how it happens. (I git-archive under unix and use winzip to extract them, so the manifests are the same, and have unix line endings.)

The ghostscript distribution has other executables besides setupgs.exe and uninstgs.exe (for install and uninstall), but only those two seem to be broken. Those two are also different in having been manipulated through mt. Could the running of mt be buggy?

mt -nologo -manifest $(PSSRC)dwsetup_x64.manifest -outputresource:$(SETUP_XE);#1

I have tried re-running mt on either a built executable or vista-compiled ones, but there are no modification. perhaps I don't understand what it does and how it does its work.

[André Hentschel]

Am 21.05.2010 01:34, schrieb Hin-Tak Leung:
> --- On Thu, 20/5/10, Matijn Woudt  wrote:
> > > > - On Tue, 18 May 2010, Hin-Tak Leung wrote:
> > > > > So it seems that setupgs.exe is mis-compiled
> >
> > under wine with win7 sdk but
> > > > > just happened to also work under wine. Any
> >
> > idea how it might happen?
> > > I have gone ahead and done exactly that - the correct
> >
> > behavior should be a
> > > msg box saying filelist.txt is missing, rather than
> >
> > setupgs.exe not a valid
> > > win32 application.
> > >
> > > http://www.ghostscript.com/~hintak/setupgs-vista.exe
> > > http://www.ghostscript.com/~hintak/setupgs-wine.exe
> > >
> > > I haven't tried the uninstaller yet, so I don't know
> >
> > if the wine-built
> > > uninstaller work:
> > >
> > > http://www.ghostscript.com/~hintak/uninstgs-vista.exe
> > > http://www.ghostscript.com/~hintak/uninstgs-wine.exe
> > >
> > > To analyse the executables are a bit beyond me, but I
> >
> > hope somebody can do
> > > that.
> > >
> > > under either system, if I compile the file twice
> >
> > quickly, the result differs
> > > only by the datestamp and checksum (and in two
> >
> > wine-compiled executable
> > > built a bit of time between , also a few bytes in the
> >
> > .text section after
> > > what looks like an import table in a hex editor?
> >
> > There are a few differences I spotted between the two
> > executables:
> > - setupgs-wine.exe has wrong image size, changing it from
> >
> > 0x2b200 to
> > 0x2b000 makes the executable working under win7.
> > 2) setupgs-wine.exe has wrong resource size, probably
> > related to 1),
> > because the size of both executables are the same.
> > 3) The assembly in setupgs-wine.exe has only LF line
> > endings, vista
> > has CRLF. This explains 2).
> >
> > I don't know the reason for 3), I assume it's a bug
> > somewhere in wine.
>
> I tried uninstgs-wine.exe and it is also broken. What's more, the executable is of a different size. I am thinking 2 and 3 are probably red herrings, although it is curious how it happens. (I git-archive under unix and use winzip to extract them, so the manifests are the same, and have unix line endings.)
>
> The ghostscript distribution has other executables besides setupgs.exe and uninstgs.exe (for install and uninstall), but only those two seem to be broken. Those two are also different in having been manipulated through mt. Could the running of mt be buggy?
>
> mt -nologo -manifest $(PSSRC)dwsetup_x64.manifest -outputresource:$(SETUP_XE);#1
>
> I have tried re-running mt on either a built executable or vista-compiled ones, but there are no modification. perhaps I don't understand what it does and how it does its work.

compile your setupgs in wine but without the "mt-step" and try running it on vista.
if mt breaks the PE file then submit a bug report describing wrong behavior of mt.

[Hin-Tak Leung]

--- On Fri, 21/5/10, André Hentschel  wrote:
> compile your setupgs in wine but without the "mt-step" and
> try running it on vista.
> if mt breaks the PE file then submit a bug report
> describing wrong behavior of mt.

This is what I am doing next. I have also made a change to ghostscript trunk (r11296) so that the installer/uninstaller executables can be built ahead or independent of the rest. (they are normally built last so there were some hidden assumptions about some files being already generated).

I'll upload a source tarball to http://ghostscript.com/~hintak/ as *winedebug.tar.gz soon
with a small workaround (there is a bug about cmd/cp I filed and a work around in wine's bugzilla). To build the binaries do:

nmake -f psi/msvc32.mak bin\setupgs.exe bin\uninstgs.exe

I'll put all these in two bug reports - it is looking like two bugs;
- one where binaries are miscompiled
- wine's loader does not complain about the mis-compiled executables, but windows vista or win7 do.

[Hin-Tak Leung]

Thanks for everybody who advised. I have filed the two bugs under:

[Bug 22813] wine's loader does not check invalid image size
[Bug 22812] mt creates corrupted executables

In a nutshell, just before running mt, wine and vista generates very similiar
executables (differing by 4 bytes, two about time stamps and two seems to be 
some padding at the end of the import table?). Then the mt makes the executables 
  invalid (at least under vista and also according to one of you, from win7).

And wine certainly doesn't behave like vista in rejecting the executables and 
happily loading them...

[Hin-Tak Leung]

Matijn Woudt wrote:
> There are a few differences I spotted between the two executables:
> - setupgs-wine.exe has wrong image size, changing it from 0x2b200 to
>
> 0x2b000 makes the executable working under win7.
> 2) setupgs-wine.exe has wrong resource size, probably related to 1),
> because the size of both executables are the same.
> 3) The assembly in setupgs-wine.exe has only LF line endings, vista
> has CRLF. This explains 2).
>
> I don't know the reason for 3), I assume it's a bug somewhere in wine.

I have started looking into pedump and dumpbin, and the PE/COFF format, but it 
is new territory to me... can you explain either in a private e-mail, or if the 
info is more relevant to the wider audience, how can one tell the image size and 
resource size is 'wrong'? Presumably it is a consistency check of some sort - 
i.e. one part needs to agree with another, and the wine loader is not doing the 
check at the moment.

If I can do that life on linux or elsewhere life would be easier - not booting 
into windows; because then I can see what the 2nd bug is about - tried using 
native imagehlp and there is no improvement, so I probably need to try each of 
mt.exe's dependencies to see which of them breaks the executable. (but I need to 
be able to tell an executable being broken first).