Remove parts that have been moved already in the Development Guide.
This commit is contained in:
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
|
components are compatible. Hence, in the next section, we will examine
|
||||||
several legal issues.
|
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
|
IV. File Format Conversion
|
||||||
|
|
||||||
|
@ -405,12 +251,6 @@ import winmm
|
||||||
If you need to list multiple DLLs, then the import specification can
|
If you need to list multiple DLLs, then the import specification can
|
||||||
appear multiple times, one line per imported DLL.
|
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
|
VII. DLLs
|
||||||
|
|
||||||
As mentioned in the introduction, Wine allows you to execute windows
|
As mentioned in the introduction, Wine allows you to execute windows
|
||||||
|
@ -787,262 +627,6 @@ CONTRIBUTERS:
|
||||||
Jeremy White <jwhite@codeweavers.com>
|
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>
|
From: Damyan Ognyanoff <Damyan@rocketmail.com>
|
||||||
Subject: Re: Wine MFC info request
|
Subject: Re: Wine MFC info request
|
||||||
|
|
||||||
|
@ -1287,15 +871,3 @@ MFC
|
||||||
|
|
||||||
Regards
|
Regards
|
||||||
Damyan.
|
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