HOWTO-winelib

Dimitrie O. Paun dpaun at rogers.com
Thu Nov 7 22:13:55 CST 2002


ChangeLog
  Remove parts that have been moved already in the Development Guide.

Index: documentation/HOWTO-winelib
===================================================================
RCS file: /var/cvs/wine/documentation/HOWTO-winelib,v
retrieving revision 1.6
diff -u -r1.6 HOWTO-winelib
--- documentation/HOWTO-winelib	2 Feb 2002 18:03:55 -0000	1.6
+++ documentation/HOWTO-winelib	20 Sep 2002 18:02:47 -0000
@@ -110,160 +110,6 @@
 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 @@
 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 @@
     Jeremy White <jwhite at codeweavers.com>
 
 
-From: Ian Schmidt <ischmidt at 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 at cfl.rr.com
-
-
-From: Jeremy White <jwhite at 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 at 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 at transgaming.com
-
-From: Jeremy White <jwhite at 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 at 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 at transgaming.com
-
-From: Damyan Ognyanoff <Damyan at 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 at 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 at rocketmail.com>
 Subject: Re: Wine MFC info request
 
@@ -1287,15 +871,3 @@
 
 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 



-- 
Dimi.




More information about the wine-patches mailing list