Wine Traffic #33 For 6 Mar 2000

Hmmm... any reason this stuff (EN: the low level module) cannot remain in WNASPI32? I don't like the idea of adding more things into the Wine core and defining yet another internal interface; we already have way too many of them that will have to be cleaned up for correct dll separation.

we are already doing too many things at startup; and having to parse /proc/scsi every time when 99% of the apps won't care a bit about SCSI is a bit wasteful.

simply have the install script create empty dll files in the Windows directory? Besides, with DLL separation, there won't be a global list of builtin dlls anymore.

next logical step, to store the version information in these files. Certainly better than magic pseudo-handles to non-existent files.

Oh please... should we also include the whole source in the Wine executable so that we can automatically recompile libwine.so in case the user deleted it?

This is a packaging issue; we need to have proper install scripts, and users who don't know what they are doing should use an rpm or debian package that will do everything for them. This stuff does not belong in the Wine executable.

We are closing in on complete support for the Microsoft Visual C++ debugger nub. That is, you can use Visi C++ to control an app under Wine. The last piece of the puzzle is having full symbolic and stack frame information available not just for application code but also for all Wine code.

To do that, we are taking a Wine .so file (e.g. libwine.so) and reporting it to Visi C++ as a DLL load event. In order for Visi C++ to then resolve addresses within that DLL, we have to create a PE header that encompasses all of the code within that .so file.

Currently, we've just done hack tests to prove the concept. That is, we just use the currently allocated PE header, create a dummy text section (filled with int 3's), and branch to an address within the text section. Get the break point, backtrace looks perfect.

Now, we're trying to do this correctly. IMHO this requires using a PE header that is prior to the text section of the .so file, so that it can encompass the text section. (We did in fact use a PE header that was disjoint from the text section, and we could make it work to resolve a symbol into the correct address. However, Visi C++ would not resolve the address back to the symbol unless the address fell within the range starting with the PE. You need address to symbol resolution in order for backtracing and other goodies to work).

So, it is my belief that the best way to do this is to declare (only after a nasty configure option is selected, of course) a data block to hold the PE header, and arrange with ld for that data block to be placed immediately prior to the text section.

I object on general portability principles, but if the advantages are big enough (or the alternatives too ugly) I can certainly consider it. I think building dlls will require some advanced tools anyway (like objdump -L etc.) so a linker script is not too bad, as long as linking statically remains possible without special magic.

The past two Wine releases have seen my Wine performance actually decay to near zero, and I think part of the problem is that "make install" does not seem to follow FSH conventions for what files go where, while the binary RPMs I had used before managed this quite well.

On my system, the latest Wine release was completely unable to find its shared library files. After kludgeing a fix using soft links, Wine was then unable to find wine.conf. So I moved wine.conf. Then Wine generated errors about being unable to bind to many functions within mscrt32.dll (using "deadbeef" instead), then crashing when a "deadbeef" was accessed.

Rather than suggest that Wine itself is getting worse with time, it seems to me that the installation might not not keeping up with the needs of the program itself. The use of an RPM spec file may serve to make the installation easier to monitor and maintain.

So I humbly request that Source and Binary Wine releases should be generated in the RPM format, to make life (system and application management) easier for Wine users and testers who are not Wine developers. Sure, keep the tar.gz format (since it is easy to extract from the current CVS tree), but I would also recommend that the RPM spec files be added to the CVS tree, and that both the RPM spec files and the "make install" are check for conformance to the FSH.

Furthermore, if the needs of wine.conf change over time, a script should be included as part of the installation to at least detect out-of-date wine.conf files and allow the user to make needed updates before running an updated instance of Wine. Similar checks should be made for the PATH content. There should be little or no need to debug the Wine runtime environment every time Wine is updated.

I know this may be a lot to ask, but as Wine gets closer and closer to leaving alpha status, installation and environment issues will become ever more important. It may be best to start getting a better handle on them sooner rather than later, since this should also encourage more people to use Wine.

Guys, don't be assholes. There are tons of people out there that should be _encouraged_ to test out wine, without blaming them for a hard install. Do not get stuck in the old-time UNIX (and BSD and Debian) mentality of "it's supposed to be hard, because that's what makes you a man".

There was a reasonable cry for help and easier installation, don't miss the POINT of this all. Wine developers in particular should be aware of the fact that it's a good thing when programs are easy to use, install and play with, WITHOUT the kind of "go fix all your problems yourself" mentality...

Please folks, let's keep our priorities straight. The real issue is that we need easy-to-install binary packages for people who want them; I think nobody will dispute that. Since I'm not releasing such packages myself (and this is not going to change) you need to take up whatever problems you encountered with the package maintainer, and help him improve the situation, or take over the job if necessary.

If the package maintainer feels that his job would be made easier by having a spec file in the CVS tree, I'm certainly open to discussing it. But it is not a miraculous solution that will suddenly make the packages work, for the obvious reason that the people who try the binary packages are precisely those who do not use the CVS tree.