version<unspecified>

I have an app that tests the version number of certain dlls it uses on  
startup.

The first seems to be riched20.dll

If I run it on 20050524 it starts and works.

If I run from the same installation after installing wine-0.9 (or just  
about any winecfg based version) it starts throwing errors like:

riched20.dll version<unspecified> was found, this program requires at  
least.....

I then have to pull in a native dll and tell wine to go native when in  
fact the buildin functions  work perfectly.

bug or feature?

I guess this was done intentionally or is a result of an intentional  
change and seems related to winecfg becoming active.

What is the best way to deal with this? It seems a shame to install native  
dlls when the wine code does the job.

TIA

[Paul Vriens]

On Fri, 2005-10-28 at 19:53 +0200, [email protected] wrote:
> I have an app that tests the version number of certain dlls it uses on  
> startup.
>
> The first seems to be riched20.dll
>
> If I run it on 20050524 it starts and works.
>
> If I run from the same installation after installing wine-0.9 (or just  
> about any winecfg based version) it starts throwing errors like:
>
> riched20.dll version<unspecified> was found, this program requires at  
> least.....
>
> I then have to pull in a native dll and tell wine to go native when in  
> fact the buildin functions  work perfectly.
>
> bug or feature?
>
> I guess this was done intentionally or is a result of an intentional  
> change and seems related to winecfg becoming active.
>
> What is the best way to deal with this? It seems a shame to install native  
> dlls when the wine code does the job.
>
> TIA

Hi,

don't have time (yet) to do stuff in Wine, but have a look at
http://www.winehq.org/pipermail/wine-patches/2005-September/020423.html

this shows you how to add version stuff to a dll.

cheers,

Paul

On Fri, 28 Oct 2005 20:15:06 +0200, Paul Vriens [email protected]  
wrote:
> On Fri, 2005-10-28 at 19:53 +0200, [email protected] wrote:
> > I have an app that tests the version number of certain dlls it uses on
> > startup.
> >
> > The first seems to be riched20.dll
> >
> > If I run it on 20050524 it starts and works.
> >
> > If I run from the same installation after installing wine-0.9 (or just
> > about any winecfg based version) it starts throwing errors like:
> >
> > riched20.dll version<unspecified> was found, this program requires at
> > least.....
> >
> > I then have to pull in a native dll and tell wine to go native when in
> > fact the buildin functions  work perfectly.
> >
> > bug or feature?
> >
> > I guess this was done intentionally or is a result of an intentional
> > change and seems related to winecfg becoming active.
> >
> > What is the best way to deal with this? It seems a shame to install  
> > native
> > dlls when the wine code does the job.
> >
> > TIA
>
> Hi,
>
> don't have time (yet) to do stuff in Wine, but have a look at
> http://www.winehq.org/pipermail/wine-patches/2005-September/020423.html
>
> this shows you how to add version stuff to a dll.
>
> cheers,
>
> Paul

Many thanks, that looks like one answer. I could arbitarily give it the  
version number my app is looking for , tho' that is not a very rigourous  
approach.

I was hoping for some info as to why this worked before and not now.  
Appartently earlier wine releases did return something that satified the  
version check in the software.

Thx anyway, useful.

On Fri, 28 Oct 2005 20:15:06 +0200, Paul Vriens [email protected]  
wrote:
> On Fri, 2005-10-28 at 19:53 +0200, [email protected] wrote:
> > I have an app that tests the version number of certain dlls it uses on
> > startup.
> >
> > The first seems to be riched20.dll
> >
> > If I run it on 20050524 it starts and works.
> >
> > If I run from the same installation after installing wine-0.9 (or just
> > about any winecfg based version) it starts throwing errors like:
> >
> > riched20.dll version<unspecified> was found, this program requires at
> > least.....
> >
> > I then have to pull in a native dll and tell wine to go native when in
> > fact the buildin functions  work perfectly.
> >
> > bug or feature?
> >
> > I guess this was done intentionally or is a result of an intentional
> > change and seems related to winecfg becoming active.
> >
> > What is the best way to deal with this? It seems a shame to install  
> > native
> > dlls when the wine code does the job.
> >
> > TIA
>
> Hi,
>
> don't have time (yet) to do stuff in Wine, but have a look at
> http://www.winehq.org/pipermail/wine-patches/2005-September/020423.html
>
> this shows you how to add version stuff to a dll.
>
> cheers,
>
> Paul

Thanks for the info.

I was not really wanting to get into recoding the wine dlls, I'm not sure  
I'm upto it and I would not have the inside knowlege to know what version  
would best represent each dll.

I have an app. which is working pretty well under 20050524 but if I run  
one of the winecfg releases the app. throws this version <unspecified> bit.

I would like to know what change brought this about.

Is the text "unspecified" actually returned by wine now or is this the  
app's interpretation.

There seems to be a definate regression here.

Do you have any more detail on this?

TIA

[Paul Vriens]

> On Fri, 28 Oct 2005 20:15:06 +0200, Paul Vriens [email protected]
> wrote:
> > On Fri, 2005-10-28 at 19:53 +0200, [email protected] wrote:
> > > I have an app that tests the version number of certain dlls it uses on
> > > startup.
> > >
> > > The first seems to be riched20.dll
> > >
> > > If I run it on 20050524 it starts and works.
> > >
> > > If I run from the same installation after installing wine-0.9 (or just
> > > about any winecfg based version) it starts throwing errors like:
> > >
> > > riched20.dll version<unspecified> was found, this program requires at
> > > least.....
> > >
> > > I then have to pull in a native dll and tell wine to go native when in
> > > fact the buildin functions  work perfectly.
> > >
> > > bug or feature?
> > >
> > > I guess this was done intentionally or is a result of an intentional
> > > change and seems related to winecfg becoming active.
> > >
> > > What is the best way to deal with this? It seems a shame to install
> > > native
> > > dlls when the wine code does the job.
> > >
> > > TIA
> >
> > Hi,
> >
> > don't have time (yet) to do stuff in Wine, but have a look at
> > http://www.winehq.org/pipermail/wine-patches/2005-September/020423.html
> >
> > this shows you how to add version stuff to a dll.
> >
> > cheers,
> >
> > Paul
>
> Thanks for the info.
>
> I was not really wanting to get into recoding the wine dlls, I'm not sure
> I'm upto it and I would not have the inside knowlege to know what version
> would best represent each dll.
>
> I have an app. which is working pretty well under 20050524 but if I run
> one of the winecfg releases the app. throws this version <unspecified>
> bit.
>
> I would like to know what change brought this about.
>
> Is the text "unspecified" actually returned by wine now or is this the
> app's interpretation.
>
> There seems to be a definate regression here.
>
> Do you have any more detail on this?
>
> TIA

Hi,

could you send me a +ver,+loaddll,+module trace of both versions. I will
have a look (if time permits). I hope I can see enough from the logs as
I'm a but reluctant to go back to (or install somewhere else) the 20050524
version.

Cheers,

Paul.

On Mon, 31 Oct 2005 08:36:27 +0100, Paul Vriens [email protected]  
wrote:
> > > Hi,
> > >
> > > don't have time (yet) to do stuff in Wine, but have a look at
> > > http://www.winehq.org/pipermail/wine-patches/2005-September/020423.html
> > >
> > > this shows you how to add version stuff to a dll.
> > >
> > > cheers,
> > >
> > > Paul
> >
> > Thanks for the info.
> >
> > I was not really wanting to get into recoding the wine dlls, I'm not  
> > sure
> > I'm upto it and I would not have the inside knowlege to know what  
> > version
> > would best represent each dll.
>
> Hi,
>
> could you send me a +ver,+loaddll,+module trace of both versions. I will
> have a look (if time permits). I hope I can see enough from the logs as
> I'm a but reluctant to go back to (or install somewhere else) the  
> 20050524
> version.
>
> Cheers,
>
> Paul.

OK appologies, some misinformation on my part , I will have to look again.  
I have just realised that what caused <unspecified> to come back was that  
an earlier setup using sidenet has * native,builtin ; when I swapped to  
0.9 which winecfg driven all my nice settings in .wine/config are ignored  
and I'm back to a default wine.

I'll have to go through it again and try to remove the *n,b .

Is there an easy way to recompile a dll on its own after editting  
VERSIONINFO as you suggested or is it simpler hit it with a sledgehammer  
and rebuild wine entirely.

TIA

On Fri, 28 Oct 2005 20:15:06 +0200, Paul Vriens [email protected]  
wrote:
> On Fri, 2005-10-28 at 19:53 +0200, [email protected] wrote:
> > I have an app that tests the version number of certain dlls it uses on
> > startup.
> >
> > The first seems to be riched20.dll
> >
> > If I run it on 20050524 it starts and works.
> >
> > If I run from the same installation after installing wine-0.9 (or just
> > about any winecfg based version) it starts throwing errors like:
> >
> > riched20.dll version<unspecified> was found, this program requires at
> > least.....
> >
> > I then have to pull in a native dll and tell wine to go native when in
> > fact the buildin functions  work perfectly.
> >
> > bug or feature?
> >
> > I guess this was done intentionally or is a result of an intentional
> > change and seems related to winecfg becoming active.
> >
> > What is the best way to deal with this? It seems a shame to install  
> > native
> > dlls when the wine code does the job.
> >
> > TIA
>
> Hi,
>
> don't have time (yet) to do stuff in Wine, but have a look at
> http://www.winehq.org/pipermail/wine-patches/2005-September/020423.html
>
> this shows you how to add version stuff to a dll.
>
> cheers,
>
> Paul

To bring this upto date:

I have moved wine to 0.9 with this app and have got the native dll count  
required in winecfg down to 4. Two of these appear to be simply due to the  
lack of version_info in the built-in dll.

riched20 : req >= 5.30.22.2300
mscvrt : req >= 6.1.8637.0

I have not worked out how to rebuild the dlls with version info hacked in  
under Gentoo, so I cannot state these will work but strongly suspect they  
will.

Thanks again for your help.

[Paul Vriens]

On Sun, 2005-11-06 at 01:03 +0100, [email protected] wrote:
> On Fri, 28 Oct 2005 20:15:06 +0200, Paul Vriens [email protected]  
> wrote:
> > On Fri, 2005-10-28 at 19:53 +0200, [email protected] wrote:
> > > I have an app that tests the version number of certain dlls it uses on
> > > startup.
> > >
> > > The first seems to be riched20.dll
> > >
> > > If I run it on 20050524 it starts and works.
> > >
> > > If I run from the same installation after installing wine-0.9 (or just
> > > about any winecfg based version) it starts throwing errors like:
> > >
> > > riched20.dll version<unspecified> was found, this program requires at
> > > least.....
> > >
> > > I then have to pull in a native dll and tell wine to go native when in
> > > fact the buildin functions  work perfectly.
> > >
> > > bug or feature?
> > >
> > > I guess this was done intentionally or is a result of an intentional
> > > change and seems related to winecfg becoming active.
> > >
> > > What is the best way to deal with this? It seems a shame to install  
> > > native
> > > dlls when the wine code does the job.
> > >
> > > TIA
> >
> > Hi,
> >
> > don't have time (yet) to do stuff in Wine, but have a look at
> > http://www.winehq.org/pipermail/wine-patches/2005-September/020423.html
> >
> > this shows you how to add version stuff to a dll.
> >
> > cheers,
> >
> > Paul
>
> To bring this upto date:
>
> I have moved wine to 0.9 with this app and have got the native dll count  
> required in winecfg down to 4. Two of these appear to be simply due to the  
> lack of version_info in the built-in dll.
>
> riched20 : req >= 5.30.22.2300
> mscvrt : req >= 6.1.8637.0

This last one is now in CVS :
http://www.winehq.org/pipermail/wine-cvs/2005-November/019086.html

Cheers,

Paul.