Remove parts that have been moved already in the Development Guide.
This commit is contained in:
Dimitrie O. Paun
Alexandre Julliard
parent
c4aa073705
commit
dec35a3575
|
|
@ -110,160 +110,6 @@ from several sources and you need to ensure that the licenses for the
|
|||
components are compatible. Hence, in the next section, we will examine
|
||||
several legal issues.
|
||||
|
||||
II. Legal Issues
|
||||
|
||||
Disclaimer! I am not a lawyer. The purpose of this section is to make
|
||||
you aware of potential legal problems. Be sure to read your licenses
|
||||
and to consult your attorney.
|
||||
|
||||
During the compilation of your program, you will be combining code
|
||||
from several sources: your code, WineLib code, code from your vendor's
|
||||
DLLs (if any), and Microsoft MFC code (if used). As a result, you must
|
||||
ensure that the licenses of all code sources are obeyed. What you are
|
||||
allowed and not allowed to do can vary depending on how you compile
|
||||
your program and if you will be distributing it. For example, if you
|
||||
are releasing your code under the GPL, you cannot link your code to
|
||||
MFC code because the GPL requires that you provide ALL sources to your
|
||||
users. The MFC license forbids you from distributing the MFC source so
|
||||
you can not comply with the GPL license except by not distributing you
|
||||
program. On the other hand, if your code is released under the LGPL,
|
||||
you cannot statically link your program to MFC and distribute it, but
|
||||
you can dynamically link your LGPL code and MFC code and distribute
|
||||
it.
|
||||
|
||||
Wine/WineLib is distributed under an X11-like license. It places few
|
||||
restrictions on the use and distribution of Wine/WineLib code. I doubt
|
||||
the Wine license will cause you any problems. On the other hand, MFC
|
||||
is distributed under a very restrictive license and the restrictions
|
||||
vary from version to version and between service packs.
|
||||
|
||||
If you plan on using MFC, there are three hurdles to legally using
|
||||
MFC. The first hurdle is how to legally get MFC source code on your
|
||||
computer. MFC source code comes as a part of Visual Studio. The
|
||||
license for Visual Studio implies it is a single product that can not
|
||||
be broken up into its components. The cleanest way to get MFC on your
|
||||
system is to use a dual boot Linux box with the windows partition
|
||||
visible to the Linux OS. Boot into windows and install Visual
|
||||
Studio. Since Visual Studio is installed on the computer, you have not
|
||||
broken it into its components. There may be other solutions, but I
|
||||
think this is the easiest.
|
||||
|
||||
FIXME: quote relevant sections of EULA in above paragraph.
|
||||
|
||||
The second hurdle for MFC is the legality of compiling MFC on a
|
||||
non-Microsoft operating system. This varies with the version of MFC.
|
||||
|
||||
MFC license from Visual Studio 6.0:
|
||||
|
||||
1.1 General License Grant. Microsoft grants to you as an
|
||||
individual, a personal, nonexclusive license to make and use
|
||||
copies of the SOFTWARE PRODUCT for the sole purposes of designing,
|
||||
developing, and testing your software product(s) that are designed
|
||||
to operate in conjunction with any Microsoft operating system
|
||||
product. [Other unrelated stuff deleted.]
|
||||
|
||||
So it appears you cannot compile MFC for WineLib using this
|
||||
license. On the other hand, Visual Studio 6.0 service pack 3 (Visual
|
||||
Studio 5.0 is similar):
|
||||
|
||||
1.1 General License Grant. Microsoft grants to you as an
|
||||
individual, a personal, nonexclusive license to make and use
|
||||
copies of the SOFTWARE PRODUCT for the purpose of designing,
|
||||
developing, and testing your software product(s). [Other unrelated
|
||||
stuff deleted]
|
||||
|
||||
So it appears you can compile MFC for WineLib using this license.
|
||||
|
||||
The third hurdle is your legal right to distribute an MFC
|
||||
library. Check the relevant section of the license on redistributables
|
||||
and your redistribution rights. As I read the license, you only have
|
||||
the right to distribute binaries of the MFC library if it has no debug
|
||||
information and if you distribute it with an application that provides
|
||||
significant added functionality to the MFC library.
|
||||
|
||||
FIXME: quote relevant sections of EULA in above paragraph.
|
||||
|
||||
Once you have examined the licenses for all of the sources used in
|
||||
compiling your program and have decided you can legally compile you
|
||||
program using WineLib, you should probably experiment with your
|
||||
program running under Wine to determine how much work will be involved
|
||||
in the port. The next section will give advice on estimating the
|
||||
amount of work required for porting your program to WineLib.
|
||||
|
||||
III. How Much Work?
|
||||
|
||||
Wine and WineLib use the same functions to implement the windows API;
|
||||
hence, if your program correctly runs under Wine, it should run under
|
||||
WineLib. However, Wine/WineLib is incomplete; you may have trouble
|
||||
running your program under Wine. Many people have successfully run many
|
||||
programs under Wine, so there is a good chance you will have no
|
||||
trouble.
|
||||
|
||||
Wine executes the binary program that was compiled for a windows
|
||||
operating system. There are differences between the windows operating
|
||||
system and Unix/Linux operating systems. For example, in Windows 95
|
||||
and Windows 98, the program has direct access to the hardware. A copy
|
||||
protection program that you purchased for your windows executable may
|
||||
use direct hardware access to write data to the disk. Hence, you may
|
||||
need to disable the copy protection in order to test your executable
|
||||
under Wine.
|
||||
|
||||
As a specific example, CrypKey is a copy protection program we use at
|
||||
Lumin Software. Our program does not execute under Wine with the copy
|
||||
protection enabled. We disabled the copy protection, recompiled the
|
||||
windows executable, and our program works fine. CrypKey also works for
|
||||
Windows NT where it creates a service. Using Wine with the --winver
|
||||
nt40 option "almost" gets the our program working with copy
|
||||
protection. At a later date, we intend to either implement the system
|
||||
calls in Wine that are missing for CrypKey or to use another copy
|
||||
protection program that does work under Linux.
|
||||
|
||||
During the execution of your program, Wine prints error messages to
|
||||
standard error. These error messages include "stubs", which are
|
||||
windows API functions that have not been completely
|
||||
implemented. Depending on the system call, these could be harmless
|
||||
or crash your program. Most of the common windows API functions have
|
||||
already been implemented, so you should have no missing API functions
|
||||
or only a few missing functions. If you intend to continue with the
|
||||
port to WineLib, you will need to implement these API
|
||||
functions. After running your program for a while, you should have a
|
||||
good feel for the number of windows API functions that you need to
|
||||
implement.
|
||||
|
||||
FIXME: give info on Wine command line options to control error
|
||||
messages.
|
||||
|
||||
During the compilation of Wine, you can control the amount of error
|
||||
messages and debug information that will be be generated by Wine and
|
||||
WineLib. For the version released to your customers, you may want to
|
||||
use the following command line to configure the Wine/WineLib
|
||||
libraries.
|
||||
|
||||
./configure --disable-debug --disable-trace
|
||||
|
||||
The option --disable-debug compiles out all debugging messages and the
|
||||
option --disable-trace compile out TRACE messages. [2]
|
||||
|
||||
It is not necessary for you to implement the entire documented
|
||||
behavior of an API function in order to get your program to work. For
|
||||
example, many API functions have pointer parameters that are NULL in
|
||||
the common cases. If you always call the function with a NULL pointer
|
||||
for the default behavior, you can save yourself some effort by
|
||||
implementing a function that only works for the NULL pointer
|
||||
parameter. If you do this, make sure you test if the parameter is
|
||||
non-null and issue a warning for the non-null case. Also document in
|
||||
the source that the API function is incomplete.
|
||||
|
||||
FIXME: give info on the FIXME (macro/function?) for partially
|
||||
implemented API functions.
|
||||
|
||||
Once you have implemented an API function, submit the change back to
|
||||
the Wine project so the next person to need the same function does not
|
||||
need to repeat your work. Remember, someone else wrote all of the
|
||||
other API functions that you are using, so you are benefitting from
|
||||
their work. Let other people benefit from your work as well. If you
|
||||
work for a company, you may need your company's permission to "give
|
||||
away" your work.
|
||||
|
||||
IV. File Format Conversion
|
||||
|
||||
|
|
@ -405,12 +251,6 @@ import winmm
|
|||
If you need to list multiple DLLs, then the import specification can
|
||||
appear multiple times, one line per imported DLL.
|
||||
|
||||
VI. Compiling A Win32 Program With Resources
|
||||
|
||||
FIXME: to be continued.
|
||||
Describe wrc.
|
||||
Go through hello world example 3.
|
||||
|
||||
VII. DLLs
|
||||
|
||||
As mentioned in the introduction, Wine allows you to execute windows
|
||||
|
|
@ -787,262 +627,6 @@ CONTRIBUTERS:
|
|||
Jeremy White <jwhite@codeweavers.com>
|
||||
|
||||
|
||||
From: Ian Schmidt <ischmidt@cfl.rr.com>
|
||||
Subject: Re: WineLib and MFC
|
||||
|
||||
"Wilbur N. Dale" wrote:
|
||||
|
||||
> What is the status of MFC under WineLib?
|
||||
|
||||
I don't know precisely. Corel has done more MFC work than anyone (all
|
||||
of their applications which they are porting are MFC-based), and
|
||||
reportedly they have MFC itself compiled. I was just trying to get a
|
||||
moderately simple MFC-using app to compile, with moderate success
|
||||
(there are still some problems with MFC's headers after my patch, but
|
||||
at least they don't appear to be Wine's fault :) I did not try to
|
||||
compile MFC itself.
|
||||
|
||||
> Which versions of MFC, if any?
|
||||
|
||||
I have no idea what version Corel uses. As noted in my patch, I was
|
||||
fiddling with the headers for MFC 6 (from Visual C++ 6.0 Service Pack
|
||||
3). Most of the stuff my patch addressed was for newer IE 5-related
|
||||
features, so I'd guess MFC 5 (VC++ 5.0) is likely what they used.
|
||||
|
||||
> Is there any documentation on how to compile MFC for WineLib? If so
|
||||
> where?
|
||||
|
||||
Not that I know of.
|
||||
|
||||
> I have started to compile programs using WineLib (hello.c last
|
||||
> Sunday) and expect to be ready to start compiling MFC in a couple of
|
||||
> weeks. If documentation is not available on compiling MFC, I am
|
||||
> willing to write it.
|
||||
|
||||
Documentation would be a Good Thing, as WineLib in general is grossly
|
||||
underdocumented right now. Here's a few tips I discovered to get you
|
||||
started:
|
||||
|
||||
- First off, run all the MFC headers (and source too if you try it)
|
||||
through a utility to strip out the DOS carriage returns. They cause
|
||||
havoc with GCC when it sees one after a line that ends with a \ (and
|
||||
MFC has many macros in it's headers that meet that description). If
|
||||
you don't have one, do a Google search on "fromdos" and you should
|
||||
locate some source (or it's fairly easy to make your own).
|
||||
|
||||
- Use GCC 2.95.2, and the -fpermissive flag to make it less picky.
|
||||
2.95.2 has some VC++-compatibility features that Corel paid for, and I
|
||||
believe more are forthcoming in future GCCs.
|
||||
|
||||
- Use -I to add whereever you have the MFC headers at to your include
|
||||
path, as MFC apps typically use #include <> to access them rather than
|
||||
"".
|
||||
|
||||
- Be prepared to have to rename and/or symlink headers, unless you
|
||||
compile on a case-insensitive filesystem :)
|
||||
|
||||
- When you make install Wine it seems not to include all it's headers
|
||||
in /usr/local/include/Wine. To have any chance at getting MFC going
|
||||
you'll want to use -I to add the include/ directory from the Wine
|
||||
source tarball to the path so it can grab everything.
|
||||
|
||||
Sorry I can't help you more, but good luck!
|
||||
|
||||
-Ian Schmidt
|
||||
ischmidt@cfl.rr.com
|
||||
|
||||
|
||||
From: Jeremy White <jwhite@codeweavers.com>
|
||||
Subject: Re: RFC: Wine 1.0
|
||||
|
||||
"Wilbur N. Dale" wrote:
|
||||
> > Further, we have successfully built MFC after making only
|
||||
> > a modest set of changes to it, even with older
|
||||
> > versions of g++.
|
||||
>
|
||||
> Lumin Software is about to use WineLib to port a window program to linux. A
|
||||
> couple of years ago we thought we had to make a modification to MFC for one
|
||||
> of our projects and we had problems getting MFC to compile under MS Visual C++.
|
||||
> After much wailing and gnashing of teeth, we gave up and did things another
|
||||
> way. After this bad experience, we were wondering --- approximately how many
|
||||
> man-hours did you spend compiling and changing MFC ?
|
||||
|
||||
Urk. I misspoke. None of the developers here that I thought
|
||||
had working versions of MFC with Wine have working versions any
|
||||
longer. So, it may be a bit trickier than I led you to believe.
|
||||
|
||||
We have it working pretty reliably with TWine, but not
|
||||
quite so cleanly (yet) with Wine. However, it really shouldn't
|
||||
be too difficult, and this is what I can remember of the process:
|
||||
|
||||
1. If you use a very modern version of gcc (2.95.2 or higher),
|
||||
I believe you will need to add the -relaxed flag to
|
||||
have any hope of compiling.
|
||||
|
||||
2. If you use an earlier version of gcc, you will need to
|
||||
adjust the many anonymous structs/unions that MFC supplies.
|
||||
We prefer this approach, because requiring very
|
||||
modern gcc implementations seems harsh to us.
|
||||
|
||||
3. You will need to adjust for the many type differences
|
||||
between MFC intrinsic types and the types supplied by Wine.
|
||||
For example, I believe that MFC expects a HANDLE to
|
||||
be compatible with certain scalar types, (and it is
|
||||
under Windows/VC, but is not with Wine/gcc).
|
||||
|
||||
4. The key procedure: add many -DNO_XXX flags to the
|
||||
makefile. If you start with Microsofts make file
|
||||
for MFC, convert it into a Wine makefile, and then turn
|
||||
on many of the flags they list there (of the form -DNO_XXX),
|
||||
your life will get much easier. Once you get it working
|
||||
with a few -DNO_XXX flags, you can go back and add them
|
||||
back in.
|
||||
|
||||
5. The best resource: you need someone who knows C++ very,
|
||||
very well. You occassionaly run into very obscure C++
|
||||
problems where MS has extended the C++ standard and
|
||||
gcc has not. It really helps to have a guru on hand
|
||||
when you hit those.
|
||||
|
||||
|
||||
I hope this helps. Sorry for the earlier deceptive post.
|
||||
|
||||
Jeremy
|
||||
|
||||
From: Gavriel State <gav@magmacom.com>
|
||||
Subject: Re: MFC questions
|
||||
|
||||
"Wilbur N. Dale" wrote:
|
||||
|
||||
> 1. Compile MFC. Several years ago we (Lumin Software) tried to
|
||||
> compile MFC. The attempt failed and we found another way to do what
|
||||
> we wanted. MS documentation states that compiling MFC was
|
||||
> deliberately made difficult. Considering my experience with stuff
|
||||
> they call "easy" I am not looking forward to compiling MFC. We are
|
||||
> currently using Visual Studio 5 for windows development.
|
||||
|
||||
At Corel, we had MFC compiled and running sample apps in WineLib in
|
||||
late 1998. It's mostly a question of the Wine headers, which weren't
|
||||
originally up to snuff. We did quite a bit of work on them, and most
|
||||
of those changes have been contributed back to WineHQ, so it should be
|
||||
pretty easy now. The other thing that was a big deal was getting the
|
||||
startup code working properly - since MFC needs to initialize static
|
||||
data *after* WineLib gets initialized. I believe that that issue has
|
||||
been addressed now on the WineHQ side with some of the work done on
|
||||
the .spec file tools recently.
|
||||
|
||||
-Gav
|
||||
|
||||
--
|
||||
Gavriel State
|
||||
CEO
|
||||
TransGaming Technologies Inc.
|
||||
gav@transgaming.com
|
||||
|
||||
From: Jeremy White <jwhite@codeweavers.com>
|
||||
Subject: Re: MFC questions
|
||||
|
||||
"Wilbur N. Dale" wrote:
|
||||
[snip]
|
||||
> 1. Compile MFC. Several years ago we (Lumin Software) tried to
|
||||
> compile MFC. The attempt failed and we found another way to do what
|
||||
> we wanted. MS documentation states that compiling MFC was
|
||||
> deliberately made difficult. Considering my experience with stuff
|
||||
> they call "easy" I am not looking forward to compiling MFC. We are
|
||||
> currently using Visual Studio 5 for windows development.
|
||||
|
||||
Wilbur, I personally think that this is the 'right' approach, although
|
||||
approach #2 may prove faster.
|
||||
|
||||
Despite your previous experience, and despite my earlier incorrect
|
||||
statements, I think that this is simpler than you fear. It's one of
|
||||
those tasks that's darkest before the storm - you spend all of your
|
||||
energy getting all the include files to work. Once you have *one*
|
||||
object file, the rest go much more quickly (alright, getting it to
|
||||
link is also a hairball of a job, but it's tractable <g>).
|
||||
|
||||
If you're not in a hurry, getting MFC to compile, and having a
|
||||
documented procedure for compiling it is on our agenda for the
|
||||
relatively near future (see the Wine 1.0 task list).
|
||||
|
||||
Jer
|
||||
|
||||
p.s. Stick with Visi C++ 5. IMHO its MFC license is cleaner than that
|
||||
of VC 6.
|
||||
|
||||
From: Gavriel State <gav@magmacom.com>
|
||||
Subject: The MSVC++ 6.0 license
|
||||
|
||||
Jeremy White wrote:
|
||||
> p.s. Stick with Visi C++ 5. IMHO its MFC license is cleaner than that
|
||||
> of VC 6.
|
||||
|
||||
Actually, I just picked up a copy of MSVC 6.0 and it appears that they
|
||||
changed the license between the original release and the Service Pack
|
||||
3 release - they removed the bit in section 1.1 about requiring that
|
||||
you be developing your software product only for use with a Microsoft
|
||||
OS. In any case, even the original license explicitly says that the
|
||||
MFC redistribution rights are *in addition* to the usage rights in
|
||||
section 1.1.
|
||||
|
||||
The relevant portion of the original EULA:
|
||||
|
||||
1.1 General License Grant. Microsoft grants to you as an individual, a
|
||||
personal, nonexclusive license to make and use copies of the SOFTWARE
|
||||
PRODUCT for the sole purposes of designing, developing, and testing your
|
||||
software product(s) that are designed to operate in conjunction with
|
||||
any Microsoft operating system product. [Other unrelated stuff deleted]
|
||||
|
||||
>From the SP3 EULA:
|
||||
|
||||
3. Section 1.1 of the EULA is deleted in its entirety and replaced
|
||||
with the following:
|
||||
|
||||
1.1 General License Grant. Microsoft grants to you as an individual, a
|
||||
personal, nonexclusive license to make and use copies of the SOFTWARE
|
||||
PRODUCT for the purpose of designing, developing, and testing your
|
||||
software product(s). [Other unrelated stuff deleted]
|
||||
|
||||
Disclaimer - I am not a lawyer, but I've spent lots of time with them
|
||||
investigating software licenses.
|
||||
|
||||
-Gav
|
||||
|
||||
--
|
||||
Gavriel State
|
||||
CEO
|
||||
TransGaming Technologies Inc.
|
||||
gav@transgaming.com
|
||||
|
||||
From: Damyan Ognyanoff <Damyan@rocketmail.com>
|
||||
Subject: Need a hint
|
||||
|
||||
Hi,
|
||||
|
||||
I manage to build mfc42 as .so library and a application using it (as
|
||||
a .so library too). I execute it using simple loader which is linked
|
||||
to Wine and I load my application in it's WinMain routine. The
|
||||
problem is how clearly to unload mfc and my application (to invoke
|
||||
mfc's destructors before loader is terminated) All is fine except that
|
||||
there is a "zombi" reference to code in shared library which is
|
||||
invoked in Wine code and generate GPF. debugger stops somewhere in
|
||||
aplication's InitInstance !!! - and the stack is broken so I can't
|
||||
catch where exactly the problem is. Any hints are welcome. I'm using
|
||||
Wine-2000517 shapshot downloaded form Wine.datapary.no
|
||||
|
||||
TNX.
|
||||
|
||||
Damyan
|
||||
p.s.
|
||||
If any of You is interested in details I can share my
|
||||
experience.
|
||||
|
||||
WND comment:
|
||||
Francois Gouget <fgouget@psn.net> has been doing a lot of work in
|
||||
the headers of wine. It should be a lot easier to compile using
|
||||
C++ now and to compile MFC. Many of the actions needed in the
|
||||
following email are not needed any more.
|
||||
|
||||
From: Damyan Ognyanoff <Damyan@rocketmail.com>
|
||||
Subject: Re: Wine MFC info request
|
||||
|
||||
|
|
@ -1287,15 +871,3 @@ MFC
|
|||
|
||||
Regards
|
||||
Damyan.
|
||||
|
||||
LocalWords: WineLib HOWTO Jul vs DLLs DLL MFC NT FIXME CrypKey Kenonic API TM
|
||||
LocalWords: Codewright NE PE WinMain GPL LGPL EULA nonexclusive winver nt dos
|
||||
LocalWords: redistributables unix tr CR LF gcc libtest winebuild pic fPIC dll
|
||||
LocalWords: guiexe init cuiexe lwine lncurses lm lutil ldl wav winmm wrc lcc
|
||||
LocalWords: dllExamples WindowsExeWindowsDLL WindowsExeWineDLL WineExeWineDLL
|
||||
LocalWords: WineExeWindowsDLL Borland URL's cd distclean DllMain winemain exe
|
||||
LocalWords: winedll cdecl WINEbirthDay str WINEfullName WINEbirthday libtool
|
||||
LocalWords: proost conf LD libwinedll Gouget docs dumpbin ConstString Lumin
|
||||
LocalWords: pWINEfullName LoadLibrary GetProcAddress hiddenWinedll BV HW dlls
|
||||
LocalWords: Zandheuvel Oosterhout linkers executables runtime ntdll sym Wl
|
||||
LocalWords: DSTRICT REENTRANT rpath Bsymbolic makefile multi
|
||||
|
|
|
|||
Loading…
Reference in New Issue