Spelling and URL fixes.
This commit is contained in:
parent
32d27dc77b
commit
c28575e0e8
|
@ -455,7 +455,7 @@ child1->popup->child2->child3->wnd1->child4->wnd2->desktop.
|
|||
not obscured by other windows. If a window has the
|
||||
<constant>WS_CLIPCHILDREN</constant> style then all
|
||||
areas below its children are considered invisible.
|
||||
Similarily, if the <constant>WS_CLIPSIBLINGS</constant>
|
||||
Similarly, if the <constant>WS_CLIPSIBLINGS</constant>
|
||||
bit is in effect then all areas obscured by its siblings
|
||||
are invisible. Child windows are always clipped by the
|
||||
boundaries of their parent windows.
|
||||
|
@ -675,7 +675,7 @@ child1->popup->child2->child3->wnd1->child4->wnd2->desktop.
|
|||
Most windowing systems use a concept known as
|
||||
"focus". The window with focus gets all incoming
|
||||
keyboard messages. Focus can be changed from window
|
||||
to window by apps or by users clicking on winodws.
|
||||
to window by apps or by users clicking on windows.
|
||||
</para>
|
||||
<para>
|
||||
This is the second source of the problem. Suppose
|
||||
|
@ -738,7 +738,7 @@ child1->popup->child2->child3->wnd1->child4->wnd2->desktop.
|
|||
queues, a timer is started. When the timer goes
|
||||
off, if the focus change has not yet happened, the
|
||||
bad app has its focus taken away and all messages
|
||||
targetted at that window are skipped. When the bad
|
||||
targeted at that window are skipped. When the bad
|
||||
app finally handles the focus change message, OS/2
|
||||
will detect this and stop skipping its messages.
|
||||
</para>
|
||||
|
@ -860,7 +860,7 @@ child1->popup->child2->child3->wnd1->child4->wnd2->desktop.
|
|||
present under Intel Unix and Wine.
|
||||
</para>
|
||||
<para>
|
||||
Finally, occassionally built-in Wine DLLs implement more
|
||||
Finally, occasionally built-in Wine DLLs implement more
|
||||
features than the corresponding native Windows DLLs.
|
||||
Probably the most important example of such behavior is the
|
||||
integration of Wine with X provided by Wine's built-in USER
|
||||
|
@ -954,7 +954,7 @@ child1->popup->child2->child3->wnd1->child4->wnd2->desktop.
|
|||
<!-- FIXME: Should convert this table into a VariableList element -->
|
||||
<screen>
|
||||
ADVAPI32.DLL: 32-bit application advanced programming interfaces
|
||||
like crypto, systeminfo, security and eventlogging
|
||||
like crypto, systeminfo, security and event logging
|
||||
AVIFILE.DLL: 32-bit application programming interfaces for the
|
||||
Audio Video Interleave (AVI) Windows-specific
|
||||
Microsoft audio-video standard
|
||||
|
|
|
@ -124,7 +124,7 @@
|
|||
|
||||
<para>
|
||||
Sometimes wine installation process changes and new versions of
|
||||
Wine acccount on these changes.
|
||||
Wine account on these changes.
|
||||
This is especially true if your setup was created long time ago.
|
||||
|
||||
Rename your existing <filename>~/.wine</filename> directory
|
||||
|
@ -145,9 +145,6 @@
|
|||
<title>Check out further information</title>
|
||||
|
||||
<para>
|
||||
Check out the <ulink
|
||||
url="http://www.winehq.org/fom-meta/cache/19.html">Wine Troubleshooting Guide</ulink> on WineHQ.
|
||||
|
||||
Go to <ulink url="http://groups.google.com">Google Groups</ulink>
|
||||
and check whether some guys are smarter than you ;-)
|
||||
(well, whether they found a solution to the problem, that is)
|
||||
|
@ -263,9 +260,9 @@
|
|||
</para>
|
||||
<para>
|
||||
This will output additional information at the console
|
||||
that may be helpfull in in debugging the program. It also
|
||||
that may be helpful in debugging the program. It also
|
||||
slows the execution of program. There are some cases where
|
||||
the bug seems to dissappear when <parameter> +relay
|
||||
the bug seems to disappear when <parameter> +relay
|
||||
</parameter> is used. Please mention that in the bug report.
|
||||
</para>
|
||||
</listitem>
|
||||
|
@ -304,7 +301,7 @@
|
|||
<listitem>
|
||||
<para>
|
||||
This method is meant to allow even a total novice to
|
||||
submit a relevent trace log in the event of a crash.
|
||||
submit a relevant trace log in the event of a crash.
|
||||
</para>
|
||||
<para>
|
||||
Your computer <emphasis>must</emphasis> have perl on it
|
||||
|
@ -348,7 +345,7 @@
|
|||
<title>The Hard Way</title>
|
||||
<para>
|
||||
It is likely that only the last 100 or so lines of the
|
||||
trace are nessesary to find out where the program crashes.
|
||||
trace are necessary to find out where the program crashes.
|
||||
In order to get those last 100 lines we need to do the following
|
||||
</para>
|
||||
<orderedlist>
|
||||
|
|
|
@ -1170,7 +1170,7 @@ C:\ Root directory of primary disk drive
|
|||
<para>
|
||||
Case insensitive. Alike to Windows 9x/NT 4. This is
|
||||
the long filename filesystem you are probably used
|
||||
to working with. The filesystem bæhaviour of choice for most
|
||||
to working with. The filesystem behavior of choice for most
|
||||
programs to be run under wine. <emphasis>Probably the one
|
||||
you want!</emphasis>
|
||||
</para>
|
||||
|
@ -1889,7 +1889,7 @@ And here is a setup for Drive A, a generic floppy drive:
|
|||
<sect3>
|
||||
<title>How To Set Up?</title>
|
||||
<para>
|
||||
Reading labels and serial numbers just works automagically
|
||||
Reading labels and serial numbers just works automatically
|
||||
if you specify a <literal>"Device" =</literal> line in the
|
||||
[Drive x] section in your <filename>~/.wine/config</filename>.
|
||||
Note that the device has to exist and must be accessible by the user
|
||||
|
@ -2194,7 +2194,7 @@ And here is a setup for Drive A, a generic floppy drive:
|
|||
</para>
|
||||
<para>
|
||||
It is of course also possible to override these settings by
|
||||
explictly using Wine's <parameter>--dll</parameter>
|
||||
explicitly using Wine's <parameter>--dll</parameter>
|
||||
command-line option (see the man page for details). Some
|
||||
hints for choosing your optimal configuration (listed by
|
||||
16/32-bit DLL pair):
|
||||
|
|
|
@ -18,7 +18,7 @@
|
|||
differences between the three approaches.
|
||||
|
||||
<table>
|
||||
<title>Fonction consoles implementation comparison</title>
|
||||
<title>Function consoles implementation comparison</title>
|
||||
<tgroup cols="4" align="left">
|
||||
<thead>
|
||||
<row>
|
||||
|
@ -76,7 +76,7 @@
|
|||
Fully supported, except for the creation of a new
|
||||
console, which will be rendered on the same Unix
|
||||
terminal as the previous one, leading to
|
||||
unpredictible results.
|
||||
unpredictable results.
|
||||
</entry>
|
||||
</row>
|
||||
<row>
|
||||
|
|
|
@ -11,7 +11,7 @@
|
|||
<para>
|
||||
A problem that can happen sometimes is 'it used to work
|
||||
before, now it doesn't anymore...'. Here is a step by step
|
||||
procedure to try to pinpoint when the problem occured. This is
|
||||
procedure to try to pinpoint when the problem occurred. This is
|
||||
<emphasis>NOT</emphasis> for casual users.
|
||||
</para>
|
||||
|
||||
|
@ -115,8 +115,8 @@ make depend && make
|
|||
</screen>
|
||||
<para>
|
||||
If any non-programmer reads this, the fastest method to get
|
||||
at the point where the problem occured is to use a binary
|
||||
search, that is, if the problem occured in 1999, start at
|
||||
at the point where the problem occurred is to use a binary
|
||||
search, that is, if the problem occurred in 1999, start at
|
||||
mid-year, then is the problem is already here, back to 1st
|
||||
April, if not, to 1st October, and so on.
|
||||
</para>
|
||||
|
@ -143,7 +143,7 @@ cvs -d $CVSROOT update -D "2002-06-01 15:17:25 CST"
|
|||
If you find the patch that is the cause of the problem, you have
|
||||
almost won; report about it to
|
||||
<ulink url="http://bugs.winehq.com/">Wine Bugzilla</ulink>
|
||||
or susbscribe to wine-devel and post it there. There is a chance
|
||||
or subscribe to wine-devel and post it there. There is a chance
|
||||
that the author
|
||||
will jump in to suggest a fix; or there is always the possibility
|
||||
to look hard at the patch until it is coerced to reveal where is
|
||||
|
|
|
@ -27,7 +27,7 @@
|
|||
CVS. You will need CVS 1.9 or above. If you are coming from
|
||||
behind a firewall, you will either need a hole in the firewall
|
||||
for the CVS port (2401) or use <ulink
|
||||
url="http://www.cyclic.com/cvs/d ev-net.html">SOCKS</ulink>.
|
||||
url="http://www.cvshome.org/cyclic/cyclic-pages/unoff-socks.txt">SOCKS</ulink>.
|
||||
</para>
|
||||
</sect1>
|
||||
|
||||
|
@ -87,7 +87,7 @@ checkout -P
|
|||
<command>joe</command>, <command>ae</command>,
|
||||
<command>vi</command>),
|
||||
or by creating the file <filename>.cvsrc</filename> in your
|
||||
home directory with your favourite graphical editor like nedit, kedit,
|
||||
home directory with your favorite graphical editor like nedit, kedit,
|
||||
gedit or others.
|
||||
</para>
|
||||
<para>
|
||||
|
@ -174,7 +174,7 @@ checkout -P
|
|||
<title>Wine CVS mirror servers</title>
|
||||
|
||||
<para>
|
||||
Wine's CVS tree is mirrored at several places arround the world
|
||||
Wine's CVS tree is mirrored at several places around the world
|
||||
to make sure that the source is easily accessible. Note that not
|
||||
all servers have all repositories available, but all have at
|
||||
least the Wine source.
|
||||
|
@ -191,7 +191,7 @@ CVSROOT=:pserver:<Username>@<CVS Server>:<Server root>
|
|||
<para>
|
||||
Alternatively, you can use the -d parameter of
|
||||
<command>cvs</command> instead.
|
||||
Substitude the applicable fields from the table below.
|
||||
Substitute the applicable fields from the table below.
|
||||
</para>
|
||||
<para>
|
||||
Just do a traceroute and a ping on all servers below to find out
|
||||
|
|
|
@ -251,7 +251,7 @@ winedbg "hl.exe -windowed"
|
|||
<command>detach</command> command). Unfortunately, as the
|
||||
debugger cannot, for now, neither clear its internal
|
||||
information, nor restart a new process, the debugger, after
|
||||
detaching itself, cannot do much except being quited.
|
||||
detaching itself, cannot do much except being quitted.
|
||||
</para>
|
||||
</sect2>
|
||||
</sect1>
|
||||
|
@ -320,7 +320,7 @@ winedbg "hl.exe -windowed"
|
|||
<para>
|
||||
Get the reason for the crash. This is usually an access to
|
||||
an invalid selector, an access to an out of range address
|
||||
in a valid selector, popping a segmentregister from the
|
||||
in a valid selector, popping a segment register from the
|
||||
stack or the like. When reporting a crash, report this
|
||||
<emphasis>whole</emphasis> crashdump even if it doesn't
|
||||
make sense to you.
|
||||
|
@ -369,9 +369,9 @@ winedbg "hl.exe -windowed"
|
|||
</para>
|
||||
<para>
|
||||
Occasionally there are additional debug channels defined at the
|
||||
begining of the file in the form.
|
||||
beginning of the file in the form.
|
||||
<function>WINE_DECLARE_DEBUG_CHANNEL(<channel>);</function>
|
||||
If so the offending fuction may also uses one of these alternate
|
||||
If so the offending function may also uses one of these alternate
|
||||
channels. Look through the the function for
|
||||
<function>TRACE_(<channel>)(" ... /n");</function> and add any
|
||||
additional channels to the commandline.
|
||||
|
@ -622,7 +622,7 @@ call KERNEL.LSTRLEN
|
|||
|Ret KERNEL.74: OPENFILE() retval=0xffff ret=060f:09d8 ds=0927
|
||||
^^^^^^ HFILE_ERROR16, yes, it failed.
|
||||
|
||||
|Call USER.1: MESSAGEBOX(0x0000,0x09278376"Sie mussen Windows verlassen und SHARE.EXE laden bevor Sie Word starten.",0x00000000,0x1030) ret=060f:084f ds=0927
|
||||
|Call USER.1: MESSAGEBOX(0x0000,0x09278376"You must close Windows and load SHARE.EXE before you start Word.",0x00000000,0x1030) ret=060f:084f ds=0927
|
||||
</screen>
|
||||
<para>
|
||||
And MessageBox'ed.
|
||||
|
@ -734,8 +734,8 @@ Call KERNEL.96: FREELIBRARY(0x031f) ret=01cf:105c ds=01ff
|
|||
<para>
|
||||
Provided that segment <literal>0x0004</literal> is indeed segment
|
||||
<literal>0x1cf</literal>, we now we can use IDA (available at
|
||||
<ulink url="ftp://ftp.uni-koeln.de/pc/msdos/programming/assembler/ida35bx.zip">
|
||||
ftp://ftp.uni-koeln.de/pc/msdos/programming/assembler/ida35bx.zip</ulink>) to
|
||||
<ulink url="http://www.filelibrary.com:8080/cgi-bin/freedownload/DOS/h/72/ida35bx.zip">
|
||||
http://www.filelibrary.com:8080/cgi-bin/freedownload/DOS/h/72/ida35bx.zip</ulink>) to
|
||||
disassemble the part that caused the error. We just have to find the address of
|
||||
the call to <function>FreeLibrary()</function>. Some lines before that the
|
||||
runtime error occurred. But be careful! In some cases you don't have to
|
||||
|
@ -767,8 +767,8 @@ Call KERNEL.96: FREELIBRARY(0x031f) ret=01cf:105c ds=01ff
|
|||
<term>
|
||||
<application>IDA</application>:
|
||||
<filename>
|
||||
<ulink url="ftp://ftp.uni-koeln.de/pc/msdos/programming/assembler/ida35bx.zip">
|
||||
ftp://ftp.uni-koeln.de/pc/msdos/programming/assembler/ida35bx.zip</ulink>
|
||||
<ulink url="http://www.filelibrary.com:8080/cgi-bin/freedownload/DOS/h/72/ida35bx.zip">
|
||||
http://www.filelibrary.com:8080/cgi-bin/freedownload/DOS/h/72/ida35bx.zip</ulink>
|
||||
</filename>
|
||||
</term>
|
||||
<listitem>
|
||||
|
@ -782,8 +782,8 @@ Call KERNEL.96: FREELIBRARY(0x031f) ret=01cf:105c ds=01ff
|
|||
<term>
|
||||
<application>XRAY</application>:
|
||||
<filename>
|
||||
<ulink url="ftp://ftp.th-darmstadt.de/pub/machines/ms-dos/SimTel/msdos/asmutil/xray15.zip">
|
||||
ftp://ftp.th-darmstadt.de/pub/machines/ms-dos/SimTel/msdos/asmutil/xray15.zip</ulink>
|
||||
<ulink url="http://garbo.uwasa.fi/pub/pc/sysinfo/xray15.zip">
|
||||
http://garbo.uwasa.fi/pub/pc/sysinfo/xray15.zip</ulink>
|
||||
</filename>
|
||||
</term>
|
||||
<listitem>
|
||||
|
@ -797,8 +797,8 @@ Call KERNEL.96: FREELIBRARY(0x031f) ret=01cf:105c ds=01ff
|
|||
<term>
|
||||
<application>pedump</application>:
|
||||
<filename>
|
||||
<ulink url="http://oak.oakland.edu/pub/simtelnet/win95/prog/pedump.zip">
|
||||
http://oak.oakland.edu/pub/simtelnet/win95/prog/pedump.zip</ulink>
|
||||
<ulink url="ftp://ftp.simtel.net/pub/simtelnet/win95/prog/pedump.zip">
|
||||
ftp://ftp.simtel.net/pub/simtelnet/win95/prog/pedump.zip</ulink>
|
||||
</filename>
|
||||
</term>
|
||||
<listitem>
|
||||
|
@ -1472,7 +1472,7 @@ i => instructions (disassemble)
|
|||
x => 32 bit unsigned hexadecimal integer
|
||||
d => 32 bit signed decimal integer
|
||||
w => 16 bit unsigned hexadecimal integer
|
||||
c => character (only printable 0x20-0x7f are actuallyprinted)
|
||||
c => character (only printable 0x20-0x7f are actually printed)
|
||||
b => 8 bit unsigned hexadecimal integer
|
||||
g => GUID
|
||||
</screen>
|
||||
|
@ -1535,7 +1535,7 @@ set - fixme => turn off the 'fixme' class
|
|||
|
||||
<para>
|
||||
However, some limitation in GDB while debugging wine (see
|
||||
below) don't ppear in this mode:
|
||||
below) don't appear in this mode:
|
||||
<itemizedlist>
|
||||
<listitem>
|
||||
<para>
|
||||
|
|
|
@ -51,7 +51,7 @@
|
|||
|
||||
<para>
|
||||
The common controls have been continuously improved in the
|
||||
past. Some of the orignal structures had to be extended
|
||||
past. Some of the original structures had to be extended
|
||||
and their size changed. Most of the common control
|
||||
structures include their size as the first parameter. If a
|
||||
control gets the wrong size in a message or function a
|
||||
|
@ -63,7 +63,7 @@
|
|||
</para>
|
||||
<note>
|
||||
<para>
|
||||
Some stuctures are NOT defined in wine's COMCTL32 yet.
|
||||
Some structures are NOT defined in wine's COMCTL32 yet.
|
||||
</para>
|
||||
</note>
|
||||
|
||||
|
|
|
@ -12,9 +12,9 @@
|
|||
<para>
|
||||
Like most large scale volunteer projects, Wine is strongest in areas that are rewarding
|
||||
for its volunteers to work in. The majority of contributors send code patches either
|
||||
fixing bugs, adding new functionalty or otherwise improving the software components of
|
||||
fixing bugs, adding new functionality or otherwise improving the software components of
|
||||
the distribution. A lesser number contribute in other ways, such as reporting bugs and
|
||||
regressions, creating tests, providing organisational assistance, or helping to document
|
||||
regressions, creating tests, providing organizational assistance, or helping to document
|
||||
Wine.
|
||||
</para>
|
||||
|
||||
|
@ -34,13 +34,13 @@
|
|||
The Wine source code tree comes with a large amount of documentation in the
|
||||
<filename>documentation/</filename> subdirectory. This used to be a collection
|
||||
of text files culled from various places such as the Wine Weekly News and the wine-devel
|
||||
mailing list, but was reorganised some time ago into a number of books, each of which is
|
||||
mailing list, but was reorganized some time ago into a number of books, each of which is
|
||||
marked up using SGML. You are reading one of these books (the
|
||||
<emphasis>Wine Developer's Guide</emphasis>) right now.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
Since being reorganised, the books have been updated and extended regularly. In their
|
||||
Since being reorganized, the books have been updated and extended regularly. In their
|
||||
current state they provide a good framework which over time can be expanded and kept
|
||||
up to date. This means that most of the time when further documentation is added, it is
|
||||
a simple matter of updating the content of an already existing file. The books
|
||||
|
@ -99,7 +99,7 @@
|
|||
<title>Introduction to API Documentation</title>
|
||||
<para>
|
||||
Wine includes a large amount of documentation on the API functions
|
||||
it implements. There are serveral reasons to want to document the Win32
|
||||
it implements. There are several reasons to want to document the Win32
|
||||
API:
|
||||
<itemizedlist>
|
||||
|
||||
|
@ -119,14 +119,14 @@
|
|||
|
||||
<listItem><para>
|
||||
To provide more accurate documentation where the existing documentation
|
||||
is accendentally or deliberately vague or misleading.
|
||||
is accidentally or deliberately vague or misleading.
|
||||
</para></listitem>
|
||||
|
||||
</itemizedlist>
|
||||
</para>
|
||||
|
||||
<para>
|
||||
To this end, a semi formalised way of producing documentation from the Wine
|
||||
To this end, a semi formalized way of producing documentation from the Wine
|
||||
source code has evolved. Since the primary users of API documentation are Wine
|
||||
developers themselves, documentation is usually inserted into the source code
|
||||
in the form of comments and notes. Good things to include in the documentation
|
||||
|
@ -294,7 +294,7 @@
|
|||
<para>
|
||||
The input/output status tells the programmer whether the value will be modified
|
||||
by the function (an output parameter), or only read (an input parameter). The
|
||||
status must be enclosed in square brackets to be recognised, otherwise, or if it
|
||||
status must be enclosed in square brackets to be recognized, otherwise, or if it
|
||||
is absent, anything following the parameter name is treated as the parameter
|
||||
description. This field is case insensitive and can be any of the following:
|
||||
<command>[I]</command>, <command>[In]</command>, <command>[O]</command>,
|
||||
|
@ -352,7 +352,7 @@ BOOL WINAPI PathRelativePathToA(
|
|||
<command>FIXME</command>. Things that should be updated or addressed in the implementation
|
||||
of the function at some future date (perhaps dependent on other parts of Wine). Note
|
||||
that if this information is only relevant to Wine developers then it should probably
|
||||
be placed in the relavent code section instead.
|
||||
be placed in the relevant code section instead.
|
||||
</para></listitem>
|
||||
</orderedlist>
|
||||
</para>
|
||||
|
@ -458,7 +458,7 @@ BOOL WINAPI PathRelativePathToA(
|
|||
|
||||
<para>
|
||||
Words in all uppercase are assumed to be API constants and are highlighted. If
|
||||
you want to emphasise something in the documentation, put it in a section by itself
|
||||
you want to emphasize something in the documentation, put it in a section by itself
|
||||
rather than making it upper case.
|
||||
</para>
|
||||
|
||||
|
@ -475,7 +475,7 @@ BOOL WINAPI PathRelativePathToA(
|
|||
|
||||
<para>
|
||||
Any line starting with a single word followed by a colon (<command>:</command>)
|
||||
is assumed to be case listing and is emphasised and put in its own paragrah. This
|
||||
is assumed to be case listing and is emphasized and put in its own paragraph. This
|
||||
is most often used for return values, as in the example section below.
|
||||
</para>
|
||||
<screen>
|
||||
|
@ -516,7 +516,7 @@ BOOL WINAPI PathRelativePathToA(
|
|||
<para>
|
||||
These items are generated using the same formatting rules as described earlier. The
|
||||
only difference is the first line of the comment, which indicates to the generator
|
||||
that the documentation is supplimental and does not describe an export from the dll
|
||||
that the documentation is supplemental and does not describe an export from the dll
|
||||
being processed.
|
||||
</para>
|
||||
|
||||
|
@ -537,7 +537,7 @@ BOOL WINAPI PathRelativePathToA(
|
|||
|
||||
<para>
|
||||
Format this documentation exactly as you would a standard export. The only
|
||||
difference is the use of curly brackets to mark this documentation as supplimental.
|
||||
difference is the use of curly brackets to mark this documentation as supplemental.
|
||||
The generator will output this documentation using the name given before the
|
||||
DLL name, and will link to it from the main DLL page. In addition, if you have
|
||||
referred to the comment name in other documentation using "IExample interface",
|
||||
|
@ -1545,7 +1545,7 @@ BOOL WINAPI PathRelativePathToA(
|
|||
...</programlisting>
|
||||
</para>
|
||||
<para>
|
||||
By default, most SGML processors will autogenerate
|
||||
By default, most SGML processors will auto generate
|
||||
some generic text for the <sgmltag
|
||||
class="starttag">xref</sgmltag> link, like
|
||||
<quote>Section 2.3.1</quote>. You can use the
|
||||
|
|
|
@ -534,7 +534,7 @@ checkout -P
|
|||
<command>joe</command>, <command>ae</command>,
|
||||
<command>vi</command>),
|
||||
or by creating the file <filename>.cvsrc</filename> in your
|
||||
home directory with your favourite graphical editor like nedit, kedit,
|
||||
home directory with your favorite graphical editor like nedit, kedit,
|
||||
gedit or others.
|
||||
</para>
|
||||
</sect3>
|
||||
|
|
|
@ -175,13 +175,13 @@
|
|||
<listitem>
|
||||
<para>
|
||||
Several of the winelib based programs in the subdirectory
|
||||
programs also have internationalisation support. See the
|
||||
programs also have internationalization support. See the
|
||||
appropriate files there for reference.
|
||||
</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>Edit
|
||||
<filename>documentation/internationalisation</filename> to
|
||||
<filename>documentation/internationalization</filename> to
|
||||
show the new status.</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
|
|
|
@ -207,7 +207,7 @@ WORD cmd;
|
|||
<filename>stdout</filename>, <filename>stderr</filename>,
|
||||
<filename>stdaux</filename> and <filename>stdprn</filename>.
|
||||
Windows 16 inherits this behavior, and in fact, win16 handles
|
||||
are interchangable with DOS handles. Some nasty windows
|
||||
are interchangeable with DOS handles. Some nasty windows
|
||||
programs even do this!
|
||||
</para>
|
||||
<para>
|
||||
|
@ -363,7 +363,7 @@ XXXX > YY @ ZZZZ:ZZZZ
|
|||
< data was read from the port
|
||||
</programlisting>
|
||||
<para>
|
||||
My basic tip for interperating these logs is to pay close
|
||||
My basic tip for interpreting these logs is to pay close
|
||||
attention to the addresses of the IO instructions. Their
|
||||
grouping and sometimes proximity should reveal the presence of
|
||||
subroutines in the driver. By studying the different versions
|
||||
|
@ -450,7 +450,7 @@ int udpp_put(int udpp_base, unsigned char command)
|
|||
program to analyse the logfile and decode them futher as this
|
||||
can reveal higher level grouping of the low level routines.
|
||||
For example from the logs from my UMAX Astra 600P when decoded
|
||||
futher reveal (this is a small snippet)
|
||||
further reveal (this is a small snippet)
|
||||
</para>
|
||||
<programlisting>
|
||||
start:
|
||||
|
|
|
@ -426,7 +426,7 @@
|
|||
|
||||
<para>
|
||||
A built-in MIDI mapper can be found in dlls/winmm/midimap/. It partly
|
||||
provides the same functionnality as the Windows' one. It allows to pick up
|
||||
provides the same functionality as the Windows' one. It allows to pick up
|
||||
destination channels (you can map a given channel to a specific playback
|
||||
device channel (see the configuration bits for more details).
|
||||
</para>
|
||||
|
@ -717,7 +717,7 @@
|
|||
</listitem>
|
||||
<listitem>
|
||||
<para>
|
||||
fix the audio/video synchronisation issue
|
||||
fix the audio/video synchronization issue
|
||||
</para>
|
||||
</listitem>
|
||||
</itemizedlist>
|
||||
|
@ -817,7 +817,7 @@
|
|||
|
||||
<para>
|
||||
Note that native VIDEODISC crashes when the module is loaded, which
|
||||
occurs when the MCI procedures are initialised. Make sure that this is
|
||||
occurs when the MCI procedures are initialized. Make sure that this is
|
||||
not in the list from above. Try adding:
|
||||
mci=CDAUDIO:SEQUENCER:WAVEAUDIO:AVIVIDEO:MPEGVIDEO
|
||||
to the [options] section of the wine config file.
|
||||
|
@ -913,7 +913,7 @@
|
|||
<para>
|
||||
The API consists of the mmio* functions found in dlls/winmm/mmio.c.
|
||||
Seems to work ok in most of the cases. There's some linear/segmented
|
||||
issues with 16 bit code. There are also some bugs when writting MMIO
|
||||
issues with 16 bit code. There are also some bugs when writing MMIO
|
||||
files.
|
||||
</para>
|
||||
|
||||
|
@ -1047,7 +1047,7 @@ HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\MediaProperties\PrivatePrope
|
|||
</screen>
|
||||
a link to and .IDF file which allows to remap channels internally (for
|
||||
example 9 -> 16), to change instruments identification, event
|
||||
controlers values. See the source file dlls/winmm/midimap/midimap.c
|
||||
controllers values. See the source file dlls/winmm/midimap/midimap.c
|
||||
for the details (this isn't implemented yet).
|
||||
</para>
|
||||
</sect2>
|
||||
|
|
|
@ -65,7 +65,7 @@
|
|||
Unfortunately the layout of the virtual table is compiler
|
||||
specific, the layout of g++ virtual tables is not the same
|
||||
as that of an egcs virtual table which is not the same as
|
||||
that generated by Visual C+. There are workarounds to make
|
||||
that generated by Visual C+. There are work arounds to make
|
||||
the virtual tables compatible via padding but unfortunately
|
||||
the one which is imposed to the Wine emulator by the Windows
|
||||
binaries, i.e. the Visual C++ one, is the most compact of
|
||||
|
@ -73,7 +73,7 @@
|
|||
</para>
|
||||
<para>
|
||||
So the solution I finally adopted does not use virtual
|
||||
tables. Instead I use inline non virtual methods that
|
||||
tables. Instead I use in-line non virtual methods that
|
||||
dereference the method pointer themselves and perform the
|
||||
call.
|
||||
</para>
|
||||
|
@ -166,7 +166,7 @@ ICOM_DEFINE(IDirect3D,IUnknown)
|
|||
C. Unfortunately I don't see any way to avoid having to
|
||||
duplicate the inherited method definitions there. This time
|
||||
I could have used a trick to use only one macro whatever the
|
||||
number of parameters but I prefered to have it work the same
|
||||
number of parameters but I preferred to have it work the same
|
||||
way as above.
|
||||
</para>
|
||||
<para>
|
||||
|
@ -240,7 +240,7 @@ struct IDirect3DVtbl {
|
|||
and initialize the lpVtbl field to point to this variable.
|
||||
</para>
|
||||
<para>
|
||||
The IDirect3D_Xxx macros then just derefence the lpVtbl
|
||||
The IDirect3D_Xxx macros then just difference the lpVtbl
|
||||
pointer and use the function pointer corresponding to the
|
||||
macro name. This emulates the behavior of a virtual table
|
||||
and should be just as fast.
|
||||
|
@ -282,7 +282,7 @@ struct IDirect3DVtbl {
|
|||
<para>
|
||||
In C++ IDirect3D does double duty as both the virtual/jump
|
||||
table and as the interface definition. The reason for this
|
||||
is to avoid having to duplicate the mehod definitions: once
|
||||
is to avoid having to duplicate the method definitions: once
|
||||
to have the function pointers in the jump table and once to
|
||||
have the methods in the interface class. Here one macro can
|
||||
generate both. This means though that the first pointer,
|
||||
|
@ -300,7 +300,7 @@ struct IDirect3DVtbl {
|
|||
<para>
|
||||
Since IDirect3D does double duty, each ICOM_METHOD macro
|
||||
defines both a function pointer and a non-virtual inline
|
||||
method which dereferences it and calls it. This way this
|
||||
method which differences it and calls it. This way this
|
||||
method behaves just like a virtual method but does not
|
||||
create a true C++ virtual table which would break the
|
||||
structure layout. If you look at the implementation of these
|
||||
|
|
|
@ -76,7 +76,7 @@
|
|||
'modern' OpenGL libraries do).
|
||||
</para>
|
||||
<para>
|
||||
If the OpenGL library explicitely links in libpthread (you
|
||||
If the OpenGL library explicitly links in libpthread (you
|
||||
can check it with a <command>ldd libGL.so</command>), you
|
||||
need to force OpenGL support by starting
|
||||
<command>configure</command> with the
|
||||
|
@ -88,7 +88,7 @@
|
|||
most of the cases (glibc 2.1.x). On the other hand, we never
|
||||
got Wine to work with glibc 2.0.6. Thus, I deemed preferable
|
||||
to play it safe : by default, I suppose that the hack won't
|
||||
work and that it's the user's responsability to enable it.
|
||||
work and that it's the user's responsibility to enable it.
|
||||
</para>
|
||||
<para>
|
||||
Anyway, it should be pretty safe to build with
|
||||
|
@ -186,7 +186,7 @@ DesktopDoubleBuffered = Y
|
|||
</orderedlist>
|
||||
|
||||
<para>
|
||||
Add to this some braindead programs (using GL calls without
|
||||
Add to this some brain-dead programs (using GL calls without
|
||||
setting-up a context or deleting three time the same context)
|
||||
and you have still some work to do :-)
|
||||
</para>
|
||||
|
@ -207,7 +207,7 @@ DesktopDoubleBuffered = Y
|
|||
double buffer mode. This is implemented in
|
||||
<filename>graphics/x11drv/opengl.c</filename> (all these
|
||||
functions are part of Wine's graphic driver function
|
||||
pointer table and thus could be reimplented if ever Wine
|
||||
pointer table and thus could be reimplemented if ever Wine
|
||||
works on another Windowing system than X).
|
||||
</para>
|
||||
</listitem>
|
||||
|
@ -333,8 +333,8 @@ DesktopDoubleBuffered = Y
|
|||
a better solution than adding another autogenerated thunk file), you
|
||||
can always download anywhere on the net (it's free) a
|
||||
<filename>GLU32.DLL</filename> file (by browsing, for example,
|
||||
<ulink url="http://ftpsearch.lycos.com/">
|
||||
http://ftpsearch.lycos.com/</ulink>).
|
||||
<ulink url="http://www.dll-files.com/dllindex/index.shtml">
|
||||
http://www.dll-files.com/dllindex/index.shtml</ulink>).
|
||||
</para>
|
||||
</sect2>
|
||||
|
||||
|
|
|
@ -59,7 +59,7 @@
|
|||
</para>
|
||||
<para>
|
||||
Since wine is constantly changing due to development it is strongly
|
||||
recomended that you use cvs for patches, if you cannot use cvs for
|
||||
recommended that you use cvs for patches, if you cannot use cvs for
|
||||
some reason, you can submit patches against the latest tarball.
|
||||
To do this make a copy of the files that you will be modifying and
|
||||
<command>diff -u</command> against the old file. I.E.
|
||||
|
@ -80,8 +80,8 @@ diff -u file.old file.c > file.txt
|
|||
<itemizedlist>
|
||||
<listitem>
|
||||
<para>
|
||||
No HTML mail, since patches should be inlined and HTML turns the
|
||||
patch into garbage. Also it is considered bad netiquette as it
|
||||
No HTML mail, since patches should be in-lined and HTML turns the
|
||||
patch into garbage. Also it is considered bad etiquette as it
|
||||
uglifies the message, and is not viewable by many of the subscribers.
|
||||
</para>
|
||||
</listitem>
|
||||
|
@ -89,7 +89,7 @@ diff -u file.old file.c > file.txt
|
|||
<para>
|
||||
Only one change set per patch. Patches should address only one
|
||||
bug/problem at a time. If a lot of changes need to be made then it
|
||||
is perfered to break it into a series of patches. This makes it
|
||||
is preferred to break it into a series of patches. This makes it
|
||||
easier to find regressions.
|
||||
</para>
|
||||
</listitem>
|
||||
|
@ -126,8 +126,8 @@ code
|
|||
</listitem>
|
||||
<listitem>
|
||||
<para>
|
||||
Patches should be inlined (if you can configure your email client to
|
||||
not wrap lines), or attached as plain text attachements so they can
|
||||
Patches should be in-lined (if you can configure your email client to
|
||||
not wrap lines), or attached as plain text attachments so they can
|
||||
be read inline. This may mean some more work for you. However it
|
||||
allows others to review your patch easily and decreases the chances
|
||||
of it being overlooked or forgotten.
|
||||
|
@ -144,7 +144,7 @@ code
|
|||
<sect2 id="Inline-Attachments-with-OE">
|
||||
<title>Inline attachments with Outlook Express</title>
|
||||
<para>
|
||||
Outlook Express is notorious for mangleing attachements. Giving the
|
||||
Outlook Express is notorious for mangling attachments. Giving the
|
||||
patch a <filename>.txt</filename> extension and attaching will solve
|
||||
the problem for most mailers including Outlook. Also, there is a way
|
||||
to enable Outlook Express send <filename>.diff</filename>
|
||||
|
@ -197,7 +197,7 @@ code
|
|||
</para>
|
||||
<para>
|
||||
Make sure your patch applies to the current CVS head
|
||||
revisions. If a bunch of patches are commited to CVS that may
|
||||
revisions. If a bunch of patches are committed to CVS that may
|
||||
affect whether your patch will apply cleanly then verify that
|
||||
your patch does apply! <command>cvs update</command> is your
|
||||
friend!
|
||||
|
|
|
@ -21,7 +21,7 @@
|
|||
|
||||
<itemizedlist>
|
||||
<listitem>
|
||||
<para>How to port Wine to your favourite operating system</para>
|
||||
<para>How to port Wine to your favorite operating system</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>Why you probably shouldn't use <symbol>#ifdef MyOS</symbol></para>
|
||||
|
|
|
@ -184,7 +184,7 @@ printer=on
|
|||
</para>
|
||||
<para>
|
||||
You also need to add certain entries to the registry.
|
||||
The easiest way to do this is to customise the PostScript
|
||||
The easiest way to do this is to customize the PostScript
|
||||
driver contents of <filename>winedefault.reg</filename> (see below) and use the
|
||||
Winelib program <command>programs/regedit/regedit</command>. For
|
||||
example, if you have installed the Wine source tree in
|
||||
|
|
|
@ -464,12 +464,12 @@ winspool</><entry>wnet</><entry>x11</>
|
|||
<sect1 id="CUI-programs">
|
||||
<title>Text mode programs (CUI: Console User Interface)</title>
|
||||
<para>Text mode programs are program which output is only made
|
||||
out of text (surprise!). In Windows terminolgy, they are
|
||||
out of text (surprise!). In Windows terminology, they are
|
||||
called CUI (Console User Interface) executables, by opposition
|
||||
to GUI (Graphical User Interface) executables. Win32 API
|
||||
provide a complete set of APIs to handle this situation, which
|
||||
goes from basic features like text printing, up to high level
|
||||
functionnalities (like full screen editing, color support,
|
||||
functionalities (like full screen editing, color support,
|
||||
cursor motion, mouse support), going through features like
|
||||
line editing or raw/cooked input stream support
|
||||
</para>
|
||||
|
@ -676,7 +676,7 @@ winspool</><entry>wnet</><entry>x11</>
|
|||
This lets you pick up how many commands you want
|
||||
the console to recall. You can also drive whether
|
||||
you want, when entering several times the same
|
||||
command - potentially intertwened with others -
|
||||
command - potentially intertwined with others -
|
||||
whether you want to store all of them (tick off)
|
||||
or only the last one (tick on).
|
||||
</entry>
|
||||
|
|
|
@ -75,8 +75,8 @@
|
|||
<listitem>
|
||||
<para>
|
||||
Tests written in advance of the Wine development (possibly even
|
||||
by non Wine developpers) can also simplify the work of the
|
||||
futur implementer by making it easier for him to check the
|
||||
by non Wine developers) can also simplify the work of the
|
||||
future implementer by making it easier for him to check the
|
||||
correctness of his code.
|
||||
</para>
|
||||
</listitem>
|
||||
|
|
|
@ -12,7 +12,7 @@
|
|||
</para>
|
||||
|
||||
<para>
|
||||
This document desribes tools for handling resources within wine
|
||||
This document describes tools for handling resources within wine
|
||||
</para>
|
||||
|
||||
<sect2>
|
||||
|
|
|
@ -193,7 +193,7 @@ signed short WINAPI MyProxyWinFunc (unsigned short a, void *b, void *c,
|
|||
</para>
|
||||
<para>
|
||||
Then each of the functions simply calls the appropriate Linux function
|
||||
through the function pointer that was set up during initialisation.
|
||||
through the function pointer that was set up during initialization.
|
||||
</para>
|
||||
</sect1>
|
||||
|
||||
|
|
|
@ -32,7 +32,7 @@
|
|||
What you gain by recompiling your application with Winelib is the
|
||||
ability to make calls to Unix APIs, directly from your
|
||||
Windows source code. This allows for a better integration with the
|
||||
Unix environment than is allowed by runnning an unmodified Windows
|
||||
Unix environment than is allowed by running an unmodified Windows
|
||||
application running in Wine. Another benefit is that a Winelib
|
||||
application can relatively easily be recompiled on a non-Intel
|
||||
architecture and run there without the need for a slow software
|
||||
|
@ -398,7 +398,7 @@
|
|||
review the <filename>Makefile.in</filename> files to
|
||||
adjust the default compilation and link options set by
|
||||
winemaker. See the <xref linkend="source-analysis"
|
||||
endterm="source-analysis.title"> section for some hints.
|
||||
endterm="source-analysis.title"> section for some hints.
|
||||
</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
|
|
|
@ -87,7 +87,7 @@ printf("Processor architecture=%d\n",si ANONS .wProcessorArchitecture);
|
|||
<constant>WINE_UNICODE_REWRITE</constant> for each file
|
||||
that is built, and add
|
||||
<parameter>-fwritable-strings</parameter> to the compiler
|
||||
command line. You should replace all occurances of
|
||||
command line. You should replace all occurrences of
|
||||
<type>wchar_t</type> with <type>WCHAR</type> also, since
|
||||
<type>wchar_t</type> is the native (32 bit) type. These
|
||||
changes allow Wine to modify the native unicode strings
|
||||
|
@ -247,7 +247,7 @@ printf("Processor architecture=%d\n",si ANONS .wProcessorArchitecture);
|
|||
too that some functions are implemented with an underscore in
|
||||
their name and <function>#define</function>d to that name in
|
||||
the MS headers. So you may need to find out the name by
|
||||
examing <filename>dlls/msvcrt/msvcrt.spec</filename> to get
|
||||
examining <filename>dlls/msvcrt/msvcrt.spec</filename> to get
|
||||
the correct name for your <function>@ignore</function> entry.
|
||||
</para>
|
||||
</sect1>
|
||||
|
@ -271,9 +271,9 @@ printf("Processor architecture=%d\n",si ANONS .wProcessorArchitecture);
|
|||
<parameter>-lwine_uuid</parameter> to the link line.
|
||||
</para>
|
||||
<para>
|
||||
gcc is more strict than VC++, especially whan compiling
|
||||
gcc is more strict than VC++, especially when compiling
|
||||
C++. This may require you to add casts to your C++ to prevent
|
||||
overloading abiguities between similar types (such as two
|
||||
overloading ambiguities between similar types (such as two
|
||||
overloads that take int and char respectively).
|
||||
</para>
|
||||
<para>
|
||||
|
@ -305,7 +305,7 @@ printf("Processor architecture=%d\n",si ANONS .wProcessorArchitecture);
|
|||
Further compounding the problem is the fact that Linux's (GNU's?)
|
||||
current dynamic library loader does not call the module
|
||||
initializers in their dependency order. So even if Winelib were to
|
||||
have its own initializer there would be no garantee that it would be
|
||||
have its own initializer there would be no guarantee that it would be
|
||||
called before the initializer of the library containing this static
|
||||
variable. Finally even if the variable is in a library that your
|
||||
application links with, that library's initializer may be called
|
||||
|
|
|
@ -147,7 +147,7 @@
|
|||
If winemaker fails to find a file in any of the directories of the
|
||||
include path, it will rename it to lowercase on the basis that it
|
||||
is most likely a system header and that all system headers names
|
||||
are lowercase (this can be overriden by using
|
||||
are lowercase (this can be overridden by using
|
||||
<option>--nolower-include</option>).
|
||||
</para>
|
||||
<para>
|
||||
|
@ -700,7 +700,7 @@ ORDINAL VARTYPE EXPORTNAME (DATA [DATA [DATA [...]]])
|
|||
<literal>long</literal> for 8, 16, or 32 bits respectively.
|
||||
<literal>EXPORTNAME</literal> will be the name available for
|
||||
dynamic linking. <literal>DATA</literal> can be a decimal number
|
||||
or a hex number preceeded by "0x". The example defines the
|
||||
or a hex number preceded by "0x". The example defines the
|
||||
variable <literal>Variable</literal> at ordinal 2 and containing
|
||||
4 bytes.
|
||||
</para>
|
||||
|
@ -715,7 +715,7 @@ ORDINAL equate EXPORTNAME DATA
|
|||
corresponding to the variable. <literal>EXPORTNAME</literal> will
|
||||
be the name available for dynamic linking.
|
||||
<literal>DATA</literal> can be a decimal number or a hex number
|
||||
preceeded by "0x".
|
||||
preceded by "0x".
|
||||
</para>
|
||||
|
||||
<programlisting>
|
||||
|
|
Loading…
Reference in New Issue