From dec35a3575b27238a553d53c225defe0d7854c21 Mon Sep 17 00:00:00 2001 From: "Dimitrie O. Paun" Date: Tue, 12 Nov 2002 02:12:14 +0000 Subject: [PATCH] Remove parts that have been moved already in the Development Guide. --- documentation/HOWTO-winelib | 428 ------------------------------------ 1 file changed, 428 deletions(-) diff --git a/documentation/HOWTO-winelib b/documentation/HOWTO-winelib index 62410996faf..25c7df7eebb 100644 --- a/documentation/HOWTO-winelib +++ b/documentation/HOWTO-winelib @@ -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 -From: Ian Schmidt -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 -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 -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 -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 ). - -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 -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 -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 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 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