From: ke...@lila.physics.sunysb.edu (Kenji Matsuoka)
Subject: Developing Wine: where to start?
organization: SUNY Stony Brook, Physics
I really really like the idea of Wine, and would love to contribute
to the development effort, but first I need to do some reading. I
know the basics of C, but I've never done system programming. I don't
know anything about Windows API. Where should I start?
From: loe...@cs.tu-berlin.de (Martin v.Loewis)
Subject: Re: Developing Wine: where to start?
content-type: text/plain; charset=iso-8859-1
organization: Technical University of Berlin, Germany
In article <41ugv4$...@abel.cc.sunysb.edu>,
Kenji Matsuoka <ke...@lila.physics.sunysb.edu> wrote:
>I really really like the idea of Wine, and would love to contribute
>to the development effort, but first I need to do some reading. I
>know the basics of C, but I've never done system programming. I don't
>know anything about Windows API. Where should I start?
This is my Wine TODO list. I posted such lists before, but because it is
outdated quickly, I hesitated to put it in a permanent location. Check item
9 if you don't like this.
It turns out that the items fall into two classes: writing source code and
writing documentation. Both are equally important, but require different
skills. When you read the items below, you can safely skip the elaborations
if you are not interested in an item.
First, I have some short-term problems. If you choose to deal with these
now, you might be finished in a couple of weeks. Post in this group if
you pick anything to avoid duplication of efforts.
1. Fix the dialog look.
Although dialogs are mostly functional now, they don't look right. Texts
are positioned wrong and items overlap. If you want to solve this problem,
you should know how dialogs are created in Windows and how they are displayed
2. Add Win95 look.
NOTE: There is already somebody working on that. I believe it's enough for
3. Add WinHelp support.
I found that an application using WinHelp and winhelp.exe exchange an
undocumented message WM_WINHELP to implement context-sensitiveness.
Investigate the parameters of this message, and have Wine send it, too.
Here, debugging Windows code seems to be a requirement.
15. Improve Winsock support
Although winsock support is already in Wine, it does not work reliably.
Find the problems, and fix them.
Next, I have some items which require a medium amount of work.
6. Add lzexpand.
LZEXPAND.DLL is a DLL that decompresses files compressed with compress.exe.
If possible, Wine should have a replacement to allow program installation.
People have mentioned that the algorithm might be patented, so some
legal research might be necessary as well.
7. Add ver.
VER.DLL does the version checking in the installation process. Again, Wine
could use a replacement to become standalone.
The documentation items don't require programming skills. Instead, a profound
knowledge of the English language is desirable. More important, the
documentation maintainers should be willing for a long term commitment to
their documentations, and update it frequently.
I think it would be best if the documents were posted into c.e.m.w. regularly.
Anybody taking such a project should contact the Wine FAQ maintainer as well.
9. Maintain the Wine TODO list.
As this is a single frequently asked question, and often changes, the TODO
list maintainer should collect all open and in-progress projects of Wine.
Developers should be encouraged to contact the TODO list maintainer if they
think a problem could need another volunteer, if they volunteer to deal with
a problem, or if they think an issue in this list is resolved.
10. Maintain the Wine Installation HOWTO.
People frequently ask how to install Wine. The maintainer of this document
should actively collect answers to this question. This is a journalistic
problem, as people often don't post the solution even if they found one.
The Installation HOWTO should list configurations known to work and those
that are known not to work.
The document is likely to be small, but changed at least as often as new
Wine releases appear. Although it is covered partially in the man page,
I still think that somebody taking care of installation only would be
helpful. As an additional service, preconfigured binaries are also welcome
by some users.
The last three items are long-term projects. Completion will take at
least a year, and it is not likely that a single person does the whole thing.
However, there is no reason not to start with it today.
11. Add OLE2.
There are several approaches to provide OLE2 support to Wine, which could
be followed independently:
a) Make Wine look that much like Windows that you can use the MS supplied
implementation (the 'native' approach). This is what Wine does now.
b) Implement just as much of OLE2 that the application thinks it is there,
but really does nothing (the 'stub' approach). This is my favourite approach,
and I intend to follow it further.
c) Provide a complete replacement of OLE2 (the 'full' approach). This is Wine's
eventual goal. Not likely to happen anytime soon.
d) Allow Wine applications to interoperate even if they are not in the same
process, or on the same machine (the 'distributed' approach). I think this
would be most interesting, although most difficult to implement.
12. Add Win32.
Win32 is the API provided by Windows NT and Windows 95. Because it is similar
to Windows 3.1 in some respects, the Wine code can be reused, for some areas.
There are still many design problems. Contact me if you want to get involved.
14. Add distribution.
Although the current approach of running several Windows programs in one
Linux process gives you best backward compatibility, one process per program
would give you the usual Unix crash protection. In this case, communication
between the several Wine instances is required. Several solutions are possible,
including communication to a remote computer. Much like 11d), this would make
Wine a better Windows than Windows :-)
Anybody is encouraged to follow up with more items for this list. Especially
welcome are commitments for any of these points, of course.
From: iia...@iifeak.swan.ac.uk (Alan Cox)
Subject: Re: Developing Wine: where to start?
references: <firstname.lastname@example.org> <email@example.com>
organization: Institute For Industrial Information Technology
In article <422kpb$...@news.cs.tu-berlin.de> loe...@cs.tu-berlin.de (Martin v.Loewis) writes:
>15. Improve Winsock support
>Although winsock support is already in Wine, it does not work reliably.
>Find the problems, and fix them.
This one may be a good one to drop back for a while. Winsock2 is about
to appear and potentially change all the rules of the game. Anyone working
on it should read the draft winsock2 spec before working at the least.
Semi related to this is doing the netdde stuff - at the moment wine with
the real DLL's traps out with unimplemented interrupts which are
the rather well documented netbios interrupt calls.
>6. Add lzexpand.
>LZEXPAND.DLL is a DLL that decompresses files compressed with compress.exe.
>If possible, Wine should have a replacement to allow program installation.
>People have mentioned that the algorithm might be patented, so some
>legal research might be necessary as well.
Do the work outside the USA, store it outside the USA, the civilised world
doesnt have software patents. Also verify the following with the lpf, but
I believe it is correc that the patent is on the compression not the
// Alan Cox // iia...@www.linux.org.uk // GW4PTS@GB7SWN.#45.GBR.EU //
Redistribution of this message via the Microsoft Network is prohibited
<A href="file:/dev/mouse">Click here to disable mouse.</A>
USENET (Users’ Network) was a bulletin board shared among many computer
systems around the world. USENET was a logical network, sitting on top
of several physical networks, among them UUCP, BLICN, BERKNET, X.25, and
the ARPANET. Sites on USENET included many universities, private companies
and research organizations. See USENET Archives.
SCO Files Lawsuit Against IBM
March 7, 2003 - The SCO Group filed legal action against IBM in the State
Court of Utah for trade secrets misappropriation, tortious interference,
unfair competition and breach of contract. The complaint alleges that IBM
made concentrated efforts to improperly destroy the economic value of
UNIX, particularly UNIX on Intel, to benefit IBM's Linux services
business. See SCO v IBM.
The materials and information included in this website may only be used
for purposes such as criticism, review, private study, scholarship, or
Electronic mail: WorldWideWeb: