Hello,
I am looking at the MS Office 2k or IE5 installation issues on the current wine.
The main problem I see is that when IE5 is installed within the office installer or by itself a message box saying:"The spilt of the Windows Desktop Update from the IE browser has been completed. You are currently running a self-host version of the web shell. Please go to http://ie/teams/setup/shdoc401.htm for more information..." and so on. This stops Office or IE from installing correctly. This behaviour is also reported by at least bug 4789 but not as the main issue.
This is solved if shell32 is using an older win98 file version something like 4.72.3110.1.
The problem as I see it is that we need the shell32.dll DllGetVersion to return a win98 version for some cases and a 2k for others.
My question is why shouldn't the code be changed to return the version depending on the currently emulated version and the process version?
This way when an app is set to win98 and it runs as a win98 it will get a 98 version. When running as 2k and emulating 2k it will get a 2k version and so on.
I have investigated the code and found that by using GetProcessVersion and GetVersionExW we can get the emulated and process version. I also noticed that a similar approach was taken for user.dll with regards to treating the edit control differently according to the emulated and process version. I am talking about get_app_version in wine/dlls/user/edit.c around line 377 We have a different version for all emulated windows versions and at http://members.ozemail.com.au/~geoffch@ozemail.com.au/samples/win32/shell/sh... we have a a lot of the versions needed provided.
On another note we can move the dlls/user/edit.c get_app_version function to a location available for all dlls so we can avoid code duplication and open the way for other dlls to implement the same thing if needed. I am not sure yet what that place would be. Any ideeas?
I will create a bug report for this issue after sending this email. I am planning to post a patch for it once the best approach is refined with your help.
I am very interested in what you all think about this so I will appreciate your oppinions. If you have a better ideea I am very interested in hearing it.
Thanks,
Dragos
P.S. Additional question #1 What is "/* FIXME: when libs/wpp gets fixed to support concatenation we can remove* this and define it in version.rc */" refering to?
I tried taking out the defines from version.h and moving them to version.rc for shell32 getting rid of the version.h include, just like other dlls have it in ther version.rc(shdocvw for example) compiled it and it seemed to work fine. I could make this change also while I am changing code arround this same exact spot.
__________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
Dragos wrote:
Hello,
I am looking at the MS Office 2k or IE5 installation issues on the current wine.
The main problem I see is that when IE5 is installed within the office installer or by itself a message box saying:"The spilt of the Windows Desktop Update from the IE browser has been completed. You are currently running a self-host version of the web shell. Please go to http://ie/teams/setup/shdoc401.htm for more information..." and so on. This stops Office or IE from installing correctly. This behaviour is also reported by at least bug 4789 but not as the main issue.
This is solved if shell32 is using an older win98 file version something like 4.72.3110.1.
The problem as I see it is that we need the shell32.dll DllGetVersion to return a win98 version for some cases and a 2k for others.
My question is why shouldn't the code be changed to return the version depending on the currently emulated version and the process version?
This way when an app is set to win98 and it runs as a win98 it will get a 98 version. When running as 2k and emulating 2k it will get a 2k version and so on.
I have investigated the code and found that by using GetProcessVersion and GetVersionExW we can get the emulated and process version. I also noticed that a similar approach was taken for user.dll with regards to treating the edit control differently according to the emulated and process version. I am talking about get_app_version in wine/dlls/user/edit.c around line 377 We have a different version for all emulated windows versions and at http://members.ozemail.com.au/~geoffch@ozemail.com.au/samples/win32/shell/sh... we have a a lot of the versions needed provided.
On another note we can move the dlls/user/edit.c get_app_version function to a location available for all dlls so we can avoid code duplication and open the way for other dlls to implement the same thing if needed. I am not sure yet what that place would be. Any ideeas?
I will create a bug report for this issue after sending this email. I am planning to post a patch for it once the best approach is refined with your help.
I am very interested in what you all think about this so I will appreciate your oppinions. If you have a better ideea I am very interested in hearing it.
Thanks,
Dragos
P.S. Additional question #1 What is "/* FIXME: when libs/wpp gets fixed to support concatenation we can remove* this and define it in version.rc */" refering to?
We'd like to do this instead, but wpp doesn't yet support it:
#define WINE_FILEVERSION #WINE_FILEVERSION_MAJOR "." #WINE_FILEVERSION_MINOR "." #WINE_FILEVERSION_BUILD "." #WINE_FILEVERSION_PLATFORMID
I tried taking out the defines from version.h and moving them to version.rc for shell32 getting rid of the version.h include, just like other dlls have it in ther version.rc(shdocvw for example) compiled it and it seemed to work fine. I could make this change also while I am changing code arround this same exact spot.
Don't do that. You can't include .rc files from C code.
Hi,
Thanks Robert for the reply. I will not touch version.h then.
I investigated a bit more and the problem is a bit more complex. The call that matters for my problem is GetFileVersionInfo wich does not use DllGetVersion. Changing DllGetVersion won't have an impact on it.
GetFileVersionInfo reads the resource DWORDs to get the info. That means we can have only one hardcoded version for shell32. Am I wrong?
Any thoughts? Any ideeas? It would be very usefull to have this info offered depending on the context of the requester. Else wine's shell32 will be only one hardcoded version.
Thanks,
Dragos
--- Robert Shearman rob@codeweavers.com wrote:
P.S. Additional question #1 What is "/* FIXME: when libs/wpp gets fixed to support concatenation we can remove* this and
define
it in version.rc */" refering to?
We'd like to do this instead, but wpp doesn't yet support it:
#define WINE_FILEVERSION #WINE_FILEVERSION_MAJOR "."
#WINE_FILEVERSION_MINOR "." #WINE_FILEVERSION_BUILD "." #WINE_FILEVERSION_PLATFORMID
I tried taking out the defines from version.h and moving them to version.rc for shell32 getting rid
of
the version.h include, just like other dlls have it
in
ther version.rc(shdocvw for example) compiled it
and
it seemed to work fine. I could make this change
also
while I am changing code arround this same exact
spot.
Don't do that. You can't include .rc files from C code.
__________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
-
Dragos -
Robert Shearman