�
Kernel Traffic
Latest�|�Archives�|�People�|�Topics 		Wine
Latest�|�Archives�|�People�|�Topics 		GNUe
Latest�|�Archives�|�People�|�Topics
Czech
Home | News | RSS Feeds | Mailing Lists | Authors Info | Mirrors | Stalled Traffic
�

Wine Traffic #43 For 15�May�2000

By Eric Pouech

Table Of Contents

Introduction

This is the 43rd release of the Wine's kernel cousin publication. It's main goal is to distribute widely what's going on around Wine (the Un*x windows emulator).

(Ove K�ven pointed out in previous edition (IsBadPtr and such ) that another solution, as Ulrich Weigand also proposed, was to make use of the stack boundaries (as define with the ulimit, or even in Wine core with setrlimit call). Thanks for the correction Ove. -- Ed: [08 May 2000 00:00:00 -0800]

Mailing List Stats For This Week

We looked at 114 posts in 411K.

There were 38 different contributors. 22 posted more than once. 17 posted last week too.

The top posters of the week were:

1. Packaging WineLib apps (and .so files)

11�May�2000 (5 posts) Archive Link: "dll separation"

People: Michael Cardenas,�Eric Pouech,�Alexandre Julliard,�

Some latest changes from Alexandre Julliard split the big libwine.so file into smaller .so file. The final goal is to have each DLL in its own .so file (except for some core DLL like KERNEL32, TOOLHELP... which all sit in libwine.so).

This change impacted Michael Cardenas' project:
I just picked up the latest cvs tree and made the necessary changes to my project for the dll separation. To get my project to link I had to explicitly link a number of dll's including:

My question: is why are we doing this? Does this mean that to ship a Winelib app we're going to have to ship a bunch of little .so files? Wine worked just fine as one big .so and all this means is that we're going to have to spend more time on linker errors.

(Ed Note: Michael's project consist of porting Canvas from Windows to Linux using WineLib. Michael work at Deneba)

Eric Pouech first proposed to use 'configure --disable-dll' which would build any WineLib program as a big executable, but Michael didn't like it:
That's no good. I'll figure out how to make a unified .so, that's what I need.

Eric Pouech went in greater details:
I assume that you want to ship a configuration by its own of your program where you don't rely/mess with any other installed software (and you're afraid of the 20 or so .so files embedding DLLs)

If you package your app like ELF-main executable + libwine.so, then there's still a risk that some of your users, installing some other wine packages overwrite/erase/modify/put before in shared lib load order another libwine.so file. That's not safe either.

Anyway, issues with .so file will appear as soon as you use .so file (no matter you use 1 of them or 20 of them)

Solutions that come to my mind are:
  1. build your app as a single exec (libwine.a comes into play)
  2. build your app as an exec plus a libwine.so file.
  3. build your app as an exec plus a bunch of .so files

>From a distribution stand point: 1/ is the easiest one. 2/ and 3/ can cause trouble if users change the .so files somehow... You can in 2/ use another name for libwine.so, like libwine_for_my_app_no_one_can_use_it.so, but there's no gain with solution 1 (except if you have several execs sharing this .so file) >From an execution speed point of view: 3/ is the best one (less memory: only loads needed code), less time (because less things to do) >From a memory allocation point of view: 3/ is also the best (only needed .so files are loaded into memory)

No, I'm not so convinced 2/ (which is, AFAIU, what you request) is the best solution. 1/ or 3/ seem better to me. Obviously, 3/ is not a valid solution today. As every day brings its load of bug fixes, enhancements... people willing to ship need to build their apps on something more rock solid. That's definitively a limitation for 3/ (until wine 1.0 is ready).

So my proposal would be:

Michael then explained that Deneba ships canvas as an executable + libcv7.so. Here libcv.so is just libwine with the name and the soname changed (in the configure scripts...),
I think that having a ton of little dll's all over for wine is probably not good for developers since it will introduce a bunch of linking problems, and cause more hassles creating installers for new apps and worrying about .so files loading properly, etc. This approach would introduce a benefit though, because we won't have to include all the extra dll's in our distribution, which will allow for smaller installers and faster downloads. It also allows us to fix a problem in a particular dll and distribute just that dll.

In our case, we only need 4 .so so it would probably be perfectly acceptable to have them all separate and name each one something like libcomdlg32cv7.so

Actually, I think that 3 is the best solution for today because it allows you to easily distribute the fixes to your app.
And Michael changed his mind for the proposal 3/.

2. Wine 1.0

11�May�2000�-�15�May�2000 (42 posts) Archive Link: "RFC: Wine 1.0"

People: Jutta Wrage,�Jeff Tranter,�Alexandre Julliard,�,�Ove Kaaven,�Francois Gouget,�J�rg Mayer,�Jeremy White,�Gav State,�Michael Cardenas,�Patrik Stridvall,�Marcus Meissner

Jeremy White fired a great discussion:
Given the amount of progress Wine has made over the past year, it seems (to me anyway) that the time may be appropriate to try for Wine version 1.0.

I was hoping to spark a conversation on this topic, in two basic areas:

I'll start with my personal list:

Several parallels discussion spread from this first post.

Many contributed to the wish list:

Alexandre Julliard gave his point of view:
I think we definitely want to make a 1.0 release. Not because of marketing reasons, but because our end goal is an emulator that works for everybody, not only for developers; and this will require at some point that we stop adding features and concentrate for a while on stabilizing the code.

As to the features we want in 1.0, here is my personal list:

The major point for the release after 1.0 should IMO be a better desktop integration by making it possible to use a standard toolkit; ideally a modular toolkit interface, but even support for only a single toolkit (probably GTK) would be good enough.

Another threadlet discussed the development process to be used: Alexandre Julliard explained the Wine 1.0 release process:
The release process I envision would be like this: once all the features that we want in 1.0 are in place, I'll make a 0.9 release which marks the feature freeze; from then on, only bug fixes will be allowed into the tree, until we consider it stable enough to call 1.0. There will _not_ be a separate unstable branch until after 1.0 is out; otherwise developers will continue working on the unstable branch and the bugs won't get fixed.
and answered for later versions (some people - Patrik Stridvall, Ove Kaaven - discussed different strategies for core DLLs (like kernel...) and non core DLLs - like commctrl):
The stable version is maintained as a CVS branch, where only bug fixes are accepted. Once enough changes have been committed we can make 1.0.1, 1.0.2 etc. releases while development continues on the 1.1 (main) branch.

I'm not sure what you mean about core/non-core dlls; all dlls will be part of the same release process (i.e. stabilized at the same time), though of course changes to non-core dlls have a better chance of being accepted in the stable release, simply because they can break less things.

Another important threadlet included the discussion of what the driving factor(s) for Wine 1.0 shall be. Some folks asked rather for:

Alexandre Julliard gave his interpretation of it:
In fact a solid Wine 1.0 is more important for companies than end-users; most users will be happy if their favorite app works, no matter how ugly the underlying implementation is, and no matter whether it is called 1.0 or not. But companies that want to ship their apps on top of Wine need a solid foundation to build upon, and this is what 1.0 must mean. Of course this will also mean less bugs for end-users, because it will be easier to fix bugs without breaking everything; but the goal of 1.0 is not to run 100% of the apps out there, nor even 50%. It is to run a few apps well enough to show that our design will allow adding support for more apps later on.

You'll notice that there are no high-level features like common controls or OLE in my list. This is not because they are not important; but they are not mandatory for 1.0. We can perfectly ship 1.0 with, say, a broken treeview control, as long as this doesn't impact our set of "certified" apps; we can always put a corrected version in 1.0.1. But we cannot ship 1.0 with broken window management or address space separation, because this is not something you can retrofit after 1.0; so it has to go in before.

Another threadlet covered the tools to be used to help the effort towards Wine 1.0. Lots of people requested solid WineHQ, CVS and mailing list servers (you bet!), and some people suggested the use of BitKeeper. The BitKeeper's "your privacy or your money" motto offended Alexandre:
My problem with their license is that I consider that privacy is a right, not something that you should have to buy. A tool that is designed to publish a trace of everything you do is IMO wrong from a moral standpoint, and so I refuse to use it. For me it's a question of principle.

3. WineHQ application database

12�May�2000 (2 posts) Archive Link: "Application Database"

People: Doug Ridgway,�,�Douglas Ridgway

Christopher Michael Morgan asked about the status of the application database on WineHQ. Douglas Ridgway answered:
It broke during an upgrade. I turned it off to stop the flood of CGI errors in my inbox, and was hoping to have it up again within a couple of days. Unfortunately, as you know, it's been longer than that. I'll try and work something out so that at least queries function.
Which he did, you can no again browse the application database (however writing to it is still disabled).

�

�

�

�

�

�

Sharon And Joy
�

Kernel Traffic is grateful to be developed on a computer donated by Professor Greg Benson and Professor Allan Cruse in the Department of Computer Science at the University of San Francisco. This is the same department that invented FlashMob Computing. Kernel Traffic is hosted by the generous folks at kernel.org. All pages on this site are copyright their original authors, and distributed under the terms of the GNU General Public License version 2.0.