Wine Traffic #43 For 15�May�2000
Table Of Contents
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:
- 12 posts in 43K by Patrik Stridvall <email@example.com>
- 11 posts in 23K by Alexandre Julliard <firstname.lastname@example.org>
- 10 posts in 22K by gerard patel <email@example.com>
- 7 posts in 16K by Eric Pouech <Eric.Pouech@wanadoo.fr>
- 6 posts in 30K by Jeff Tranter <firstname.lastname@example.org>
- Full Stats
Packaging WineLib apps (and .so files)
Archive Link: "dll separation"
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:
(Ed Note: Michael's project consist of porting Canvas from Windows to
Linux using WineLib. Michael work at
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:
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.
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:
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 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:
- build your app as a single exec (libwine.a comes into play)
- build your app as an exec plus a libwine.so file.
- 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
>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:
- use 1/ until wine 1.0 ships
- use 3/ as soon as wine 1.0 exists, and build your apps on top
of it (as it's done with XFree, KDE...)
And Michael changed his mind for the proposal 3/.
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
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
Actually, I think that 3 is the best solution for today because it allows
you to easily distribute the fixes to your app.
Archive Link: "RFC: Wine 1.0"
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:
Several parallels discussion spread from this first post.
Many contributed to the wish list:
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
I was hoping to spark a conversation on this topic, in two basic
- Should we do it? (If not, why not, and when?)
- What needs to be done before we can release Wine 1.0?
I'll start with my personal list:
- All apps listed as a '5' work perfectly with Wine
(revising the apps database so that it's accurate
is a fine way to accomplish this, IMO).
- Many sample applications compile and work with Winelib 'out of
the box' (along the lines of the work that Francois Gouget is doing).
- The installation and configuration stuff is cleaner
(I think it's mostly there; I just think it needs a
little spit and polish).
- The wine server interface is standardized so that
Wine version 1.01 and version 1.1 and version 2.0
will be able to interoperate with the Wine 1.0 server.
Alexandre Julliard gave his point of view:
- Process (or address space) separation must be done (Marcus Meissner)
- Efficient printing (Marcus Meissner)
- CommDlg, Comdlg32 pair in working state (Marcus Meissner)
- Shell, Shell32 pair in working state (Marcus Meissner)
- Support and compilation of MFC available (Vivek Dasgupta,
Michael Cardenas). On this, Jeff Tranter (from Corel, replacing Gav
State who left Corel), announced that
enhancements that we contracted Cygnus to do are now complete and
should show up in the public release (I'm not sure when,
though)., and Jeremy White
further, we have
successfully built MFC after making only a modest set of changes to
it, even with older versions of g++.
- Merging back the Wine and Corel CVS tree (to ship their various
applications, Corel decorelate its own tree from Wine's, even if
modifications in both ways took place in the past six months).
- a proper Windows' free environment (J�rg Mayer)
- a complete wrc (Wine resource compiler) (Michael Cardenas had
issues with huge resources and wrc).
- better font support (which triggered again the discussion on
the True Type integration).
Another threadlet discussed the development process to be used:
Alexandre Julliard explained the Wine 1.0 release process:
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:
- (surprise) address space separation
- NT-like WOW VDMs for Win16 processes
- dll shared sections
- if possible no system structures allocated on the system heap
- better window management
- update regions calculation will get broken by address space
- rewrite of -managed mode support
- correct interfaces between dlls
- dlls only use exported APIs
- no more global variables
- functions exported from libwine.so reduced to a minimum
- proper separation of GDI and USER
- backwards compatibility
- an app built against Winelib 1.0 should work with Wine 1.1 dlls
- the other way around is not necessary (i.e. if you upgrade an
app/dll you may have to upgrade the Wine core too)
- thread-safe GDI (merge from Corel tree)
- a set of "certified" applications that work correctly
- all apps based on InstallShield should at least get
- some kind of automated regression testing, at least for
- better font handling would be nice, but this depends a lot on the X
server, so it may have to wait until more infrastructure is in place
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.
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):
Another important threadlet included the discussion of what the
driving factor(s) for Wine 1.0 shall be. Some folks asked rather for:
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
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
Alexandre Julliard gave his interpretation of it:
- a end-user oriented release (it runs application X from company
A, Y from company B and Z from company C),
- a software editor release: let companies use Wine to port their
products to Wine
- a technical oriented release: put in place the correct
foundation to build upon?
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
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.
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.
WineHQ application database
Archive Link: "Application Database"
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