Wine Traffic #147 For 6 Dec 2002

I've gotten a lot of great screenshots over the past few weeks. I've put together a preview you can find here:

http://www.theshell.com/~vinn/ss/preview.html

Be warned, the format isn't the best, the thumbnails aren't even close to optimized, I only looked at it in one browser, and it might even steal your lunch money.

Random notes:

• there's lots of great shots not on the thumbnails page - most likely there's a reason, not 800x600, didn't scale well, or I simply overlooked it
• you can find all of the screenshots at:
  http://www.theshell.com/~vinn/ss
• the images predominantly are PNG, though there are quite a few JPEGs. No GIF.
• Special thanks to:
  Thomas Wickline
  Carlos Lozano
  David Buchmann
  Guido Grazioli
  Ender
  Juliusz Gonera
  Michael Krasucki
  Mike Hearn
  Rick Romero
  Robert Shade
  Rory King
  Tony Lambregts
  tavis

Okay, if you've read this far maybe you're expecting something to prompt discussion. One of the things you'll notice is there's a lot of screenshots on there there almost certainly don't run out of the box. In some instances the folks above listed exactly what they had to do to make it run. Personally, I don't think it matters. We already have the apps DB and the proposed "Gold/Silver/.." apps list, I really don't think we need more than a link to one of those.

we're going to have the Gold page, listing apps that you can get going without any tricks. It's going to contain screenshots as well, it's going to be self contained.

This page is a little different, there no point in putting the same constraints on it as the Gold page. That being said, I fully agree with you. So I think that we should:

• NOT include apps that crash or don't work reasonable well Just starting up enough to take a shot is not good enough
• NOT include apps that can not be tweaked into working with a reasonable enough of effort. Apps that _require_ cxoffice or WineX have no place on this page
• DO include a warning saying that the apps featured on this page may require teaks to get working. Each shot should have a link to the appropriate entry on the appdb that has up to date instructions on how to get the app working
• TRIM the list rather than have lots and lots of apps that may not work right, or have installation problems, etc.

Version 0.6 of the TODO for Wine 0.9 is available at:

http://www.dssd.ca/wine/Wine-0.9-TODO-0.6.html

As always, you can find the work-in-progress one here:

http://www.dssd.ca/wine/Wine-0.9-TODO.html

As a departure from previous release, this time I'm only going to include a small summary of changes since the last release:

• A4: New screenshots page is available for comment
• A5: New FAQ is done, waiting to be promoted to WineHQ
• D2: Alexandre got rid of the rsrc directive in .spec files
• E4: Lionel made OpenGL detection dynamic
• E9: New TODO item for fixing header location as discussed on wine-devel

I have updated the Janitorial section:

http://www.dssd.ca/wine/Wine-Janitorial.html

with the list of cross calls from 32->16, and W->A.

There are currently 13 cross calls from 32->16 bit code, and 194 cross calls from Unicode to ASCII.

Any takers? :)

I was just looking at shell32.dll and wondered if it should implement A->U as it almost completely consistently implements U->A. So I guess this should all be changed then. Problem is that some of those functions call other functions where only the ANSI version is implemented yet, so it is a lot more work than just moving the implementation from the ANSI to the Unicode version.

But what the heck do the errors about AW functions calling Unicode mean? Isn't that the actual idea about the AW functions?

Please feel free to suggest new projects for the list. There are many things to cleanup in the tree, and having them available on an easy to read page increase the changes of (1) someone picking them up, and (2) us not forgeting them.

So let me know if you come across anything that you feel should be on the list. Also, if you're working on something big, I can mark your name there so we can avoid duplicated work.

Last but not least, there are a lot of small, self contained, and easy to get into tasks listed there. If you feel like getting your feet a bit wet in Wine development, this is an ideal opportunity to start, and get to know the project a little better. Just ask for help if you are new, and would like some help to get you started.

I'm just posting a quick update on my various WINE work for those intrested.

I currently have a working HTML Help viewer, which seems to work pretty well on everything I've tested so far. It does however need some more work to conform to the way the real HTML Help system works in Windows (eg, I havn't written an ActiveX control for it yet).

Currently the HTML Help viewer requires an IWebBrowser interface, and only really works with an Internet Explorer installation - so I don't believe it should be commited into WINE proper yet. We don't want applications in our own CVS that require native dlls :)

That brings me to my other WIP, de-QT'ing KHTML and turning it into a working browser implementation for WINE. So far this is actually coming along quite well, and besides a few points it definatly makes an effective browser and IE compatability seems to generally be good enough to keep the majority of IWebBrowser using applications happy. I've since abandoned my earlier hopes to keep the changes minor (in order to make it easier to backport fixes from the main KDE cvs), simply because it was making the code quite messy.

Hopefully I'll have some beta code ready in a week or two, depending on how my free time goes.

I have a few questions however, mostly I'd like to hear from Alexandre on whether he'll consider accepting this into CVS. A working IWebBrowser implementation is, in my opinion, a must - and my HTML Help work does require it - but there are a few points to consider:

• It is C++. So far, all of WINEs dlls are plain C. Is this really a rule, or just a result of the current areas of focus? I can't really de-C++ khtml and co, but I'm unsure as to whether it's okay to add a requirement for a working C++ compile environment on core dll's.
• It is somewhat big, several megabytes of new code. Hopefully I can chop it down after removing a lot of the unneeded KDE and QT code I currently have #ifdef'ed and commented out.

• Simple
• No XPCOM dependancies
• Could be more easily hacked to add IE compatability (and was more IE compatible to start with)
• Small, good for embedding, relatively fast (gecko embedding is huge)
• Would be possible to include in the Wine CVS tree as opposed to Gecko which is probably almost as big as Wine itself.

There are obviously some pros for Mozilla as well, but the things that make Moz a good choice for a web browser don't apply so much to a good replacement for the WebBrowser control.

I just told Dirk (one of the people putting quite a lot of time into kde) about your work and he told be the following (translated from German):

" [Tell him about kdenox - which is basically a kdelibs replacement with limited functionality for khtml only]
[Then there is the Atheos port, which simply replaces the (few) used Qt classes by its own implemetation and is thus able to use an almost unmodified khtml tree]"

I have been running the Wine conformance tests on Windows 95 and NT4. The results are pretty bad. 24 tests out of 32 have failures in one or more of these two platforms.

That's 75% of 'Windows conformance tests' that don't work on Windows! Out of the 32 tests, only 4, that's 12.5%, execute successfully on all tested platforms (and one of them has 4 todos in Wine).

You can see things more graphically at the following URL: http://fgouget.free.fr/wine/tests-en.shtml

Come on people, we can do better. Send fixes to wine-patches, and send me emails to so that I update this table.

can anybody point me to a resource saying what exactly I may or may not do when writing code for a wine DLL? In particular, when writing code for DLL X, which functions from other DLLs may I call?

Example: When writing netapi32 code, can I call advai32 Registry functions to obtain config options, or do I need to use the (IMO rather awkward) ntdll interface ?

The rules to preserve Dll separation are

• Do not call a non-exported function from a different Module/Dll.
• When calling exported functions of another Dll, make sure the Dll you are working on imports that other Dll (look at the IMPORTS variable in the Dll's Makefile.in). DO NOT USE functions of non-imported Dlls.
• In principle, it is legal to add more IMPORTS to a Dll, but you should have really good reasons to do so. You must make sure that the new imports do not cause a circular Dll dependency (we say if Dll A imports Dll B, A depends on B). Dll Dependencies are specified in the individual Dll's Makefile.in through the IMPORTS variable, and in the file dlls/Makefile.in in the "Inter-Dll dependencies" section.

Dll separation is a goal of current Wine development, it is not achieved yet. However, it is important that you adhere to these rules NOW, so that clean Dll separation can be reached more easily later.

Patrik brought up the header location sometime ago, in this thread:

http://www.winehq.com/hypermail/wine-devel/2002/10/index.html#540

At the time, I thought it is a bit premature, that we have other things to do. Now I realize that this is one of those highly visible external things, that would be a _lot_ better to fix before people start using Winelib. Otherwise will piss people off when we change, or we will not change because people are already using the headers.

Both versions are not good, and I think we can fix them now without too much pain.

Here is my proposal:

${prefix}/include/win32 -- standard Win32 headers
${prefix}/include/msvcrt -- MS Visual C Runtime library
${prefix}/include/wine -- Wine specific headers

It is simple (to understand & implement), clean, and pretty. And I think it solved Patrik's problem (even if I can't quite understand what the problem is from the first message :)), plus a bunch of other things (like making it easy to use other headers for the Win32 API, etc). And best of all, it seems to be easily implementable, no?

I think everything should be under wine/ otherwise we risk conflicts with other packages. So I'd suggest something like this:

${prefix}/include/wine/windows -- standard Windows headers
${prefix}/include/wine/msvcrt -- MS Visual C Runtime library
${prefix}/include/wine -- Wine specific headers

It means the Windows headers are a bit buried instead of being directly under wine/, but it's not too bad. As long as you don't change anything in the source tree I could be convinced to go along with that...

Making only one tweak to /etc/profile, cygwin manages to launch partially.

If you comment the line USER="`id -un`", bash -l -i displays : (I placed "I'm here!" at the end of .bahrc)

C>bash -l -i
I'm here!
syl@snoop ~
$ logout
C>

The next step will be identify the reason why it just logs out.

I tried zsh but it says zsh: error on TTY read: permission denied and then I have no keyboard in wcmd.

mc begin to display itself,then makes disappear the wcmd window, the program doesn't terminate. (??)

I was looking at entry C.5 of the 0.9 Todo list: "Make Wine's DLLs register themselves to avoid manual merging of the winedefault.reg [TODO]"

Upon first glance I figured the approach is to (not necissarily in this order): add regsvr32.exe calls in the installation scripts, fill in the DllRegisterServer (and DllUnregisterServer) sections of the appropriate libraries, and remove those entries from winedefault.reg.

About a dozen dll files have their names in winedefault.reg. So I checked the native versions of these files, and only half of them have a DllRegisterServer function. I did some further research and found that perhaps DllInstall was what I needed. Well, that only adds one library, and two have *both* functions.

Does anyone have any better ideas on what the "Right Way" to tackle this item is? I am sure that adding external functions that do not exist in native versions is *not* the way.

I'm glad you feel that way. I created bug 1117, "Make all Wine OLE DLLs self-registerable", and have been working on an implementation.

What to do about DLLs like ole32.dll that have a native DllRegisterServer but no corresponding DllUnregisterServer? I'm inclined to include it for completeness, though it's unlikely that anyone would ever want to unregister such a basic system DLL.

I posted my idea for representing the registration data, accidentally from "jhohm@happyhappy.dyndns.org" rather than my usual "jhohm@acm.org" (see http://www.winehq.com/hypermail/wine-devel/2002/11/1409.html), but I haven't gotten any responses, not even "looks fine" or "you are a moron". I guess I'll just start submitting patches, then.

For those interested, here are a couple of links relating to the INF file format (1), and the SetupAPI (2). I don't know how complete our implementation is, but it can be found under wine/dlls/setupapi.

I've been following the recent work on D3D and decided I would give a couple of benchmarks/demos I had around a go. Pleasantly I found that they actually start up now and display some stuff on screen! Before the recent patches they would fail completely when starting the actual D3D stuff. I'm not sure if you're aware of these programs or not but I figured I would pass on the URLs to you as they might be of help.

This first is a demo called Bleam:

http://www.bluespoon.com/banjoh/

This page has a binary of the demo and source code as well.

The second is an older benchmark/demo called Tirtanium:

http://www.tirtanium.de/prog3d.html

http://public.planetmirror.com/pub/3dfiles/tweakfiles/benchmark/tirta190.zip

Both display stuff on screen and will run through to the end with no crashes.

PS. Great work guys!

http://cdgenp01.csd.toshiba.com/content/support/downloads/220guide.exe is an "online manual" for the Toshiba 220CDS laptop. I unzipped it with Linux unzip, then ran its setup and the app itself with Wine20020605-2 from Red Hat 8. Both ran acceptably well, although I did get a few warnings

OK, I tried the same app with a freshly compiled Wine20021125. The results are no better. The commandline to run the program is

cd c/docs wine toshdoc.EXE

With either version of Wine, clicking around for a while locks the app up. (e.g. clicking on the big red Right Arrow 10-15 times locks it up).

Plus the display artifacts (text being overwritten without being cleared) are still there.

Wow, I'm really striking out running either the 16 bit or 32 bit version of this old app (see my other post today). Both are freely downloadable... I'd gladly buy a case of Guiness for anyone who contributed patches to the Wine tree that got either of these apps running cleanly. I sadly don't have time to do much more than test.