ReceiveTempSMS
/
Sweden-Number
1
0
Fork 0
Code Issues Pull Requests Releases Wiki Activity

Remove a bunch of dummy and/or obsolete info from the Winelib 

Developers Guide.
This commit is contained in:
Dimitrie O. Paun 2004-01-28 20:07:59 +00:00 committed by Alexandre Julliard
parent 47c13f537c
commit 6a748376ef
6 changed files with 20 additions and 90 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

1
documentation/Makefile.in
View File

@ -43,7 +43,6 @@ WINELIB_USER_SRCS = \
winelib-bindlls.sgml \
winelib-intro.sgml \
winelib-mfc.sgml \
winelib-pkg.sgml \
winelib-porting.sgml \
winelib-toolkit.sgml

57
documentation/winelib-bindlls.sgml
View File

@ -53,7 +53,7 @@
of the functions etc. have been changed to protect the innocent).
A large Windows application includes a DLL that links to a third-party
DLL. For various reasons the third-party DLL does not work too well
under Wine. However the third-party DLL is also available for the
under Wine. However the third-party library is also available for the
Linux environment. Conveniently the DLL and Linux shared library
export only a small number of functions and the application only uses
one of those.
@ -62,8 +62,7 @@
Specifically, the application calls a function:
<programlisting>
signed short WINAPI MyWinFunc (unsigned short a, void *b, void *c,
unsigned long *d, void *e, unsigned char f, char g,
unsigned char *h);
unsigned long *d, void *e, int f, char g, unsigned char *h);
</programlisting>
and the linux library exports a corresponding function:
<programlisting>
@ -83,8 +82,7 @@ signed short MyLinuxFunc (unsigned short a, void *b, void *c,
<para>
In the simple example we want a Wine built-in Dll that corresponds to
the MyWin Dll. The spec file is <filename>MyWin.dll.spec</filename> and
looks something like this (depending on changes to the way that the
specfile is formatted since this was written).
looks something like this:
<programlisting>
#
# File: MyWin.dll.spec
@ -102,10 +100,9 @@ signed short MyLinuxFunc (unsigned short a, void *b, void *c,
# End of file
</programlisting>
Notice that the arguments are flagged as long even though they are
smaller than that.
Notice also that we do not specify an initial function. With this
example we will link directly to the Linux shared library whereas
with the ODBC example we will load the Linux shared library dynamically.
smaller than that. With this example we will link directly to the
Linux shared library whereas with the ODBC example we will load the
Linux shared library dynamically.
</para>
<para>
In the case of the ODBC example you can see this in the file
@ -113,23 +110,17 @@ signed short MyLinuxFunc (unsigned short a, void *b, void *c,
</para>
</sect1>
<sect1 id="bindlls-cxx-apis">
<title id="bindlls-cxx-apis.title">How to deal with C++ APIs</title>
<para>
names are mangled, how to demangle them, how to call them
</para>
</sect1>
<sect1 id="bindlls-wrapper">
<title id="bindlls-wrapper.title">Writing the wrapper</title>
<para>
Firstly we will look at the simple example. The main complication of
this case is the slightly different argument lists. The f parameter
does not have to be passed to the Linux function and the d parameter
(theoretically) has to be converted between unsigned long * and
unsigned short *. Doing this ensures that the "high" bits of the
returned value are set correctly. Also unlike with the ODBC example we
will link directly to the Linux Shared Library.
(theoretically) has to be converted between
<literal>unsigned long *i</literal> and <literal>unsigned short *</literal>.
Doing this ensures that the "high" bits of the returned value are set
correctly. Also unlike with the ODBC example we will link directly to
the Linux Shared Library.
<programlisting>
/*
* File: MyWin.c
@ -153,9 +144,6 @@ signed short MyLinuxFunc (unsigned short a, void *b, void *c,
#include &lt; &lt;3rd party linux header&gt; &gt;
#include &lt;windef.h&gt; /* Part of the Wine header files */
signed short WINAPI MyProxyWinFunc (unsigned short a, void *b, void *c,
unsigned long *d, void *e, unsigned char f, char g,
unsigned char *h)
/* This declaration is as defined in the spec file. It is deliberately not
* specified in terms of &lt;3rd party&gt; types since we are messing about here
* between two operating systems (making it look like a Windows thing when
@ -163,6 +151,8 @@ signed short WINAPI MyProxyWinFunc (unsigned short a, void *b, void *c,
* inconsistencies.
* For example the fourth argument needs care
*/
signed short WINAPI MyProxyWinFunc (unsigned short a, void *b, void *c,
unsigned long *d, void *e, int f, char g, unsigned char *h)
{
unsigned short d1;
signed short ret;
@ -282,22 +272,15 @@ signed short WINAPI MyProxyWinFunc (unsigned short a, void *b, void *c,
</para>
</sect1>
<sect1 id="bindlls-advanced">
<title id="binary-dlls-advanced.title">Advanced options</title>
<sect1 id="bindlls-filenames">
<title id="binary-dlls-filenames.title">Converting filenames</title>
<para>
Here are a few more advanced options.
Suppose you want to convert incoming DOS format filenames to their
Unix equivalent. Of course there is no suitable function in the true
Microsoft Windows API, but wine provides a function for just this
task and exports it from its copy of the kernel32 DLL. The function
is <function>wine_get_unix_file_name</function> (defined in winbase.h).
</para>
<sect2 id="bindlls-adv-filenames">
<title id="binary-dlls-adv-filenames.title">Converting filenames</title>
<para>
Suppose you want to convert incoming DOS format filenames to their
Unix equivalent. Of course there is no suitable function in the true
Microsoft Windows API, but wine provides a function for just this
task and exports it from its copy of the kernel32 DLL. The function
is wine_get_unix_file_name (defined in winbase.h). Use the -ikernel32
option to winemaker to link to it.
</para>
</sect2>
</sect1>
</chapter>

10
documentation/winelib-mfc.sgml
View File

@ -209,16 +209,6 @@
</para>
</sect1>
<sect1 id="mfc-using">
<title id="mfc-using.title">Using the MFC</title>
<para>
</para>
<para>
Specific winemaker options,
the configure options,
the initialization problem...
</para>
</sect1>
</chapter>
<!-- Keep this comment at the end of the file

15
documentation/winelib-pkg.sgml
View File

@ -1,15 +0,0 @@
<chapter id="packaging">
<title id="packaging.title">Packaging your Winelib application</title>
<para>
Selecting which libraries to deliver,
how to avoid interference with other Winelib applications,
how to play nice with other Winelib applications
</para>
</chapter>
<!-- Keep this comment at the end of the file
Local variables:
mode: sgml
sgml-parent-document:("winelib-user.sgml" "book" "chapter" "")
End:
-->

25
documentation/winelib-porting.sgml
View File

@ -149,31 +149,6 @@
</para>
</sect1>
<sect1 id="com-support">
<title id="com-support.title">VC's native COM support</title>
<para>
don't use it,
guide on how to replace it with normal C++ code (yes, how???):
extracting a .h and .lib from a COM DLL
Can '-fno-rtti' be of some use or even required?
</para>
</sect1>
<sect1 id="SEH">
<title id="SEH.title">SEH</title>
<para>
how to modify the syntax so that it works both with gcc's macros and Wine's macros,
is it even possible?
</para>
</sect1>
<sect1 id="others">
<title id="others.title">Others</title>
<para>
-fpermissive and -fno-for-scope,
maybe other options
</para>
</sect1>
</chapter>
<!-- Keep this comment at the end of the file

2
documentation/winelib-user.sgml
View File

@ -5,7 +5,6 @@
<!entity toolkit SYSTEM "winelib-toolkit.sgml">
<!entity mfc SYSTEM "winelib-mfc.sgml">
<!entity bindlls SYSTEM "winelib-bindlls.sgml">
<!entity packaging SYSTEM "winelib-pkg.sgml">
]>
@ -35,6 +34,5 @@
&toolkit;
&mfc;
&bindlls;
&packaging;
</book>