Hi all, I already announced that I'd want to write support for VersionInfo queries for builtin modules. (several programs query e.g. GDI and USER and break if no original Windows file exists that they can read VS_VERSION_INFO from) I plan to do the following: - check whether the native file exists (where the LZOpenFileA() call is); otherwise: - if file name is a builtin DLL (I need to write a check function for that): - use if1632/builtin.c/BUILTIN_LoadModule() or relay32/builtin32.c/BUILTIN32_DoLoadImage() (export it to some .h file if needed) *somehow* to load the builtin module into memory. for Win32 modules maybe use loader/module.c/MODULE_LoadLibraryExA. for Win16: dunno, find out. - if successful, then load the appropriate VERSION_INFO resource according to the current -winver setting (use VERSION_GetVersion() to find out) via loader/resource.c/FindResource*(), LoadResource*() depending on whether it's a Win16 or Win32 module; For this to succeed the DLLs that need a VERSION_INFO struct should of course have several structs, VERSION_INFO_WIN31, VERSION_INFO_WIN95 etc. And I should add these VERSION_INFO resources to some .rc files just as I did it with DISPLAY and MOUSE in my Win16 resource patch. - FreeLibrary() or FreeModule() the loaded builtin module again. - return the VERSION_INFO data. So what I'm planning to do is just adding different VS_VERSION_INFO structs for each OS version to each of the builtin modules and writing proper function support for that. Somebody suggested some weeks ago to create .EXE stubs that just contain the version info. While this has the advantage that I don't need to enhance the VerQuery*() query functionality for builtin VS_VERSION_INFO as we have external files just as with original Windows DLLs, the disadvantages are much more important: - no enhancement of VerQuery*() needed -> so no support for different OS versions of VS_VERSION_INFO possible either, as the already existing functions of course only support a single VS_VERSION_INFO, the one contained in the file. - additional files have to be installed that are possibly messing up the wine usability in case of broken setup. - how to create .EXE files ?? (well, that could be easily solved by modifying VerQuery*() functions to let them read the same sections in ELF DLLs as they do for .EXE files) So I think I should add the VS_VERSION_INFO to the builtin Wine DLLs just as described above. Or did I miss something completely ?? Andreas Mohr
