Skip to content

W
wine-cw
Commit 1e8e5ba8 authored by John R. Sheets's avatar John R. Sheets Committed by Alexandre Julliard
Browse files
Options

Converted Wine documentation to SGML format.

parent c4fac786
Expand all Hide whitespace changes
Inline Side-by-side
Showing with 1008 additions and 3099 deletions
Make.rules.in
View file @ 1e8e5ba8
......@@ -238,7 +238,7 @@ Makefile: Makefile.in $(TOPSRCDIR)/configure
man: $(C_SRCS)
for i in $(C_SRCS); do $(C2MAN) -L -o $(TOPOBJDIR)/documentation/man3w -S3w $(DIVINCL) -D__WINE__ $(MANSPECS) $$i; done
html: $(C_SRCS)
doc-html: $(C_SRCS)
for i in $(C_SRCS); do $(C2MAN) -L -o $(TOPOBJDIR)/documentation/html -Th -iwindows.h $(DIVINCL) -D__WINE__ $(MANSPECS) $$i; done
# Rule for linting
......
documentation/.cvsignore
View file @ 1e8e5ba8
*.aux
*.dvi
*.junk
*.log
*.tex
DBTOHTML_OUTPUT_DIR*
Makefile
wine.aux
wine-doc
wine-doc.pdf
wine-doc.ps
wine-doc.rtf
wine.conf.man
wine.cp
wine.cps
wine.dvi
wine.fn
wine.fns
wine.html
wine.info
wine.info-1
wine.info-2
wine.ky
wine.log
wine.man
wine.pg
wine.texi
wine.toc
wine.tp
wine.tps
wine.vr
wine.vrs
wine_toc.html
documentation/Makefile.in
View file @ 1e8e5ba8
......@@ -3,52 +3,52 @@ TOPOBJDIR = ..
SRCDIR = @srcdir@
VPATH = @srcdir@
MODULE = none
INCLUDES = \
AUTHORS \
LICENSE \
WARRANTY
SOURCES = \
wine.texinfo \
$(INCLUDES)
INFOFILES = \
wine.info \
wine.info-1 \
wine.info-2
HTMLFILES = \
wine_toc.html \
wine.html
DVIFILES = wine.dvi
BOOKNAME = wine-doc
EXTRASUBDIRS = samples status
all: $(INFOFILES) $(DVIFILES) $(HTMLFILES)
info: $(INFOFILES)
dvi: $(DVIFILES)
html: $(HTMLFILES)
BOOK_SRCS = \
architecture.sgml \
bugs.sgml \
build.sgml \
compiling.sgml \
configuring.sgml \
consoles.sgml \
debugger.sgml \
debugging.sgml \
dlls.sgml \
documentation.sgml \
fonts.sgml \
i18n.sgml \
implementation.sgml \
installing.sgml \
opengl.sgml \
packaging.sgml \
patches.sgml \
porting.sgml \
printing.sgml \
registry.sgml \
running.sgml \
tools.sgml \
wine-doc.sgml
BOOK_TARGETS = \
$(BOOKNAME)/index.html \
$(BOOKNAME).pdf \
$(BOOKNAME).ps
all: $(BOOK_TARGETS)
@MAKE_RULES@
$(INFOFILES): $(SOURCES)
makeinfo $(SRCDIR)/wine.texinfo
$(DVIFILES): $(SOURCES)
texi2dvi $(SRCDIR)/wine.texinfo
$(BOOKNAME)/index.html: $(BOOK_SRCS)
db2html $(BOOKNAME).sgml
$(HTMLFILES): $(SOURCES)
makeinfo -E wine.texi $(SRCDIR)/wine.texinfo
texi2html wine.texi
$(BOOKNAME).pdf: $(BOOK_SRCS)
db2pdf $(BOOKNAME).sgml
$(INCLUDES):
$(RM) $(INCLUDES)
for i in $(INCLUDES); do $(LN_S) $(TOPSRCDIR)/$$i $$i || exit 1; done
$(BOOKNAME).ps: $(BOOK_SRCS)
db2ps $(BOOKNAME).sgml
install::
$(INSTALL) -d $(mandir)/man$(prog_manext)
......@@ -62,19 +62,8 @@ uninstall::
$(RM) $(mandir)/man$(prog_manext)/wine.$(prog_manext)
$(RM) $(mandir)/man$(conf_manext)/wine.conf.$(conf_manext)
# Not done by default because of makeinfo bugs
install_info: $(INFOFILES)
[ -d $(infodir) ] || mkdir -p $(infodir)
for i in $(INFOFILES); do $(INSTALL_DATA) $$i $(infodir)/$$i; done
uninstall_info:
for i in $(INFOFILES); do $(RM) $(infodir)/$$i; done
clean::
$(RM) $(INFOFILES) $(DVIFILES) $(INCLUDES)
$(RM) wine.aux wine.cp wine.cps wine.fn wine.fns wine.ky wine.log \
wine.pg wine.toc wine.tp wine.tps wine.vr wine.vrs \
wine.texi
$(RM) -r man3w
$(RM) *.aux *.dvi *.tex *.log $(BOOKNAME).pdf $(BOOKNAME).ps
$(RM) -r $(BOOKNAME) html man3w *.junk DBTOHTML_OUTPUT_DIR*
### Dependencies:
documentation/accelerators deleted 100644 → 0
View file @ c4fac786
Some notes concerning accelerators.
There are _three_ differently sized accelerator structures exposed to the
user. The general layout is:
BYTE fVirt;
WORD key;
WORD cmd;
We now have three different appearances:
- Accelerators in NE resources. These have a size of 5 byte and do not have
any padding. This is also the internal layout of the global handle HACCEL
(16 and 32) in Windows 95 and WINE. Exposed to the user as Win16 global
handles HACCEL16 and HACCEL32 by the Win16/Win32 API.
- Accelerators in PE resources. These have a size of 8 byte. Layout is:
BYTE fVirt;
BYTE pad0;
WORD key;
WORD cmd;
WORD pad1;
They are exposed to the user only by direct accessing PE resources.
- Accelerators in the Win32 API. These have a size of 6 byte. Layout is:
BYTE fVirt;
BYTE pad0;
WORD key;
WORD cmd;
These are exposed to the user by the CopyAcceleratorTable and
CreateAcceleratorTable in the Win32 API.
Why two types of accelerators in the Win32 API? We can only guess, but
my best bet is that the Win32 resource compiler can/does not handle struct
packing. Win32 ACCEL is defined using #pragma(2) for the compiler but without
any packing for RC, so it will assume #pragma(4).
Findings researched by Uwe Bonnes, Ulrich Weigand and Marcus Meissner.
documentation/aspi deleted 100644 → 0
View file @ c4fac786
This file describes setting up the Windows ASPI interface.
Warning/Warning/Warning!!!!!!
=============================
THIS MAY TRASH YOUR SYSTEM IF USED INCORRECTLY
THIS MAY TRASH YOUR SYSTEM IF USED CORRECTLY
Now that I have said that. ASPI is a direct link to SCSI devices from
windows programs. ASPI just forwards the SCSI commands that programs send
to it to the SCSI bus.
If you use the wrong scsi device in your setup file, you can send
completely bogus commands to the wrong device - An example would be
formatting your hard drives (assuming the device gave you permission -
if you're running as root, all bets are off).
So please make sure that **all** SCSI devices that the program won't need
have their permissions set as restricted as possible !
Cookbook for setting up scanner: (At least how mine is to work)
================================
Windows requirements:
=====================
0) The scanner software needs to use the "Adaptec" compatible drivers
(ASPI). At least with Mustek, they allow you the choice of using
the builtin card or the "Adaptec (AHA)" compatible drivers. This will not
work any other way.
Software that accesses the scanner via a DOS ASPI driver (e.g. ASPI2DOS)
is supported, too. [AM]
1) You probably need a real windows install of the software to set the
LUN's/SCSI id's up correctly. I'm not exactly sure.
LINUX requirements:
============================================================
0) Your scsi card must be supported under linux. This will not work with
an unknown scsi card.
Even for cheap'n crappy "scanner only" controllers some special Linux drivers
exist on the net.
1) Compile generic scsi drivers into your kernel.
2) Linux by default uses smaller scsi buffers than Windows. There is a
kernel build define SG_BIG_BUFF (in sg.h) that is by default set too low.
The SANE project recommends 130560 and this seems to work just fine. This
does require a kernel rebuild.
3) Make the devices for the scanner (generic scsi devices) - look at the scsi
programming how-to for device numbering.
4) I would recommend making the scanner device writable by a group.
I made a group called "scanner" and added myself to it. Running as root
increases your risk of sending bad scsi commands to the wrong device. With
a regular user, you are better protected.
5) Add a scsi device entry for your particular scanner to wine.conf.
The format is [scsi cCtTdD] where C=controller, T=target, D=LUN
ex. I set mine up as controller 0, Target 6, LUN 0.
[scsi c0t6d0]
Device=/dev/sgi
Yours will vary with your particular SCSI setup.
General Information:
====================
The mustek scanner I have was shipped with a package "ipplus". This
program uses the TWAIN driver specification to access scanners.
(TWAIN MANAGER)
ipplus.exe <---> (TWAIN INTERFACE) <---> (TWAIN DATA SOURCE . ASPI) -> WINASPI
NOTES/BUGS:
===========
The biggest is that it only works under linux at the moment.
The ASPI code has only been tested with:
- a Mustek 800SP with a Buslogic controller under Linux [BM]
- a Siemens Nixdorf 9036 with Adaptec AVA-1505 under Linux
accessed via DOSASPI.
Note that I had color problems, though (barely readable result) [AM]
- a Fujitsu M2513A MO drive (640MB) using generic scsi drivers.
Formatting and ejecting worked perfectly.
Thanks to Uwe Bonnes for access to the hardware ! [AM]
I make no warranty to the aspi code. It makes my scanner work. Your devices
may explode. I have no way of determining this. I take zero responsibility!
Bruce Milner
Additions by Andreas Mohr
documentation/bugreports deleted 100644 → 0
View file @ c4fac786
How To Report A Bug
-------------------
There are two ways for you to make a bug report. One uses a simple perl
script, and is recommended if you don't want to spend a lot of time
producing the report. It is designed for use by just about anyone, from
the newest of newbies to advanced developers. You can also make a bug
report the hard way -- advanced developers will probably prefer this.
A. The Easy Way
1) Your computer *must* have perl on it for this method to work. To
find out if you have perl, run:
which perl
If it returns something like "/usr/bin/perl", you're in business.
Otherwise, skip on down to "The Hard Way".
If you aren't sure, just keep on going. When you try to run the script, it
will become *very* apparent if you don't have perl.
2) Change directory to <dirs to wine>/tools
3) Type in "./bug_report.pl" and follow the directions.
4) Post a message to the comp.emulators.ms-windows.wine newsgroup with the
"Nice Formatted Report" attatched. If possible, upload the full debug
output to a web/ftp server and provide the address in your message.
B. The Hard Way:
Some simple advice on making your bug report more useful (and thus more
likely to get answered and fixed):
1) Post as much information as possible.
This means we need more information than a simple
"MS Word crashes whenever I run it. Do you know why?"
Include at least the following information:
- Version of Wine you're using (run 'wine -v')
- Operating system you're using, what distribution (if any), and what
version
- Compiler and version (run 'gcc -v')
- Windows version, if installed
- Program you're trying to run, its version number, and a URL for
where the program can be obtained (if available)
- Command line you used to start wine
- Any other information you think may be relevant or helpful, such as
X server version in case of X problems, libc version etc.
2) Re-run the program with the -debugmsg +relay option
(i.e., 'wine -debugmsg +relay sol.exe').
If Wine crashes while running your program, it is important that we
have this information to have a chance at figuring out what is causing
the crash. This can put out quite a lot (several MB) of information,
though, so it's best to output it to a file. When the Wine-dbg> prompt
appears, type 'quit'.
You might want to try +relay,+snoop instead of +relay, but please note
that +snoop is pretty unstable and often will crash earlier than a
simple +relay !
If this is the case, then please use *only* +relay !!
A bug report with a crash in +snoop code is useless in most cases !
To get the trace output, use the following commands:
all shells:
echo quit|wine -debugmsg +relay [other_options] program_name >& filename.out; tail -n 100 filename.out > report_file
(This will print wine's debug msgs only to the file and then
auto-quit. It's probably a good idea to use this command, since wine
prints out so many debug msgs that they flood the terminal, eating CPU.)
tcsh and other csh-like shells:
wine -debugmsg +relay [other_options] program_name |& tee filename.out
tail -100 filename.out > report_file
bash and other sh-like shells:
wine -debugmsg +relay [other_options] program_name 2>&1 | tee filename.out
tail -100 filename.out > report_file
'report_file' will now contain the last hundred lines of the debugging
output, including the register dump and backtrace, which are the most
important pieces of information. Please do not delete this part, even
if you don't understand what it means.
3) Post your report to the newsgroup comp.emulators.ms-windows.wine
In your post, include all of the information from part 1), and insert
the text from the output file in part 2). If you do this, your chances
of receiving some sort of helpful response should be very good.
4) Questions and comments
If after reading this document there is something you couldn't figure
out, or think could be explained better, or that should have been
included, please post to comp.emulators.ms-windows.wine to let us know
how this document can be improved.
How to do regression testing using Cvs
-------------------------------------
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 *NOT* for casual
users.
1) get the 'full cvs' archive from winehq.
This archive is the cvs tree but with the tags controling the versioning
system. It's a big file (> 15 meg) with a name like full-cvs-<last update date>
(it's more than 100mb when uncompressed, you can't very well do this
with small, old computers or slow Internet connections)
2) untar it into a repository directory :
cd /home/gerard
tar -zxffull-cvs-2000-05-20.tar.gz
mv wine repository
3) extract a new destination directory
This directory must not be in a subdirectory of the repository else
cvs will think it's part of the repository and deny you an extraction
in the repository :
cd /home/gerard
mv wine wine_current (-> this protects your current wine sandbox, if any)
export CVSROOT=/home/gerard/repository
cd /home/gerard
cvs -d $CVSROOT checkout wine
Note that it's not possible to do a checkout at a given date; you
always do the checkout for the last date where the full-cvs-xxx snapshot
was generated.
4) you will have now in the ~/wine directory an image of the cvs tree,
on the client side.
Now update this image to the date you want :
cd /home/gerard/wine
cvs -d $CVSROOT update -D "1999-06-01"
The date format is YYYY-MM-DD.
Many messages will inform you that more recent files have been
deleted to set back the client cvs tree to the date you asked,
for example :
cvs update: tsx11/ts_xf86dga2.c is no longer in the repository
Cvs update is not limited to upgrade to a *newer* version as
I have believed for far too long :-(
5) Now proceed as for a normal update :
./configure
make depend && make
When you have found the exact date when a bug was
added to Cvs, use something like :
cvs -d $CVSROOT diff -D "1999-07-10" -D "1999-07-12"
to get all the differences between the last cvs version
known to work and code that first displayed the misbehavior.
[ I did not include flags for diff since they are in my .cvsrc file :
cvs -z 3
update -dPA
diff -u
]
From this diff file, particularly the file names, and the
ChangeLog, it's usually possible to find the different individual
patches that were done at this time.
If any non-programmer reads this, the fasted 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 mid-year,
then is the problem is already here, back to 1st avril, if not,
to 1st october, and so on.
6) The next step is to start from the last working version
and to dig the individual contributions from
http://www.integrita.com/cgi-local/lwgate.pl/WINE-PATCHES/
(where the Wine patches mailing list is archived)
If the patch was done by the Wine maintainer or if it was
sent directly to his mail address without going first through
wine-patches, you are out of luck as you will never find the
patch in the archive.
If it is, it's often possible to apply the patches one by
one to last working Cvs, compile and test. If you have saved
the next candidate as /home/gerard/buggedpatch1.txt :
cd /home/gerard/wine
patch -p 0 </home/gerard/buggedpatch1.txt
Beware that the committed patch is not always identical to
the patch that the author sent to wine-patches, as sometimes
the Wine maintainer changes things a bit.
If you find one patch that is getting the Cvs to reproduce the problem,
you have almost won; post the problem on
comp.emulators.windows.wine
and 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 the bug :-)
documentation/bugs.sgml 0 → 100644
View file @ 1e8e5ba8
<chapter id="bugs">
<title>Finding and Reporting Bugs</title>
<sect1 id="bug-reporting">
<title>How To Report A Bug</title>
<para>
written by Gerard Patel (???)
</para>
<para>
(Extracted from <filename>wine/documentation/bugreports</filename>)
</para>
<para>
There are two ways for you to make a bug report. One uses a
simple perl script, and is recommended if you don't want to
spend a lot of time producing the report. It is designed for
use by just about anyone, from the newest of newbies to
advanced developers. You can also make a bug report the hard
way -- advanced developers will probably prefer this.
</para>
<sect2>
<title>The Easy Way</title>
<orderedlist>
<listitem>
<para>
Your computer *must* have perl on it for this method to
work. To find out if you have perl, run <command>which
perl</command>. If it returns something like
<filename>/usr/bin/perl</filename>, you're in business.
Otherwise, skip on down to "The Hard Way". If you aren't
sure, just keep on going. When you try to run the
script, it will become *very* apparent if you don't have
perl.
</para>
</listitem>
<listitem>
<para>
Change directory to <filename>&lt;dirs to
wine>/tools</filename>
</para>
</listitem>
<listitem>
<para>
Type in <command>./bug_report.pl</command> and follow
the directions.
</para>
</listitem>
<listitem>
<para>
Post a message to the
<systemitem>comp.emulators.ms-windows.wine</systemitem>
newsgroup with the "Nice Formatted Report" attatched. If
possible, upload the full debug output to a web/ftp
server and provide the address in your message.
</para>
</listitem>
</orderedlist>
</sect2>
<sect2>
<title>The Hard Way</title>
<para>
Some simple advice on making your bug report more useful
(and thus more likely to get answered and fixed):
</para>
<orderedlist>
<listitem>
<para>Post as much information as possible.</para>
<para>
This means we need more information than a simple "MS
Word crashes whenever I run it. Do you know why?"
Include at least the following information:
</para>
<itemizedlist spacing="compact">
<listitem>
<para>Version of Wine you're using (run <command>wine
-v</command>)</para>
</listitem>
<listitem>
<para>
Operating system you're using, what distribution (if
any), and what version
</para>
</listitem>
<listitem>
<para>Compiler and version (run <command>gcc -v</command>)</para>
</listitem>
<listitem>
<para>Windows version, if installed</para>
</listitem>
<listitem>
<para>
Program you're trying to run, its version number,
and a URL for where the program can be obtained (if
available)
</para>
</listitem>
<listitem>
<para>Command line you used to start wine</para>
</listitem>
<listitem>
<para>
Any other information you think may be relevant or
helpful, such as X server version in case of X
problems, libc version etc.
</para>
</listitem>
</itemizedlist>
</listitem>
<listitem>
<para>
Re-run the program with the <parameter>--debugmsg
+relay</parameter> option (i.e., <command>wine
--debugmsg +relay sol.exe</command>).
</para>
<para>
If Wine crashes while running your program, it is
important that we have this information to have a chance
at figuring out what is causing the crash. This can put
out quite a lot (several MB) of information, though, so
it's best to output it to a file. When the <prompt>Wine-dbg></prompt>
prompt appears, type <userinput>quit</userinput>.
</para>
<para>
You might want to try
<parameter>+relay,+snoop</parameter> instead of
<parameter>+relay</parameter>, but please note that
<parameter>+snoop</parameter> is pretty unstable and
often will crash earlier than a simple
<parameter>+relay</parameter>! If this is the case, then
please use *only* <parameter>+relay</parameter>!! A bug
report with a crash in <parameter>+snoop</parameter>
code is useless in most cases!
</para>
<para>
To get the trace output, use the following commands:
</para>
<variablelist>
<varlistentry>
<term>all shells:</term>
<listitem>
<screen>
<prompt>$ </prompt>echo quit | wine -debugmsg +relay [other_options] program_name >& filename.out;
<prompt>$ </prompt>tail -n 100 filename.out > report_file
</screen>
<para>
(This will print wine's debug messages only to the file and then
auto-quit. It's probably a good idea to use this command, since wine
prints out so many debug msgs that they flood the terminal, eating CPU.)
</para>
</listitem>
</varlistentry>
<varlistentry>
<term>tcsh and other csh-like shells:</term>
<listitem>
<screen>
<prompt>$ </prompt>wine -debugmsg +relay [other_options] program_name |& tee filename.out;
<prompt>$ </prompt>tail -100 filename.out > report_file
</screen>
</listitem>
</varlistentry>
<varlistentry>
<term>bash and other sh-like shells:</term>
<listitem>
<screen>
<prompt>$ </prompt>wine -debugmsg +relay [other_options] program_name 2>&1 | tee filename.out;
<prompt>$ </prompt>tail -100 filename.out > report_file
</screen>
</listitem>
</varlistentry>
</variablelist>
<para>
<filename>report_file</filename> will now contain the
last hundred lines of the debugging output, including
the register dump and backtrace, which are the most
important pieces of information. Please do not delete
this part, even if you don't understand what it means.
</para>
</listitem>
<listitem>
<para>
Post your report to the newsgroup
<systemitem>comp.emulators.ms-windows.wine</systemitem>
</para>
<para>
In your post, include all of the information from part
1), and insert the text from the output file in part 2).
If you do this, your chances of receiving some sort of
helpful response should be very good.
</para>
</listitem>
</orderedlist>
</sect2>
<sect2>
<title>Questions and comments</title>
<para>
If after reading this document there is something you
couldn't figure out, or think could be explained better, or
that should have been included, please post to
<systemitem>comp.emulators.ms-windows.wine</systemitem> to
let us know how this document can be improved.
</para>
</sect2>
</sect1>
</chapter>
<!-- Keep this comment at the end of the file
Local variables:
mode: sgml
sgml-parent-document:("wine-doc.sgml" "book" "chapter" "")
End:
-->
documentation/build.sgml 0 → 100644
View file @ 1e8e5ba8
<chapter id="build">
<title>The Wine Build System</title>
<para>How the Wine build system works, and how to tweak it...</para>
</chapter>
<!-- Keep this comment at the end of the file
Local variables:
mode: sgml
sgml-parent-document:("wine-doc.sgml" "book" "part" "chapter" "")
End:
-->
documentation/cdrom-labels deleted 100644 → 0
View file @ c4fac786
Drive labels and serial numbers with wine
-----------------------------------------
Until now, your only possibility of specifying drive volume labels
and serial numbers was to set them manually in the wine config file.
By now, wine can read them directly from the device as well. This may be
useful for many Win 9x games or for setup programs distributed on CD-ROMs
that check for volume label.
WHAT'S SUPPORTED ?
* FAT systems (types 'hd' and 'floppy'): reads labels and serial num's.
* Iso9660 ('cdrom'): reads labels only.
HOW TO SET UP ?
Reading labels and serial numbers just works automagically if
you specify a 'Device=' line in the [Drive X] section in your wine.conf.
Note that the device has to exist and must be accessible if you do this,
though.
If you don't do that, then you should give fixed 'Label=' or 'Serial=' entries
in wine.conf, as Wine returns these entries instead if no device is given.
If they don't exist, then Wine will return default values (label "Drive X"
and serial 12345678).
Now a seldom needed one:
If you want to give a 'Device=' entry *only* for drive raw sector accesses, but
not for reading the volume info from the device (i.e. you want a *fixed*,
preconfigured label), you need to specify 'ReadVolInfo=0' to tell Wine to skip
the volume reading.
EXAMPLES
*** Simple example of cdrom and floppy; labels will be read from the device on
both cdrom and floppy; serial numbers on floppy only:
[Drive A]
Path=/mnt/floppy
Type=floppy
Device=/dev/fd0
Filesystem=msdos
[Drive R]
Path=/mnt/cdrom
Type=cdrom
Device=/dev/hda1
Filesystem=win95
*** CD-ROM. We want to override the label:
[Drive J]
Path=/mnt/cdrom
Type=cdrom
Label=X234GCDSE
; note that the device isn't really needed here as we have a fixed label
Device=/dev/cdrom
Filesystem=msdos
TODO / OPEN ISSUES
- The cdrom label can be read only if the data track of the disk resides in
the first track and the cdrom is iso9660.
- Better checking for FAT superblock (it now check's only one byte).
- Support for labels/serial num's WRITING.
- Can the label be longer than 11 chars? (iso9660 has 32 chars).
- What about reading ext2 volume label? ....
Petr Tomasek changes by: Andreas Mohr
<tomasek@etf.cuni.cz> <a.mohr@mailto.de>
Nov 14 1999 Jan 25 2000
documentation/compiling.sgml 0 → 100644
View file @ 1e8e5ba8
<chapter id="compiling">
<title>Compiling Wine</title>
<para>How to compile wine, and problems that may arise...</para>
</chapter>
<!-- Keep this comment at the end of the file
Local variables:
mode: sgml
sgml-parent-document:("wine-doc.sgml" "book" "part" "chapter" "")
End:
-->
documentation/console deleted 100644 → 0
View file @ c4fac786
Console - First Pass
--------------------
Consoles are just xterms created with the -Sxxn switch.
A pty is opened and the master goes to the xterm side
and the slave is held by the wine side. The console
itself it turned into a few HANDLE32s and is set
to the STD_*_HANDLES.
It is possible to use the WriteFile and ReadFile commands
to write to a win32 console. To accomplish this, all K32OBJs
that support I/O have a read and write function pointer.
So, WriteFile calls K32OBJ_WriteFile which calls the K32OBJ's
write function pointer, which then finally calls write.
[this paragraph is now out of date]
If the command line console is to be inheirited or
a process inherits its parent's console (-- can that happen???),
the console is created at process init time via PROCESS_InheritConsole.
The 0, 1, and 2 file descriptors are duped to be the
STD_*_HANDLES in this case. Also in this case a flag is set
to indicate that the console comes from the parent process or
command line.
If a process doesn't have a console at all, its
pdb->console is set to NULL. This helps indicate when
it is possible to create a new console (via AllocConsole).
When FreeConsole is called, all handles that the process has
open to the console are closed. Like most k32objs, if the
console's refcount reaches zero, its k32obj destroy function
is called. The destroy kills the xterm if one was open.
Also like most k32 objects, we assume that (K32OBJ) header is the
first field so the casting (from K32OBJ *to CONSOLE *)
works correctly.
FreeConsole is called on process exit (in ExitProcess) if
pdb->console is not NULL.
BUGS
----
Console processes do not inherit their parent's handles. I think
there needs to be two cases, one where they have to inherit
the stdin/stdout/stderr from unix, and one where they have to
inherit from another windows app.
SetConsoleMode -- UNIX only has ICANON and various ECHOs
to play around with for processing input. Win32 has
line-at-a-time processing, character processing, and
echo. I'm putting together an intermediate driver
that will handle this (and hopefully won't be any more
buggy then the NT4 console implementation).
================================================================
experimentation with NT4 yields that:
WriteFile
---------
o does not truncate file on 0 length write
o 0 length write or error on write changes numcharswritten to 0
o 0 length write returns TRUE
o works with console handles
_lwrite
-------
o does truncate/expand file at current position on 0 length write
o returns 0 on a zero length write
o works with console handles (typecasted)
WriteConsole
------------
o expects only console handles
SetFilePointer
--------------
o returns -1 (err 6) when used with a console handle
FreeConsole
-----------
o even when all the handles to it are freed, the win32 console
stays visible, the only way I could find to free it
was via the FreeConsole
Is it possible to interrupt win32's FileWrite? I'm not sure.
It may not be possible to interrupt any system calls.
DOS (Generic) Console Support
-----------------------------
I. Command Line Configuration
DOS consoles must be configured either on the command line or in a dot
resource file (.console). A typical configuration consists of a string
of driver keywords separated by plus ('+') signs. To change the
configuration on the command-line, use the -console switch.
For example:
wine -console ncurses+xterm <apllication>
Possible drivers:
tty - Generic text-only support. Supports redirection.
ncurses - Full-screen graphical support with color.
xterm - Load a new window to display the console in. Also
supports resizing windows.
II. Wine.conf Configuration
In the wine.conf file, you can create a section called [console] that
contains configuration options that are respected by the assorted
console drivers.
Current Options:
XtermProg=<program>
Use this program instead of xterm. This eliminates the need for a
recompile. See the table below for a comparison of various
terminals.
InitialRows=<number>
Attempt to start all drivers with this number of rows. This
causes xterms to be resized, for instance.
Note: This information is passed on the command-line with the
-g switch.
InitialColumns=<number>
Attempt to start all drivers with this number of columns. This
causes xterms to be resized, for instance.
Note: This information is passed on the command-line with the
-g switch.
TerminalType=<name>
Tell any driver that is interested (ncurses) which termcap
and/or terminfo type to use. The default is xterm which is
appropiate for most uses. "nxterm" may give you better support
if you use that terminal. This can also be changed to
"linux" (or "console" on older systems) if you manage to hack
the ability to write to the console into this driver.
III. Terminal Types
There are a large number of potential terminals that can be used with
Wine, depending on what you are trying to do. Unfortunately, I am still
looking for the "best" driver combination.
Note that 'slave' is required for use in Wine, currently.
Program | Color? | Resizing? | Slave?
-----------------------------------------
xterm N Y Y
nxterm Y N Y
rxvt Y ? N
(linux console) Y N ?
As X terminals typically use a 24x80 screen resolution rather than the
typical 25x80 one, it is necessary to resize the screen to allow a DOS
program to work full-screen. There is a wine.conf option to work
around this in some cases but run-time resizing will be disabled.
documentation/dll-overrides deleted 100644 → 0
View file @ c4fac786
DLL overrides
-------------
The wine.conf directives [DllDefaults] and [DllOverrides] are the
subject of some confusion. The overall purpose of most of these
directives are clear enough, though - given a choice, should Wine use
its own built-in DLLs, or should it use .DLL files found in an
existing Windows installation? This document explains how this feature
works.
DLL types
native
A "native" DLL is a .DLL file written for the real Microsoft
Windows.
builtin
A "builtin" DLL is a Wine DLL. These can either be a part of
libwine.so, or more recently, in a special .so file that Wine
is able to load on demand.
elfdll
An "elfdll" is a Wine .so file with a special Windows-like file
structure that is as close to Windows as possible, and that can
also seamlessly link dynamically with "native" DLLs, by using
special ELF loader and linker tricks. Bertho Stultiens did some
work on this, but this feature has not yet been merged back
into Wine (because of political reasons and lack of time), so
this DLL type does not exist in the official Wine at this time.
In the meantime, the "builtin" DLL type gained some of the
features of elfdlls (such as dynamic loading), so it's possible
that "elfdll" functionality will be folded into "builtin" at
some point.
so
A native Unix .so file, with calling convention conversion
thunks generated on the fly as the library is loaded. This is
mostly useful for libraries such as "glide" that has exactly
the same API on both Windows and Unix.
The [DllDefaults] section
EXTRA_LD_LIBRARY_PATH
This specifies the location of the Wine's DLL .so files. Wine
will search this path when trying to locate a DLL of the type
"builtin" or "elfdll". (This does not apply to libwine.so,
since libwine.so is not a DLL in this sense.)
DefaultLoadOrder
This specifies in what order Wine should search for available
DLL types, if the DLL in question was not found in the
[DllOverrides] section.
The [DllPairs] section
At one time, there was a section called [DllPairs] in the default
configuration file, but this has been obsoleted because the pairing
information has now been embedded into Wine itself. (The purpose of
this section was merely to be able to issue warnings if the user
attempted to pair codependent 16-bit/32-bit DLLs of different types.)
If you still have this in your wine.conf or .winerc, you may safely
delete it.
The [DllOverrides] section
This section specifies how you want specific DLLs to be handled, in
particular whether you want to use "native" DLLs or not, if you have
some from a real Windows configuration. Because builtins do not mix
seamlessly with native DLLs yet, certain DLL dependencies may be
problematic, but workarounds exist in Wine for many popular DLL
configurations. Also see WWN's [16]Status Page to figure out how well
your favorite DLL is implemented in Wine.
It is of course also possible to override these settings by explictly
using Wine's --dll command-line option (see the man page for details).
Some hints for choosing your optimal configuration (listed by
16/32-bit DLL pair):
krnl386, kernel32
Native versions of these will never work, so don't try. Leave
at builtin.
gdi, gdi32
Graphics Device Interface. No effort has been made at trying to
run native GDI. Leave at builtin.
user, user32
Window management and standard controls. It was possible to use
Win95's native versions at some point (if all other DLLs that
depend on it, such as comctl32 and comdlg32, were also run
native). However, this is no longer possible after the Address
Space Separation, so leave at builtin.
ntdll
NT kernel API. Although badly documented, the native version of
this will never work. Leave at builtin.
w32skrnl
Win32s (for Win3.x). Native version will probably never work.
Leave at builtin.
wow32
Win16 support library for NT. Native version will probably
never work. Leave at builtin.
system
Win16 kernel stuff. Will never work native. Leave at builtin.
display
Display driver. Definitely leave at builtin.
toolhelp
Tool helper routines. This is rarely a source of problems.
Leave at builtin.
ver, version
Versioning. Seldom useful to mess with.
advapi32
Registry and security features. Trying the native version of
this may or may not work.
commdlg, comdlg32
Common Dialogs, such as color picker, font dialog, print
dialog, open/save dialog, etc. It is safe to try native.
commctrl, comctl32
Common Controls. This is toolbars, status bars, list controls,
the works. It is safe to try native.
shell, shell32
Shell interface (desktop, filesystem, etc). Being one of the
most undocumented pieces of Windows, you may have luck with the
native version, should you need it.
winsock, wsock32
Windows Sockets. The native version will not work under Wine,
so leave at builtin.
icmp
ICMP routines for wsock32. As with wsock32, leave at builtin.
mpr
The native version may not work due to thunking issues. Leave
at builtin.
lzexpand, lz32
Lempel-Ziv decompression. Wine's builtin version ought to work
fine.
winaspi, wnaspi32
Advanced SCSI Peripheral Interface. The native version will
probably never work. Leave at builtin.
crtdll
C Runtime library. The native version will easily work better
than Wine's on this one.
winspool.drv
Printer spooler. You are not likely to have more luck with the
native version.
ddraw
DirectDraw/Direct3D. Since Wine does not implement the DirectX
HAL, the native version will not work at this time.
dinput
DirectInput. Running this native may or may not work.
dsound
DirectSound. It may be possible to run this native, but don't
count on it.
dplay/dplayx
DirectPlay. Native ought to work best on this, if at all.
mmsystem, winmm
Multimedia system. The native version is not likely to work.
Leave at builtin.
msacm, msacm32
Audio Compression Manager. Builtin works best, if you set
msacm.drv to the same.
msvideo, msvfw32
Video for Windows. It is safe (and recommended) to try native.
mcicda.drv
CD Audio MCI driver.
mciseq.drv
MIDI Sequencer MCI driver (.MID playback).
mciwave.drv
Wave audio MCI driver (.WAV playback).
mciavi.drv
AVI MCI driver (.AVI video playback). Best to use native.
mcianim.drv
Animation MCI driver.
msacm.drv
Audio Compression Manager. Set to same as msacm32.
midimap.drv
MIDI Mapper.
wprocs
This is a pseudo-DLL used by Wine for thunking purposes. A
native version of this doesn't exist.
Have fun...
- Ove Kåven
documentation/dlls deleted 100644 → 0
View file @ c4fac786
WINE/WINDOWS DLLS
This document mainly deals with the status of current DLL support by
Wine. The Wine ini file currently supports settings to change the
load order of DLLs. The load order depends on several issues, which
results in different settings for various DLLs.
Pros of Native DLLs
-------------------
Native DLLs of course guarantee 100% compatibility for routines they
implement. For example, using the native USER DLL would maintain a
virtually perfect and Windows 95-like look for window borders, dialog
controls, and so on. Using the built-in WINE version of this library,
on the other hand, would produce a display that does not precisely
mimic that of Windows 95. Such subtle differences can be engendered
in other important DLLs, such as the common controls library COMMCTRL
or the common dialogs library COMMDLG, when built-in WINE DLLs outrank
other types in load order.
More significant, less aesthetically-oriented problems can result if
the built-in WINE version of the SHELL DLL is loaded before the native
version of this library. SHELL contains routines such as those used by
installer utilities to create desktop shortcuts. Some installers might
fail when using WINE's built-in SHELL.
Cons of Native DLLs
-------------------
Not every application performs better under native DLLs. If a library
tries to access features of the rest of the system that are not fully
implemented in Wine, the native DLL might work much worse than the
corresponding built-in one, if at all. For example, the native Windows
GDI library must be paired with a Windows display driver, which of
course is not present under Intel Unix and WINE.
Finally, occassionally 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 DLL. Should the native Windows USER library take
load-order precedence, such features as the ability to use the
clipboard or drag-and- drop between Wine windows and X windows will be
lost.
Deciding Between Native and Built-In DLLs
-----------------------------------------
Clearly, there is no one rule-of-thumb regarding which load-order to
use. So, you must become familiar with:
* what specific DLLs do
* which other DLLs or features a given library interacts with
and use this information to make a case-by-case decision.
Load Order for DLLs
-------------------
Using the DLL sections from the wine configuration file, the load
order can be tweaked to a high degree. In general it is advised not to
change the settings of the configuration file. The default
configuration specifies the right load order for the most important
DLLs.
The default load order follows this algorithm: for all DLLs which have
a fully-functional Wine implementation, or where the native DLL is
known not to work, the built-in library will be loaded first. In all
other cases, the native DLL takes load-order precedence.
The DefaultLoadOrder from the [DllDefaults] section specifies for all
DLLs which version to try first. See manpage for explanation of the
arguments.
The [DllOverrides] section deals with DLLs, which need a
different-from-default treatment.
The [DllPairs] section is for DLLs, which must be loaded in pairs. In
general, these are DLLs for either 16-bit or 32-bit applications. In
most cases in Windows, the 32-bit version cannot be used without its
16-bit counterpart. For WINE, it is customary that the 16-bit
implementations rely on the 32-bit implementations and cast the
results back to 16-bit arguments. Changing anything in this section is
bound to result in errors.
For the future, Wine implemetation of Windows DLL seems to head
towards unifying the 16 and 32 bit DLLs wherever possible, resulting
in larger DLLs. They are stored in the dlls/ subdirectory using the
16-bit name. For large DLLs, a split might be discussed.
Understanding What DLLs Do
--------------------------
The following list briefly describes each of the DLLs commonly found
in Windows whose load order may be modified during the configuration
and compilation of WINE.
(See also ./DEVELOPER-HINTS or the dlls/ subdirectory to see which
DLLs are currently being rewritten for wine)
ADVAPI32.DLL: 32-bit application advanced programming interfaces
like crypto, systeminfo, security and eventlogging
AVIFILE.DLL: 32-bit application programming interfaces for the
Audio Video Interleave (AVI) Windows-specific
Microsoft audio-video standard
COMMCTRL.DLL: 16-bit common controls
COMCTL32.DLL: 32-bit common controls
COMDLG32.DLL: 32-bit common dialogs
COMMDLG.DLL: 16-bit common dialogs
COMPOBJ.DLL: OLE 16- and 32-bit compatibility libraries
CRTDLL.DLL: Microsoft C runtime
DCIMAN.DLL: 16-bit
DCIMAN32.DLL: 32-bit display controls
DDEML.DLL: DDE messaging
D3D*.DLL DirectX/Direct3D drawing libraries
DDRAW.DLL: DirectX drawing libraries
DINPUT.DLL: DirectX input libraries
DISPLAY.DLL: Display libraries
DPLAY.DLL, DPLAYX.DLL: DirectX playback libraries
DSOUND.DLL: DirectX audio libraries
GDI.DLL: 16-bit graphics driver interface
GDI32.DLL: 32-bit graphics driver interface
IMAGEHLP.DLL: 32-bit IMM API helper libraries (for PE-executables)
IMM32.DLL: 32-bit IMM API
IMGUTIL.DLL:
KERNEL32.DLL 32-bit kernel DLL
KEYBOARD.DLL: Keyboard drivers
LZ32.DLL: 32-bit Lempel-Ziv or LZ file compression
used by the installshields (???).
LZEXPAND.DLL: LZ file expansion; needed for Windows Setup
MMSYSTEM.DLL: Core of the Windows multimedia system
MOUSE.DLL: Mouse drivers
MPR.DLL: 32-bit Windows network interface
MSACM.DLL: Core of the Addressed Call Mode or ACM system
MSACM32.DLL: Core of the 32-bit ACM system
Audio Compression Manager ???
MSNET32.DLL 32-bit network APIs
MSVFW32.DLL: 32-bit Windows video system
MSVIDEO.DLL: 16-bit Windows video system
OLE2.DLL: OLE 2.0 libraries
OLE32.DLL: 32-bit OLE 2.0 components
OLE2CONV.DLL: Import filter for graphics files
OLE2DISP.DLL, OLE2NLS.DLL: OLE 2.1 16- and 32-bit interoperability
OLE2PROX.DLL: Proxy server for OLE 2.0
OLE2THK.DLL: Thunking for OLE 2.0
OLEAUT32.DLL 32-bit OLE 2.0 automation
OLECLI.DLL: 16-bit OLE client
OLECLI32.DLL: 32-bit OLE client
OLEDLG.DLL: OLE 2.0 user interface support
OLESVR.DLL: 16-bit OLE server libraries
OLESVR32.DLL: 32-bit OLE server libraries
PSAPI.DLL: Proces Status API libraries
RASAPI16.DLL: 16-bit Remote Access Services libraries
RASAPI32.DLL: 32-bit Remote Access Services libraries
SHELL.DLL: 16-bit Windows shell used by Setup
SHELL32.DLL: 32-bit Windows shell (COM object?)
TAPI/TAPI32/TAPIADDR: Telephone API (for Modems)
W32SKRNL: Win32s Kernel ? (not in use for Win95 and up!)
WIN32S16.DLL: Application compatibility for Win32s
WIN87EM.DLL: 80387 math-emulation libraries
WINASPI.DLL: Advanced SCSI Peripheral Interface or ASPI libraries
WINDEBUG.DLL Windows debugger
WINMM.DLL: Libraries for multimedia thunking
WING.DLL: Libraries required to "draw" graphics
WINSOCK.DLL: Sockets APIs
WINSPOOL.DLL: Print spooler libraries
WNASPI32.DLL: 32-bit ASPI libraries
WSOCK32.DLL: 32-bit sockets APIs
Credits
-------
Based upon various messages on wine-devel especially by Ulrich Weigand.
Adapted by Michele Petrovski and Klaas van Gend.
documentation/README.documentation → documentation/documentation.sgml
View file @ 1e8e5ba8
Wine Documentation README
Wine Man Page
The man page for Wine is in this directory. It is installed by 'make
install'.
Wine Reference Manual
Texinfo source for preliminary comprehensive documentation is in
this directory. Use 'make info' in this directory to generate the GNU
info version, 'make dvi' to generate the DVI version (hit 'r' to
ignore errors), or 'make all' for both. It is not installed by
default.
Wine API documentation
Do a 'make manpages' in the Wine toplevel directory to generate the
API manpages from the Wine source, or 'make man' in any source
subdirectory to generate manpages from only that directory. Only
functions mentioned in Wine spec files will be documented; the
specific .spec files checked are set by the MANSPECS variable in
Make.rules. The manpages will be generated into
[documentation/man3w]. For HTML formatted manpages, do 'make
htmlpages' from the toplevel, or 'make html' from any
subdirectory. HTML formatted pages are generated into
[documentation/html]. You will need c2man as modified for Wine,
available as source or binary from ftp://ftp.winehq.com/pub/wine/.
The man pages are not installed by 'make install'.
Other READMEs
Other informational files are in this directory as well as scattered
through the source tree.
Other resources:
Usenet: news:comp.emulators.ms-windows.wine
WWW: http://www.winehq.com/
Writing Wine API Documentation
To improve the documentation of the Wine API, just add comments to the
existing source. For example,
<chapter id="documentation">
<title>Documenting Wine</title>
<para>How to help out with the Wine documentation effort...</para>
<sect1 id="api-docs">
<title>Writing Wine API Documentation</title>
<para>
written by (???)
</para>
<para>
(Extracted from <filename>wine/documentation/README.documentation</filename>)
</para>
<para>
To improve the documentation of the Wine API, just add
comments to the existing source. For example,
</para>
<screen>
/******************************************************************
* CopyMetaFile32A (GDI32.23)
*
......@@ -65,9 +36,12 @@ HMETAFILE32 WINAPI CopyMetaFile32A(
HMETAFILE32 hSrcMetaFile, /* handle of metafile to copy */
LPCSTR lpFilename /* filename if copying to a file */
) { ... }
becomes, after processing with c2man and nroff -man,
</screen>
<para>
becomes, after processing with <command>c2man</command> and
<command>nroff -man</command>,
</para>
<screen>
CopyMetaFileA(3w) CopyMetaFileA(3w)
......@@ -103,3 +77,13 @@ SEE ALSO
GetMetaFileA(3w), GetMetaFileW(3w), CopyMetaFileW(3w),
PlayMetaFile(3w), SetMetaFileBitsEx(3w), GetMetaFileBit-
sEx(3w)
</screen>
</sect1>
</chapter>
<!-- Keep this comment at the end of the file
Local variables:
mode: sgml
sgml-parent-document:("wine-doc.sgml" "book" "part" "chapter" "")
End:
-->
documentation/filehandles deleted 100644 → 0
View file @ c4fac786
DOS treats the first 5 file handles as special cases. They map directly
to stdin, stdout, stderr, stdaux and stdprn. Windows 16 inherits this
behavoir, and in fact, win16 handles are interchangable with DOS handles.
Some nasty windows programs even do this!
Windows32 issues file handles starting from 1, on the grounds that
most GUI processes don't need a stdin, out, etc.
The wine handle code is implemented in the Win32 style, and the Win16
functions use two macros to convert to and from the two types.
The macros are defined in file.h as follows.:
#define HFILE16_TO_HFILE32(handle) \
(((handle)==0) ? GetStdHandle(STD_INPUT_HANDLE) : \
((handle)==1) ? GetStdHandle(STD_OUTPUT_HANDLE) : \
((handle)==2) ? GetStdHandle(STD_ERROR_HANDLE) : \
((handle)>0x400) ? handle : \
(handle)-5)
#define HFILE32_TO_HFILE16(handle) ({ HFILE32 hnd=handle; \
((hnd==HFILE_ERROR32) ? HFILE_ERROR16 : \
((handle>0x400) ? handle : \
(HFILE16)hnd+5); })
WARNING: be careful not to use the macro HFILE16_TO_HFILE32 on
functions with side-effects, as it will cause them to be evaluated
several times. This could be considered a bug, but the use of this
macro is limited enough not to need a rewrite.
NOTE: The 0x400 special case above deals with LZW filehandles (see
misc/lzexpand.c).
documentation/fonts deleted 100644 → 0
View file @ c4fac786
Note:
=====
The fnt2bdf utility is included with Wine. It can be found in the tools
directory.
Links to the other tools mentioned in this document can be found on wine
headquarters: http://www.winehq.com/tools.html
How To Convert Windows Fonts
============================
If you have access to a Windows installation you should use
fnt2bdf utility (found in the 'tools)' directory to convert
bitmap fonts (VGASYS.FON, SSERIFE.FON, and SERIFE.FON) into
the format that the X Window System can recognize.
Step 1. Extract bitmap fonts with 'fnt2bdf'.
Step 2. Convert .bdf files produced by Step 1 into
.pcf files with 'bdftopcf'.
Step 3. Copy .pcf files to the font server directory which
is usually /usr/lib/X11/fonts/misc (you will probably
need superuser privileges). If you want to create a new
font directory you will need to add it to the font path.
Step 4. Run 'mkfontdir' for the directory you copied fonts to.
If you are already in X you should run 'xset fp rehash'
to make X server aware of the new fonts.
Step 5. Edit WINE.CONF file to remove aliases for the fonts
you've just installed.
WINE can get by without these fonts but 'the look and feel'
may be quite different. Also, some applications try to load
their custom fonts on the fly (WinWord 6.0) and since WINE does
not implement this yet it instead prints out something like;
STUB: AddFontResource( SOMEFILE.FON )
You can convert this file too. Note that .FON file may not hold
any bitmap fonts and fnt2bdf will fail if this is the case. Also
note that although the above message will not disappear WINE will
work around the problem by using the font you extracted from the
SOMEFILE.FON. fnt2bdf will only work for Windows 3.1 fonts. It
will not work for TrueType fonts.
What to do with TrueType fonts? There are several commercial
font tools that can convert them to the Type1 format but the
quality of the resulting fonts is far from stellar. The other
way to use them is to get a font server capable of rendering
TrueType (Caldera has one, there also is the free Xfstt in
Linux/X11/fonts on sunsite and mirrors, if you're on FreeBSD you
can use the port in /usr/ports/x11-servers/Xfstt. And there is
xfsft which uses the freetype library, see documentation/ttfserver).
However, there is a possibility of the native TrueType support
via FreeType renderer in the future (hint, hint :-)
How To Add Font Aliases To WINE.CONF
====================================
Many Windows applications assume that fonts included in original Windows 3.1
distribution are always present. By default Wine creates a number of aliases
that map them on the existing X fonts:
Windows font ...is mapped to... X font
"MS Sans Serif" -> "-adobe-helvetica-"
"MS Serif" -> "-bitstream-charter-"
"Times New Roman" -> "-adobe-times-"
"Arial" -> "-adobe-helvetica-"
There is no default alias for the "System" font. Also, no aliases are
created for the fonts that applications install at runtime. The recommended
way to deal with this problem is to convert the missing font (see above).
If it proves impossible, like in the case with TrueType fonts, you can force
the font mapper to choose a closely related X font by adding an alias to the
[fonts] section. Make sure that the X font actually exists (with xfontsel
tool).
AliasN = [Windows font], [X font] <, optional "mask X font" flag>
Example:
Alias0 = System, --international-, subst
Alias1 = ...
...
Comments:
* There must be no gaps in the sequence {0, ..., N} otherwise all aliases
after the first gap won't be read.
* Usually font mapper translates X font names into font names visible to
Windows programs in the following fashion:
X font ...will show up as... Extracted name
--international-... -> "International"
-adobe-helvetica-... -> "Helvetica"
-adobe-utopia-... -> "Utopia"
-misc-fixed-... -> "Fixed"
-...
-sony-fixed-... -> "Sony Fixed"
-...
Note that since -misc-fixed- and -sony-fixed- are different fonts
Wine modified the second extracted name to make sure Windows programs
can distinguish them because only extracted names appear in the font
selection dialogs.
* "Masking" alias replaces the original extracted name so that in the
example case we will have the following mapping:
--international- -> "System"
"Nonmasking" aliases are transparent to the user and they do not
replace extracted names.
Wine discards an alias when it sees that the native X font is
available.
* If you do not have access to Windows fonts mentioned in the first
paragraph you should try to substitute the "System" font with
nonmasking alias. 'xfontsel' will show you the fonts available to
X.
Alias.. = System, ...bold font without serifs
Also, some Windows applications request fonts without specifying the
typeface name of the font. Font table starts with Arial in most Windows
installations, however X font table starts with whatever is the first line
in the fonts.dir. Therefore WINE uses the following entry to determine
which font to check first.
Example:
Default = -adobe-times-
Comments:
It is better to have a scalable font family (bolds and italics included)
as the default choice because mapper checks all available fonts until
requested height and other attributes match perfectly or the end of the
font table is reached. Typical X installations have scalable fonts in
the ../fonts/Type1 and ../fonts/Speedo directories.
How To Manage Cached Font Metrics
=================================
WINE stores detailed information about available fonts in the ~/.wine/.cachedmetrics
file. You can copy it elsewhere and add this entry to the [fonts] section
in your WINE.CONF:
FontMetrics = <file with metrics>
If WINE detects changes in the X font configuration it will rebuild font
metrics from scratch and then it will overwrite ~/.wine/.cachedmetrics with
the new information. This process can take a while.
Too Small Or Too Large Fonts
============================
Windows programs may ask WINE to render a font with the height specified
in points. However, point-to-pixel ratio depends on the real physical size
of your display (15", 17", etc...). X tries to provide an estimate of that
but it can be quite different from the actual size. You can change this
ratio by adding the following entry to the [fonts] section:
Resolution = <integer value>
In general, higher numbers give you larger fonts. Try to experiment with
values in the 60 - 120 range. 96 is a good starting point.
"FONT_Init: failed to load ..." Messages On Startup
===================================================
The most likely cause is a broken fonts.dir file in one of your font
directories. You need to rerun 'mkfontdir' to rebuild this file. Read
its manpage for more information. If you can't run mkfontdir on this machine
as you are not root, use "xset -fp xxx" to remove the broken font path.
documentation/how-to-port deleted 100644 → 0
View file @ c4fac786
What is this?
------------
This note is a short description of
* How to port Wine to your favourite operating system
* Why you probably shouldn't use "#ifdef MyOS"
* What to do instead.
This document does not say a thing about how to port Wine to non-386
operating systems, though. You would need a CPU emulator. Let's get
Wine into a better shape on 386 first, OK?
Why "#ifdef MyOS" is probably a mistake.
---------------------------------------
Operating systems change. Maybe yours doesn't have the "foo.h"
header, but maybe a future version will have it. If you want
to "#include <foo.h>", it doesn't matter what operating system
you are using; it only matters whether "foo.h" is there.
Furthermore, operating systems change names or "fork" into
several ones. An "#ifdef MyOs" will break over time.
If you use the feature of Autoconf, the Gnu auto-configuration
utility wisely, you will help future porters automatically
because your changes will test for _features_, not names of
operating systems. A feature can be many things:
* existance of a header file
* existance of a library function
* existance of libraries
* bugs in header files, library functions, the compiler, ...
* (you name it)
You will need Gnu Autoconf, which you can get from your
friendly Gnu mirror. This program takes Wine's "configure.in"
file and produces a "configure" shell script that users use to
configure Wine to their system.
There _are_ exceptions to the "avoid #ifdef MyOS" rule. Wine,
for example, needs the internals of the signal stack -- that
cannot easily be described in terms of features.
Let's now turn to specific porting problems and how to solve
them.
MyOS doesn't have the `foo.h' header!
------------------------------------
This first step is to make Autoconf check for this header.
In configure.in you add a segment like this in the section
that checks for header files (search for "header files"):
AC_CHECK_HEADER(foo.h, AC_DEFINE(HAVE_FOO_H))
If your operating system supports a header file with the
same contents but a different name, say bar.h, add a check
for that also.
Now you can change
#include <foo.h>
to
#ifdef HAVE_FOO_H
#include <foo.h>
#elif defined (HAVE_BAR_H)
#include <bar.h>
#endif
If your system doesn't have a corresponding header file even
though it has the library functions being used, you might
have to add an "#else" section to the conditional. Avoid
this if you can.
You will also need to add "#undef HAVE_FOO_H" (etc.) to
include/config.h.in
Finish up with "make configure" and "./configure".
MyOS doesn't have the `bar' function!
------------------------------------
A typical example of this is the `memmove'. To solve this
problem you would add `memmove' to the list of functions
that Autoconf checks for. In configure.in you search for
AC_CHECK_FUNCS and add `memmove'. (You will notice that
someone already did this for this particular function.)
Secondly, you will also need to add "#undef HAVE_BAR"
to include/config.h.in
The next step depends on the nature of the missing function.
Case 1: It's easy to write a complete implementation of the
function. (`memmove' belongs to this case.)
You add your implementation in misc/port.c surrounded by
"#ifndef HAVE_MEMMOVE" and "#endif".
You might have to add a prototype for your function. If so,
include/miscemu.h might be the place. Don't forget to protect
that definition by "#ifndef HAVE_MEMMOVE" and "#endif" also!
Case 2: A general implementation is hard, but Wine is only using
a special case.
An example is the various "wait" calls used in SIGNAL_child
from loader/signal.c. Here we have a multi-branch case on
features:
#ifdef HAVE_THIS
...
#elif defined (HAVE_THAT)
...
#elif defined (HAVE_SOMETHING_ELSE)
...
#endif
Note that this is very different from testing on operating
systems. If a new version of your operating systems comes
out and adds a new function, this code will magically start
using it.
Finish up with "make configure" and "./configure".
documentation/i18n.sgml 0 → 100644
View file @ 1e8e5ba8
<chapter id="i18n">
<title>Internationalization</title>
<sect1 id="adding-languages">
<title>Adding New Languages</title>
<para>
written by Morten Welinder, January 1996.
</para>
<itemizedlist>
<listitem>
<para>Thereafter revised Februari 1999 by Klaas van Gend</para>
</listitem>
<listitem>
<para>Revised again May 23, 1999, Klaas van Gend</para>
</listitem>
<listitem>
<para>Updated May 26, 2000, Zoran Dzelajlija</para>
</listitem>
</itemizedlist>
<para>
(Extracted from <filename>wine/documentation/languages</filename>)
</para>
<para>
This file documents the necessary procedure for adding a new
language to the list of languages that Wine can display system
menus and forms in. Currently at least the following languages
are still missing:
<simplelist columns="5" type="horiz">
<member>Bulgarian</member>
<member>Chinese</member>
<member>Greek</member>
<member>Icelandic</member>
<member>Japanese</member>
<member>Romanian</member>
<member>Croatian</member>
<member>Slovak</member>
<member>Turkish</member>
<member>Slovanian</member>
</simplelist>
</para>
<note>
<para>
<emphasis>I hope I got all the places where changes are
needed. If you see any place missing from the list,
submit a patch to this file please. Also note that
re-organization of the source code might change the list of
places.</emphasis>
</para>
</note>
<para>
To add a new language you need to be able to translate the
relatively few texts, of course. You will need very little
knowledge of programming, so you have almost no excuses for
not adding your language, right? We should easily be able to
support 20 languages within a few months, get going! Apart
from re-compilation it'll take you about an hour or two.
</para>
<para>
To add a new language to the list of languages that Wine can
handle you must...
</para>
<orderedlist>
<listitem>
<para>Find the language ID in
<filename>include/winnls.h</filename>.</para>
</listitem>
<listitem>
<para>
Look in <filename>ole/ole2nls.c</filename> if your
language is already incorporated in the <varname>static
const struct NLS_langlocale</varname>. If not: find the
appropriate entries in
<filename>include/winnls.h</filename> and add them to the
list.
</para>
</listitem>
<listitem>
<para>
Edit the parameters defined in
<filename>ole/nls/*.nls</filename> to fit your local
habits and language.
</para>
</listitem>
<listitem>
<para>
Edit <filename>documentation/wine.man.in</filename>
(search for <parameter>-language</parameter>) to show the
new language abbreviation.
</para>
</listitem>
<listitem>
<para>
Edit <filename>misc/main.c</filename> variable
<varname>Languages</varname> to contain the new language
abbreviation and language ID. Also edit
<structname>struct option_table</structname> in
<filename>misc/options.c</filename> to show the new
abbreviation.
</para>
</listitem>
<listitem>
<para>
Edit <filename>include/options.h</filename>
<type>enum</type> <varname>WINE_LANGUAGE</varname> to have
a member called <literal>LANG_XX</literal> where
<literal>XX</literal> is the new abbreviation.
</para>
</listitem>
<listitem>
<para>
Create a new file
<filename>dlls/commdlg/cdlg_XX.rc</filename> (where
<literal>XX</literal> is your language abbreviation)
containing all menus. Your best bet is to copy
<filename>cdlg_En.rc</filename> and start translating.
There is no real need to know how the internal structure
of the file, as you only need to translate the text within
quotes.
</para>
<para>
In menus, the character "&amp;" means that the next
character will be highlighted and that pressing that
letter will select the item. You should place these
"&amp;" characters suitably for your language, not just
copy the positions from (say) English. In particular,
items within one menu should have different highlighted
letters.
</para>
</listitem>
<listitem>
<para>
Edit <filename>dlls/commdlg/rsrc.rc</filename> to contain
an <symbol>#include</symbol> statement for your
<filename>cdlg_XX.rc</filename> file.
</para>
</listitem>
<listitem>
<para>
Repeat steps 6 and 7 again for:
<itemizedlist>
<listitem>
<para>
<filename>dlls/shell32/shell32_XX.rc</filename> and
<filename>shres.rc</filename>
</para>
</listitem>
<listitem>
<para>
<filename>resources/sysres_XX.rc</filename> and
<filename>user32.rc</filename>
</para>
</listitem>
</itemizedlist>
</para>
</listitem>
<listitem>
<para>
Re-configure, re-make dependencies, and re-make Wine.
</para>
</listitem>
<listitem>
<para>
Check your new menus and forms; when they're not ok, go
back to 6) and adapt the sizes, etc.
</para>
</listitem>
<listitem>
<para>
Several of the winelib based programs in the subdirectory
programs also have internationalisation support. See the
appropriate files there for reference.
</para>
</listitem>
<listitem>
<para>Edit
<filename>documentation/internationalisation</filename> to
show the new status.</para>
</listitem>
<listitem>
<para>
Submit patches for inclusion in the next Wine release, see
file <filename>./ANNOUNCE</filename> for details about
where to submit.
</para>
</listitem>
</orderedlist>
</sect1>
</chapter>
<!-- Keep this comment at the end of the file
Local variables:
mode: sgml
sgml-parent-document:("wine-doc.sgml" "book" "part" "chapter" "")
End:
-->
documentation/internal-dll deleted 100644 → 0
View file @ c4fac786
This document describes some points you should know before implementing
the internal counterparts to external DLL's. Only 32 bit DLL's
are considered.
1. The LibMain function
-----------------------
This is the way to do some initializing when a process or thread is attached
to the dll. The function name is taken from a *.spec file line:
init YourFunctionName
then, you have to implement the function:
BOOL32 WINAPI YourLibMain(HINSTANCE32 hinstDLL,
DWORD fdwReason, LPVOID lpvReserved)
{ if (fdwReason==DLL_PROCESS_ATTACH)
{ ...
}
....
}
2. Using functions from other built-in DLL's
--------------------------------------------
The problem here is, that you can't know if you have to call the function from
the internal or the external DLL. If you just call the function you will get
the internal implementation. If the external DLL is loaded the executed program
will use the external DLL and you the internal one.
When you -as an example- fill an iconlist placed in the internal DLL the
application won't get the icons from the external DLL.
To work around this, you should always use a pointer to call such functions:
/* definition of the pointer type*/
void (CALLBACK* pDLLInitComctl)();
/* getting the function address this should be done in the
LibMain function when called with DLL_PROCESS_ATTACH*/
BOOL32 WINAPI Shell32LibMain(HINSTANCE32 hinstDLL, DWORD fdwReason,
LPVOID lpvReserved)
{ HINSTANCE32 hComctl32;
if (fdwReason==DLL_PROCESS_ATTACH)
{ /* load the external / internal DLL*/
hComctl32 = LoadLibrary32A("COMCTL32.DLL");
if (hComctl32)
{ /* get the function pointer */
pDLLInitComctl=GetProcAddress32(hComctl32,"InitCommonControlsEx");
/* check it */
if (pDLLInitComctl)
{ /* use it */
pDLLInitComctl();
}
/* free the DLL / decrease the ref count */
FreeLibrary32(hComctl32);
}
else
{ /* do some panic*/
ERR(shell,"P A N I C error getting functionpointers\n");
exit (1);
}
}
....
3. Getting resources from a *.rc file linked to the DLL
-------------------------------------------------------
< If you know how, write some lines>
----------
<juergen.schmied@metronet.de>
documentation/ioport-trace-hints deleted 100644 → 0
View file @ c4fac786
cat > /dev/null <<EOF
The above line is necessary, leave it alone!!
--------------------------------------------------------------------
DOING A HARDWARE TRACE IN WINE
------------------------------
The primary reason to do this is to reverse engineer a hardware device
for which you don't have documentation, but can get to work under Wine.
This lot is aimed at parallel port devices, and in particular parallel port
scanners which are now so cheap they are virtually being given away. The
problem is that few manufactures will release any programming information which
prevents drivers being written for Sane, and the traditional technique of using
DOSemu to produce the traces does not work as the scanners invariably only have
drivers for Windows.
Please note that I have not been able to get my scanner working properly (a
UMAX Astra 600P), but a couple of people have reported success with at least
the Artec AS6e scanner. I am not in the process of developing any driver nor do
I intend to, so don't bug me about it. My time is now spent writting programs
to set things like battery save options under Linux on Toshiba laptops, ans as
such I don't have any spare time for writting a driver for a parallel port
scanner etc.
Presuming that you have compiled and installed wine the first thing to do is is
to enable direct hardware access to your parallel port. To do this edit
wine.conf (usually in /usr/local/etc) and in the ports section add the
following two lines
read=0x378,0x379,0x37a,0x37c,0x77a
write=0x378,x379,0x37a,0x37c,0x77a
This adds the necessary access required for SPP/PS2/EPP/ECP parallel port on
LPT1. You will need to adjust these number accordingly if your parallel port is
on LPT2 or LPT0.
When starting wine use the following command line, where XXXX is the program
you need to run in order to access your scanner, and YYYY is the file your
trace will be stored in:
wine -debugmsg +io XXXX 2> >(sed 's/^[^:]*:io:[^ ]* //' > YYYY)
You will need large amounts of hard disk space (read hundreds of megabytes if
you do a full page scan), and for reasonable performance a really fast
processor and lots of RAM.
You might well find the log compression program that David Campbell
<campbell@torque.net> wrote helpfull in reducing the size of the log files.
This can be obtained by the following command:
sh ioport-trace-hints
This should extract shrink.c (which is located at the end of this file. Compile
the log compression program by:
cc shrink.c -o shrink
Use the shrink program to reduce the physical size of the raw log as follows:
cat log | shrink > log2
The trace has the basic form of
XXXX > YY @ ZZZZ:ZZZZ
where XXXX is the port in hexidecimal being accessed, YY is the data written
(or read) from the port, and ZZZZ:ZZZZ is the address in memory of the
instruction that accessed the port. The direction of the arrow indicates
whether the data was written or read from the port.
> data was written to the port
< data was read from the port
My basic tip for interperating these logs is to pay close attention to the
addresses of the IO instructions. There grouping and sometimes proximity should
reveal the presence of subroutines in the driver. By studying the different
versions you should be able to work them out. For example consider the
following section of trace from my UMAX Astra 600P
0x378 > 55 @ 0297:01ec
0x37a > 05 @ 0297:01f5
0x379 < 8f @ 0297:01fa
0x37a > 04 @ 0297:0211
0x378 > aa @ 0297:01ec
0x37a > 05 @ 0297:01f5
0x379 < 8f @ 0297:01fa
0x37a > 04 @ 0297:0211
0x378 > 00 @ 0297:01ec
0x37a > 05 @ 0297:01f5
0x379 < 8f @ 0297:01fa
0x37a > 04 @ 0297:0211
0x378 > 00 @ 0297:01ec
0x37a > 05 @ 0297:01f5
0x379 < 8f @ 0297:01fa
0x37a > 04 @ 0297:0211
0x378 > 00 @ 0297:01ec
0x37a > 05 @ 0297:01f5
0x379 < 8f @ 0297:01fa
0x37a > 04 @ 0297:0211
0x378 > 00 @ 0297:01ec
0x37a > 05 @ 0297:01f5
0x379 < 8f @ 0297:01fa
0x37a > 04 @ 0297:0211
As you can see their is a repeating structure starting at address 0297:01ec
that consists of four io access on the parallel port. Looking at it the first
io access writes a changing byte to the data port the second always writes the
byte 0x05 to the control port, then a value which always seems to 0x8f is read
from the status port at which point a byte 0x04 is written to the control port.
By studying this and other sections of the trace we can write a C routine that
emulates this, shown below with some macros to make reading/writing on the
parallel port easier to read.
#define r_dtr(x) inb(x)
#define r_str(x) inb(x+1)
#define r_ctr(x) inb(x+2)
#define w_dtr(x,y) outb(y, x)
#define w_str(x,y) outb(y, x+1)
#define w_ctr(x,y) outb(y, x+2)
/*
* Seems to be sending a command byte to the scanner
*
*/
int udpp_put(int udpp_base, unsigned char command)
{
int loop,value;
w_dtr(udpp_base, command);
w_ctr(udpp_base, 0x05);
for (loop=0;loop<10;loop++)
if (((value=r_str(udpp_base)) & 0x80)!=0x00) {
w_ctr(udpp_base, 0x04);
return value & 0xf8;
}
return (value & 0xf8) | 0x01;
}
For the UMAX Astra 600P only seven such routines exist (well 14 really, seven
for SPP and seven for EPP). Whether you choose to disassemble the driver at
this point to verify the routines is your own choice. If you do, the address
from the trace should help in locating them in the disassembly.
You will probably then find it useful to write a script/perl/C 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)
start:
put: 55 8f
put: aa 8f
put: 00 8f
put: 00 8f
put: 00 8f
put: c2 8f
wait: ff
get: af,87
wait: ff
get: af,87
end: cc
start:
put: 55 8f
put: aa 8f
put: 00 8f
put: 03 8f
put: 05 8f
put: 84 8f
wait: ff
From this it is easy to see that put routine is often grouped together in five
successive calls sending information to the scanner. Once these are understood
it should be possible to process the logs further to show the higher level
routines in an easy to see format. Once the highest level format that you
can derive from this process is understood, you then need to produce a
series of scans varying only one parameter between them, so you can
discover how to set the various parameters for the scanner.
Jonathan Buzzard
<jab@hex.prestel.co.uk>
--------------------------------------------------------------------
The following is the shrink.c program.
EOF
cat > shrink.c <<EOF
#include <stdio.h>
#include <string.h>
void
main (void)
{
char buff[256], lastline[256];
int count;
count = 0;
lastline[0] = 0;
while (!feof (stdin))
{
fgets (buff, sizeof (buff), stdin);
if (strcmp (buff, lastline) == 0)
{
count++;
}
else
{
if (count > 1)
fprintf (stdout, "# Last line repeated %i times #\n", count);
fprintf (stdout, "%s", buff);
strcpy (lastline, buff);
count = 1;
}
}
}
EOF
documentation/keyboard deleted 100644 → 0
View file @ c4fac786
Wine now needs to know about your keyboard layout. This requirement comes from
a need from many apps to have the correct scancodes available, since they read
these directly, instead of just taking the characters returned by the X server.
This means that Wine now needs to have a mapping from X keys to the scancodes
these applications expect.
On startup, Wine will try to recognize the active X layout by seeing if it
matches any of the defined tables. If it does, everything is allright. If not,
you need to define it.
To do this, open the file windows/x11drv/keyboard.c and take a look at the
existing tables. Make a backup copy of it, especially if you don't use CVS.
What you really would need to do, is to find out which scancode each key needs
to generate, find it in the main_key_scan table, which looks like this
static const int main_key_scan[MAIN_LEN] =
{
/* this is my (102-key) keyboard layout, sorry if it doesn't quite match yours */
0x29,0x02,0x03,0x04,0x05,0x06,0x07,0x08,0x09,0x0A,0x0B,0x0C,0x0D,
0x10,0x11,0x12,0x13,0x14,0x15,0x16,0x17,0x18,0x19,0x1A,0x1B,
0x1E,0x1F,0x20,0x21,0x22,0x23,0x24,0x25,0x26,0x27,0x28,0x2B,
0x2C,0x2D,0x2E,0x2F,0x30,0x31,0x32,0x33,0x34,0x35,
0x56 /* the 102nd key (actually to the right of l-shift) */
};
and then assign each scancode the characters imprinted on the keycaps. This
was done (sort of) for the US 101-key keyboard, which you can find near the
top in keyboard.c. It also shows that if there is no 102nd key, you can skip
that.
However, for most international 102-key keyboards, we have done it easy for you.
The scancode layout for these already pretty much matches the physical layout
in the main_key_scan, so all you need to do is to go through all the keys that
generate characters on your main keyboard (except spacebar), and stuff those
into an appropriate table. The only exception is that the 102nd key, which is
usually to the left of the first key of the last line (usually Z), must be
placed on a separate line after the last line.
For example, my Norwegian keyboard looks like this
§ ! " # ¤ % & / ( ) = ? ` Back-
| 1 2@ 3£ 4$ 5 6 7{ 8[ 9] 0} + \´ space
Tab Q W E R T Y U I O P Å ^
¨~
Enter
Caps A S D F G H J K L Ø Æ *
Lock '
Sh- > Z X C V B N M ; : _ Shift
ift < , . -
Ctrl Alt Spacebar AltGr Ctrl
Note the 102nd key, which is the "<>" key, to the left of Z. The character
to the right of the main character is the character generated by AltGr.
This keyboard is defined as follows:
static const char main_key_NO[MAIN_LEN][4] =
{
"|§","1!","2\"@","3#£","4¤$","5%","6&","7/{","8([","9)]","0=}","+?","\\´",
"qQ","wW","eE","rR","tT","yY","uU","iI","oO","pP","åÅ","¨^~",
"aA","sS","dD","fF","gG","hH","jJ","kK","lL","øØ","æÆ","'*",
"zZ","xX","cC","vV","bB","nN","mM",",;",".:","-_",
"<>"
};
Except that " and \ needs to be quoted with a backslash, and that the 102nd
key is on a separate line, it's pretty straightforward.
After you have written such a table, you need to add it to the main_key_tab[]
layout index table. This will look like this:
static struct {
WORD lang, ansi_codepage, oem_codepage;
const char (*key)[MAIN_LEN][4];
} main_key_tab[]={
...
...
{MAKELANGID(LANG_NORWEGIAN,SUBLANG_DEFAULT), 1252, 865, &main_key_NO},
...
After you have added your table, recompile Wine and test that it works.
If it fails to detect your table, try running
wine -debugmsg +key,+keyboard >& key.log
and look in the resulting key.log file to find the error messages it
gives for your layout.
Note that the LANG_* and SUBLANG_* definitions are in include/winnls.h,
which you might need to know to find out which numbers your language
is assigned, and find it in the debugmsg output. The numbers will
be SUBLANG * 0x400 + LANG, so, for example the combination
LANG_NORWEGIAN (0x14) and SUBLANG_DEFAULT (0x1) will be (in hex)
14 + 1*400 = 414, so since I'm Norwegian, I could look for 0414 in
the debugmsg output to find out why my keyboard won't detect.
Once it works, submit it to the Wine project. If you use CVS, you
will just have to do
cvs -z3 diff -u windows/x11drv/keyboard.c > layout.diff
from your main Wine directory, then submit layout.diff to
wine-patches@winehq.com along with a brief note of what it is.
If you don't use CVS, you need to do
diff -u the_backup_file_you_made windows/x11drv/keyboard.c > layout.diff
and submit it as explained above.
If you did it right, it will be included in the next Wine release, and all
the troublesome applications (especially remote-control applications) and
games that use scancodes will be happily using your keyboard layout, and you
won't get those annoying fixme messages either.
Good luck.
-Ove Kåven <ovek@arcticnet.no>
documentation/languages deleted 100644 → 0
View file @ c4fac786
ADDING LANGUAGES TO WINE
This file documents the necessary procedure for adding a new language
to the list of languages that Wine can display system menus and forms
in. Currently at least the following languages are still missing:
Bulgarian, Chinese, Greek, Icelandic, Japanese, Romanian,
Croatian, Slovak, Turkish, and Slovanian.
To add a new language you need to be able to translate the relatively
few texts, of course. You will need very little knowledge of
programming, so you have almost no excuses for not adding your language,
right? We should easily be able to support 20 languages within a few
months, get going! Apart from re-compilation it'll take you about an
hour or two.
To add a new language to the list of languages that Wine can handle
you must...
0. Find the language ID in include/winnls.h .
1. Look in ole/ole2nls.c if your language is already incorporated in
the "static const struct NLS_langlocale". If not: find the
appropriate entries in include/winnls.h and add them to the list.
2. Edit the parameters defined in ole/nls/*.nls to fit your local
habits and language.
3. Edit documentation/wine.man.in (search for -language) to show the new
language abbreviation.
4. Edit misc/main.c variable "Languages" to contain the new language
abbreviation and language ID. Also edit struct "option_table" in
misc/options.c to show the new abbreviation.
5. Edit include/options.h enum "WINE_LANGUAGE" to have a member called
LANG_XX where XX is the new abbreviation.
6. Create a new file dlls/commdlg/cdlg_XX.rc (where XX is your language
abbreviation) containing all menus.
Your best bet is to copy cdlg_En.rc and start translating.
There is no real need to know how the internal structure of the file,
as you only need to translate the text within quotes.
In menus, the character "&" means that the next character will
be highlighted and that pressing that letter will select the item.
You should place these "&"s suitably for your language, not just
copy the positions from (say) English. In particular, items within
one menu should have different highlighted letters.
7. Edit dlls/commdlg/rsrc.rc to contain an include statement for your
cdlg_XX.rc file.
8. Repeat steps 6 and 7 again for:
- dlls/shell32/shell32_XX.rc and shres.rc
- resources/sysres_XX.rc and user32.rc
9. Re-configure, re-make dependencies, and re-make Wine.
10. Check your new menus and forms; when they're not ok,
go back to 6) and adapt the sizes, etc.
11. Several of the winelib based programs in the subdirectory programs
also have internationalisation support. See the appropriate files
there for reference.
12. Edit /documentation/internationalisation to show the new status.
13. Submit patches for inclusion in the next Wine release,
see file ./ANNOUNCE for details about where to submit.
January 1996
Morten Welinder
[I hope I got all the places where changes are needed. If you see any
place missing from the above list, submit a patch to this file please.
Also note that re-organization of the source code might change the list
of places.]
Therefore revised Februari 1999 by Klaas van Gend
Revised again May 23, 1999, Klaas van Gend
Updated May 26, 2000, Zoran Dzelajlija
documentation/linux-fat-permissions deleted 100644 → 0
View file @ c4fac786
This document describes how FAT and VFAT file system permissions work
in Linux with a focus on configuring them for Wine.
Introduction
------------
Linux is able to access DOS and Windows file systems using either the
FAT (older 8.3 DOS filesystems) or VFAT (newer Windows 95 or later
long filename filesystems) modules. Mounted FAT or VFAT filesystems
provide the primary means for which existing applications and their
data are accessed through Wine for dual boot (Linux + Windows)
systems.
Wine maps mounted FAT filesystems, such as "/c", to driver letters,
such as "c:", as indicated by the wine.conf file. The following
excerpt from a wine.conf file does this:
[Drive C]
Path=/c
Type=hd
Although VFAT filesystems are preferable to FAT filesystems for their
long filename support the term "FAT" will be used throughout the
remainder of this document to refer to FAT filesystems and their
derivatives. Also, "/c" will be used as the FAT mount point in
examples throughout this document.
Most modern Linux distributions either detect or allow existing FAT
file systems to be configured so that can be mounted, in a location
such as /c, either persistently (on bootup) or on an as needed basis.
In either case, by default, the permissions will probably be configured
so that they look something like:
~>cd /c
/c>ls -l
-rwxr-xr-x 1 root root 91 Oct 10 17:58 autoexec.bat
-rwxr-xr-x 1 root root 245 Oct 10 17:58 config.sys
drwxr-xr-x 41 root root 16384 Dec 30 1998 windows
where all the files are owned by "root", are in the "root" group and
are only writable by "root" (755 permissions). This is restrictive in
that it requires that Wine be run as root in order for applications to
be able to write to any part of the filesystem.
There three major approaches to overcoming the restrictive permissions
mentioned in the previous paragraph:
1) Run Wine as root
2) Mount the FAT filesystem with less restrictive permissions
3) Shadow the FAT filesystem by completely or partially copying it
Each approach will be discusses in the following "Running Wine as
root", "Mounting FAT filesystems" and "Shadowing FAT filesystems"
sections.
Running Wine as root
--------------------
Running Wine as root is the easiest and most thorough way of giving
applications that Wine runs unrestricted access to FAT files systems.
Running wine as root also allows applications to do things unrelated
to FAT filesystems, such as listening to ports that are less than
1024. Running Wine as root is dangerous since there is no limit to
what the application can do to the system.
Mounting FAT filesystems
------------------------
The FAT filesystem can be mounted with permissions less restrictive
than the default. This can be done by either changing the user that
mounts the FAT filesystem or by explicitly changing the permissions
that the FAT filesystem is mounted with. The permissions are
inherited from the process that mounts the FAT filesystem. Since the
process that mounts the FAT filesystem is usually a startup script
running as root the FAT filesystem inherits root's permissions. This
results in the files on the FAT filesystem having permissions similar
to files created by root. For example:
~>whoami
root
~>touch root_file
~>ls -l root_file
-rw-r--r-- 1 root root 0 Dec 10 00:20 root_file
which matches the owner, group and permissions of files seen on the
FAT filesystem except for the missing 'x's. The permissions on the
FAT filesystem can be changed by changing root's umask (unset
permissions bits). For example:
~>umount /c
~>umask
022
~>umask 073
~>mount /c
~>cd /c
/c>ls -l
-rwx---r-- 1 root root 91 Oct 10 17:58 autoexec.bat
-rwx---r-- 1 root root 245 Oct 10 17:58 config.sys
drwx---r-- 41 root root 16384 Dec 30 1998 windows
Mounting the FAT filesystem with a umask of 000 gives all users
complete control over the it.
Explicitly specifying the permissions of the FAT filesystem when it is
mounted provides additional control. There are three mount options
that are relevant to FAT permissions: "uid", "gid" and "umask". They
can each be specified when the filesystem is manually mounted. For
example:
~>umount /c
~>mount -o uid=500 -o gid=500 -o umask=002 /c
~>cd /c
/c>ls -l
-rwxrwxr-x 1 sle sle 91 Oct 10 17:58 autoexec.bat
-rwxrwxr-x 1 sle sle 245 Oct 10 17:58 config.sys
drwxrwxr-x 41 sle sle 16384 Dec 30 1998 windows
which gives "sle" complete control over /c. The options listed above
can be made permanent by adding them to the /etc/fstab file:
~>grep /c /etc/fstab
/dev/hda1 /c vfat uid=500,gid=500,umask=002,exec,dev,suid,rw 1 1
Note that the umask of 002 is common in the user private group file
permission scheme. On FAT file systems this umask assures that all
files are fully accessible by all users in the specified group (gid).
Shadowing FAT filesystems
-------------------------
Shadowing provides a finer granularity of control. Parts of the
original FAT filesystem can be copied so that the application can
safely work with those copied parts while the application continue to
directly read the remaining parts. This is done with symbolic links.
For example, consider a system where an application named "AnApp" must
be able to read and write to the c:\windows and c:\AnApp directories
as well as have read access to the entire FAT filesystem. On this
system the FAT filesystem has default permissions which should not be
changed for security reasons or can not be changed due to lack of root
access. On this system a shadow directory might be set up in the
following manner:
~>cd /
/>mkdir c_shadow
/>cd c_shadow
/c_shadow>ln -s /c_/* .
/c_shadow>rm windows AnApp
/c_shadow>cp -R /c_/{windows,AnApp} .
/c_shadow>chmod -R 777 windows AnApp
/c_shadow>perl -p -i -e 's|/c$|/c_shadow|g' /usr/local/etc/wine.conf
The above gives everyone complete read and write access to the
"windows" and "AnApp" directories while only root has write access to
all other directories.
---
Steven Elliott (elliotsl@mindspring.com)
documentation/no-windows deleted 100644 → 0
View file @ c4fac786
Wine without Windows
====================
A major goal of Wine is to allow users to run Windows programs without
having to install Windows on their machine. Wine implements the
functionality of the main DLL's usually provided with Windows.
Therefore, once Wine is finished, you will not need to have windows
installed to use Wine.
Wine has already made enough progress that it may be possible to run
your target applications without Windows installed. If you want to try
it, follow these steps:
1. Create empty C:\windows, C:\windows\system, C:\windows\Start Menu,
and C:\windows\Start Menu\Programs directories.
Do not point Wine to a Windows directory full of old installations
and a messy registry. (Wine creates a special registry in your home
directory, in $HOME/.wine/*.reg. Perhaps you have to remove these
files).
2. Point [Drive C] in wine.conf or .winerc to where you want C: to be.
Refer to the Wine man page for more information. Remember to use
filesystem=win95 !
3. Use tools/wineinstall to compile Wine and install the default
registry. Or if you prefer to do it yourself, compile programs/regapi,
and run: programs/regapi/regapi setValue < winedefault.reg
4. Run and/or install your applications.
Because Wine is not yet complete, some programs will work better
with native Windows DLL's than with Wine's replacements. Wine has been
designed to make this possible. Here are some tips by Juergen Schmied
(and others) on how to proceed. This assumes that your C:\windows
directory in the configuration file does not point to a native Windows
installation but is in a separate Unix file system. (For instance,
"C:\windows" is really subdirectory "windows" located in
"/home/ego/wine/drives/c").
- Run the application with --debugmsg +module,+file to find out
which files are needed. Copy the required DLL's one by one to the
C:\windows\system directory. Do not copy KERNEL/KERNEL32, GDI/GDI32,
or USER/USER32. These implement the core functionality of the
Windows API, and the Wine internal versions must be used.
- Edit the [DllOverrides] section of wine.conf or .winerc to specify
'native' before 'builtin' for the Windows DLL's you want to use.
For more information about this, see the Wine manpage.
- Note that some network DLL's are not needed even though Wine is
looking for them. The Windows MPR.DLL currently does not work; you
must use the internal implementation.
- Copy SHELL/SHELL32 and COMDLG/COMDLG32 COMMCTRL/COMCTL32
only as pairs to your Wine directory (these DLL's are
"clean" to use). Make sure you have these specified in the
[DllPairs] section of wine.conf or .winerc.
- Be consistent: Use only DLL's from the same Windows version
together.
- Put regedit.exe in the C:\windows directory (office95 imports
a *.reg file when it runs with a empty registry, don't know
about office97).
- Also add winhelp.exe and winhlp32.exe if you want to be able to browse
through your programs' help function.
documentation/opengl deleted 100644 → 0
View file @ c4fac786
I What is needed to have OpenGL support in Wine
===============================================
Basically, if you have a Linux OpenGL ABI compliant libGL
(http://oss.sgi.com/projects/ogl-sample/ABI/) installed on your
computer, you should everything that is needed.
To be more clear, I will detail one step after another what the
configure script checks.
If, after Wine compiles, OpenGL support is not compiled in, you can
always check 'config.log' to see which of the following points failed.
I.1 Header files
----------------
The needed header files to build OpenGL support in Wine are :
- gl.h : the definition of all OpenGL core functions, types and
enumerants
- glx.h : how OpenGL integrates in the X Window environment
- glext.h : the list of all registered OpenGL extensions
The latter file (glext.h) is, as of now, not necessary to build
Wine. But as this file can be easily obtained from SGI
(http://oss.sgi.com/projects/ogl-sample/ABI/glext.h), and that all
OpenGL should provide one, I decided to keep it here.
I.2 OpenGL library thread-safety
--------------------------------
After that, the script checks if the OpenGL library relies or not on
the pthread library to provide thread safety (most 'modern' OpenGL
libraries do).
If the OpenGL library explicitely links in libpthread (you can check
it with a 'ldd libGL.so'), you need to force OpenGL support by
starting configure with the '--enable-opengl' flag.
The reason to this is that Wine contains some hacks done by Ove to
cohabit with pthread that are known to work well in 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.
Anyway, it should be pretty safe to build with '--enable-opengl'.
I.3 OpenGL library itself
-------------------------
To check for the presence of 'libGL' on the system, the script checks
if it defines the 'glXCreateContext' function. There should be no
problem here.
I.4 glXGetProcAddressARB function
---------------------------------
The core of Wine's OpenGL implementation (at least for all extensions)
is the glXGetProcAddressARB function. Your OpenGL library needs to
have this function defined for Wine to be able to support OpenGL.
If your library does not provide it, you are out of luck.
(Note: this is not completely true as one could rewrite a
glXGetProcAddressARB replacement using 'dlopen' and friends,
but well, telling people to upgrade is easier :-) ).
II How to configure
===================
Configuration is quite easy : once OpenGL support has been built in
Wine, this internal OpenGL driver will be used each time an
application tries to load 'opengl32.dll'.
Due to restrictions (that do not exist in Windows) on OpenGL contexts,
if you want to prevent the screen to flicker when using OpenGL
applications (all games are using double-buffered contexts), you need
to set the following option in your .winerc / wine.ini in the [x11drv]
section :
DesktopDoubleBuffered = Y
and to run Wine with the '--desktop' option.
III How it all works
====================
The core OpenGL function calls are the same between Windows and
Linux. So what is the difficulty to support it in Wine ? Well, there
is two different problems :
- the interface to the windowing system is different for each
OS. It's called 'GLX' for Linux (well, for X Window) and 'wgl' for
Windows. Thus, one need first to emulate one (wgl) with the other
(GLX).
- the calling convention between Windows (the 'Pascal' convention or
'stdcall') is different from the one used on Linux (the 'C'
convention or 'cdecl'). This means that each call to an OpenGL
function must be 'translated' and cannot be used directly by the
Windows program.
Add to this some braindead programs (using GL calls without setting-up
a context or deleting three time the same context) and you have still
some work to do :-)
III.1 The Windowing system integration
--------------------------------------
This integration is done at two levels :
- at GDI level for all pixel format selection routines (ie choosing
if one wants a depth / alpha buffer, the size of these buffers,
...) and to do the 'page flipping' in double buffer mode. This is
implemented in 'graphics/x11drv/opengl.c' (all these functions are
part of Wine's graphic driver function pointer table and thus could
be reimplented if ever Wine works on another Windowing system than
X).
- in the OpenGL32.DLL itself for all other functionalities (context
creation / deletion, querying of extension functions, ...). This is
done in 'dlls/opengl32/wgl.c'.
III.2 The thunks
----------------
The thunks are the Wine code that does the calling convention
translation and they are auto-generated by a Perl script. In Wine's
CVS tree, these thunks are already generated for you. Now, if you want
to do it yourself, there is how it all works....
The script is located in dlls/opengl32 and is called 'make_opengl'. It
requires Perl5 to work and takes two arguments :
- the first is the path to the OpenGL registry. Now, you will all ask
'but what is the OpenGL registry ?' :-) Well, it's part of the
OpenGL sample implementation source tree from SGI (more
informations at this URL : http://oss.sgi.com/projects/ogl-sample/).
To summarize, these files contains human-readable but easily parsed
informations on ALL OpenGL core functions and ALL registered
extensions (for example the prototype, the OpenGL version, ...).
- the second is the OpenGL version to 'simulate'. This fixes the list
of functions that the Windows application can link directly to
without having to query them from the OpenGL driver. Windows is
based, for now, on OpenGL 1.1, but the thunks that are in the CVS
tree are generated for OpenGL 1.2.
This option can have three values '1.0', '1.1' and '1.2'.
This script generates three files :
- opengl32.spec gives Wine's linker the signature of all function in
the OpenGL32.DLL library so that the application can link
them. Only 'core' functions are listed here.
- opengl_norm.c contains all the thunks for the 'core'
functions. Your OpenGL library must provide ALL the function used
in this file as these are not queried at run time.
- opengl_ext.c contains all the functions that are not part of the
'core' functions. Contrary to the thunks in opengl_norm.c, these
functions do not depend at all on what your libGL provides.
In fact, before using one of these thunks, the Windows program
first needs to 'query' the function pointer. At this point, the
corresponding thunk is useless. But as we first query the same
function in libGL and store the returned function pointer in the
thunk, the latter becomes functional.
IV Known problems - shortcomings
=================================
IV.1 Missing GLU32.DLL
----------------------
GLU is a library that is layered upon OpenGL. There is a 100 %
corespondance between the libGLU.so that is used on Linux and
GLU32.DLL.
As for the moment, I did not create a set of thunks to support this
library natively in Wine (it would easy to do, but I am waiting for a
better solution than adding another autogenerated thunk file), you can
always download anywhere on the net (it's free) a GLU32.DLL file (by
browsing, for example, http://ftpsearch.lycos.com/).
IV.2 OpenGL not detected at configure time
------------------------------------------
See section (I) for a detailed explanation of the configure
requirements.
IV.3 When running an OpenGL application, the screen flickers
------------------------------------------------------------
See section (II) for how to create the context double-buffered and
thus preventing this flicker effect.
IV.4 Wine gives me the following error message :
------------------------------------------------
Extension defined in the OpenGL library but NOT in opengl_ext.c... Please report
(lionel.ulmer@free.fr) !
This means that the extension requested by the application is found in
the libGL used by Linux (ie the call to glXGetProcAddressARB returns a
non NULL pointer) but that this string was NOT found in Wine's
extension registry.
This can come from two causes :
- the opengl_ext.c file is too old and need to be generated again.
- use of obsolete extensions that are not supported anymore by SGI or
of 'private' extensions that are not registered. An example of the
former are 'glMTexCoord2fSGIS' and 'glSelectTextureSGIS' as used by
Quake 2 (and apparently also by old versions of Half Life). If
documentation can be found on these functions, they can be added to
Wine's extension set.
If you have this, run with --debugmsg +opengl and send me
(lionel.ulmer@free.fr) the TRACE.
IV.5 libopengl32.so is built but it is still not working
--------------------------------------------------------
This may be caused by some missing functions required by opengl_norm.c
but that your Linux OpenGL library does not provide.
To check for this, do the following steps :
- create a dummy .c file :
int main(void) {
return 0;
}
- try to compile it by linking both libwine and libopengl32 (this
command line supposes that you installed the Wine libraries in
/usr/local/lib, YMMV) :
gcc dummy.c -L/usr/local/lib -lwine -lopengl32
- if it works, the problem is somewhere else (and you can send me an
email). If not, you could re-generate the thunk files for OpenGL
1.1 for example (and send me your OpenGL version so that this
problem can be detected at configure time).
Lionel Ulmer (lionel.ulmer@free.fr)
last modification : 2000/06/13
documentation/patches.sgml 0 → 100644
View file @ 1e8e5ba8
<chapter id="patches">
<title>Submitting Patches</title>
<para>How to create patches, and where to send them...</para>
</chapter>
<!-- Keep this comment at the end of the file
Local variables:
mode: sgml
sgml-parent-document:("wine-doc.sgml" "book" "part" "chapter" "")
End:
-->
documentation/printing deleted 100644 → 0
View file @ c4fac786
Printing in Wine
================
Printing in Wine can be done in one of two ways. Both of which are very alpha.
1. Use a windows 3.1 printer driver.
2. Use the builtin Wine Postscript driver (+ ghostscript to produce output for
non-postscript printers).
Note that at the moment WinPrinters (cheap, dumb printers that require the host
computer to explicitly control the head) will not work. It is unclear whether
they ever will.
1. External printer drivers
---------------------------
At present only 16 bit drivers will work (note that these include win9x
drivers).
Add
printer=on
to the [wine] section of wine.conf (or ~/.winerc). This lets CreateDC proceed
if its driver argument is a 16 bit driver.
You will probably also need to add
TTEnable=0
TTOnly=0
to the [TrueType] section of win.ini .
The code for the driver interface is in graphics/win16drv .
2. Builtin Wine PostScript driver
---------------------------------
Enables printing of PostScript files via a driver built into Wine. See
documentation/psdriver for installation instructions. The code for the
PostScript driver is in graphics/psdrv .
Spooling
========
Spooling is rather primitive. The [spooler] section of wine.conf maps a port
(e.g. LPT1:) to a file or a command via a pipe. For example the following lines
LPT1:=foo.ps
LPT2:=|lpr
map LPT1: to file foo.ps and LPT2: to the lpr command. If a job is sent to an
unlisted port then a file is created with that port's name e.g. for LPT3: a
file called LPT3: would be created.
documentation/printing.sgml 0 → 100644
View file @ 1e8e5ba8
<chapter id="printing">
<title>Printing in Wine</title>
<para>How to print documents in Wine...</para>
<sect1 id="wine-printing">
<title>Printing</title>
<para>
written by (???)
</para>
<para>
(Extracted from <filename>wine/documentation/printing</filename>)
</para>
<para>
Printing in Wine can be done in one of two ways. Both of which are very
alpha.
</para>
<orderedlist>
<listitem>
<para>Use an external windows 3.1 printer driver.</para>
</listitem>
<listitem>
<para>
Use the builtin Wine Postscript driver (+ ghostscript to produce
output for non-postscript printers).
</para>
</listitem>
</orderedlist>
<para>
Note that at the moment WinPrinters (cheap, dumb printers that require
the host computer to explicitly control the head) will not work. It is
unclear whether they ever will.
</para>
<sect2>
<title>External printer drivers</title>
<para>
At present only 16 bit drivers will work (note that these include win9x
drivers). To use them, add
</para>
<screen>
printer=on
</screen>
<para>
to the [wine] section of <filename>wine.conf</filename> (or
<filename>~/.winerc</filename>). This lets
<function>CreateDC</function> proceed if its driver argument is a 16
bit driver. You will probably also need to add
</para>
<screen>
TTEnable=0 TTOnly=0
</screen>
<para>
to the [TrueType] section of <filename>win.ini</filename>. The code for
the driver interface is in <filename>graphics/win16drv</filename>.
</para>
</sect2>
<sect2>
<title>Builtin Wine PostScript driver</title>
<para>
Enables printing of PostScript files via a driver built into Wine. See
<filename>documentation/psdriver</filename> for installation
instructions. The code for the PostScript driver is in
<filename>graphics/psdrv</filename>.
</para>
</sect2>
<sect2>
<title>Spooling</title>
<para>
Spooling is rather primitive. The [spooler] section of
<filename>wine.conf</filename> maps a port (e.g.
<systemitem>LPT1:</systemitem>) to a file or a command via a pipe. For
example the following lines
</para>
<screen>
LPT1:=foo.ps LPT2:=|lpr
</screen>
<para>
map <systemitem>LPT1:</systemitem> to file <filename>foo.ps</filename>
and <systemitem>LPT2:</systemitem> to the <command>lpr</command>
command. If a job is sent to an unlisted port then a file is created
with that port's name e.g. for <systemitem>LPT3:</systemitem> a file
called <systemitem>LPT3:</systemitem> would be created.
</para>
</sect2>
</sect1>
<sect1 id="psdriver">
<title>The Wine PostScript Driver</title>
<para>
written by Huw Davies <email>h.davies1@physics.ox.ac.uk</email>
</para>
<para>
(Extracted from <filename>wine/documentation/psdriver</filename>)
</para>
<para>
When complete this will allow Wine to generate PostScript files without
needing an external printer driver. It should be possible to print to a
non PostScript printer by filtering the output through ghostscript.
</para>
<sect2>
<title>Installation</title>
<para>
The driver behaves as if it were a DRV file called
<filename>wineps.drv</filename> which at the moment is built into Wine.
Although it mimics a 16 bit driver it will work with both 16 and 32 bit
apps, just as win9x drivers do.
</para>
<para>
To install it add
</para>
<screen>
Wine PostScript Driver=WINEPS,LPT1:
</screen>
<para>
to the [devices] section of <filename>win.ini</filename> and to set it
as the default printer also add
</para>
<screen>
device=Wine PostScript Driver,WINEPS,LPT1:
</screen>
<para>
to the [windows] section of <filename>win.ini</filename> and ???
<emphasis>[sic]</emphasis>
</para>
<para>
To run 32 bit apps (and 16 bit apps using the
<literal>builtin</literal> commdlg) you also need to add certain
entries to the registry. The easiest way to do that at the moment is
to use the winelib program <command>programs/regapi/regapi</command>
with the file <filename>documentation/psdrv.reg</filename>. To do this
<command>cd</command> to <filename>programs/regapi/regapi</filename>
and type <userinput>make</userinput> to actually make the program, then
type <userinput>./regapi setValue
&lt;../../documentation/psdrv.reg</userinput>. You can obviously
edit <filename>psdrv.reg</filename> to suit your requirements.
</para>
<para>
You will need Adobe Font Metric (AFM) files for the (type 1 PostScript)
fonts that you wish to use. You can get these from
<ulink url="ftp://ftp.adobe.com/pub/adobe/type/win/all/afmfiles">
ftp://ftp.adobe.com/pub/adobe/type/win/all/afmfiles </ulink>. The
directories <filename>base17</filename> or <filename>base35</filename>
are good places to start. Note that these are only the font metrics and
not the fonts themselves. At the moment the driver does not download
additional fonts, so you can only use fonts that are already present on
the printer.
</para>
<para>
Then create a [afmfiles] section in your
<filename>wine.conf</filename> (or
<filename>~/.winerc</filename>) and add a line of the form
</para>
<screen>
file&lt;n&gt;=/unix/path/name/filename.afm
</screen>
<para>
for each AFM file that you wish to use. [This might change in the future]
</para>
<para>
You also require a PPD file for your printer. This describes certain
characteristics of the printer such as which fonts are installed, how
to select manual feed etc. Adobe also has many of these on its website,
have a look in <ulink url="ftp://ftp.adobe.com/pub/adobe/printerdrivers/win/all/">
ftp://ftp.adobe.com/pub/adobe/printerdrivers/win/all/</ulink>. Create
a [psdrv] section in your <filename>wine.conf</filename> (or
<filename>~/.winerc</filename>) and add the following entry:
</para>
<screen>
ppdfile=/somewhere/file.ppd
</screen>
<para>
By default, the driver will look for a file named
<filename>default.ppd</filename> in the directory from which
you started wine.
</para>
<para>
To enable colour printing you need to have the
<literal>*ColorDevice</literal> entry in the PPD set to
<literal>true</literal>, otherwise the driver will generate
greyscale.
</para>
<para>
Note that you need not set <literal>printer=on</literal> in
the [wine] section of <filename>wine.conf</filename>, this
enables printing via external printer drivers and does not
affect wineps.
</para>
<para>
If you're lucky you should now be able to produce PS files
from Wine!
</para>
<para>
I've tested it with win3.1 notepad/write, Winword6 and
Origin4.0 and 32 bit apps such as win98 wordpad, Winword97,
Powerpoint2000 with some degree of success - you should be
able to get something out, it may not be in the right place.
</para>
</sect2>
<sect2>
<title>TODO / Bugs</title>
<itemizedlist>
<listitem>
<para>
Driver does read PPD files, but ignores all constraints
and doesn't let you specify whether you have optional
extras such as envelope feeders. You will therefore find
a larger than normal selection of input bins in the
print setup dialog box. I've only really tested ppd
parsing on the <filename>hp4m6_v1.ppd</filename> file.
</para>
</listitem>
<listitem>
<para>No TrueType download.</para>
</listitem>
<listitem>
<para>StretchDIBits uses level 2 PostScript.</para>
</listitem>
<listitem>
<para>AdvancedSetup dialog box.</para>
</listitem>
<listitem>
<para>Many partially implemented functions.</para>
</listitem>
<listitem>
<para>ps.c is becoming messy.</para>
</listitem>
<listitem>
<para>
Notepad often starts text too far to the left depending
on the margin settings. However the win3.1
<filename>pscript.drv</filename> (under wine) also does
this.
</para>
</listitem>
<listitem>
<para>Probably many more...</para>
</listitem>
</itemizedlist>
<para>
Please contact me if you want to help so that we can avoid duplication.
</para>
<para>
Huw Davies <email>h.davies1@physics.ox.ac.uk</email>
</para>
</sect2>
</sect1>
</chapter>
<!-- Keep this comment at the end of the file
Local variables:
mode: sgml
sgml-parent-document:("wine-doc.sgml" "book" "chapter" "")
End:
-->
documentation/psdriver deleted 100644 → 0
View file @ c4fac786
Wine PostScript Driver
======================
When complete this will allow Wine to generate PostScript files without needing
an external printer driver. It should be possible to print to a non PostScript
printer by filtering the output through ghostscript.
Installation
------------
The driver behaves as if it were a DRV file called WINEPS.DRV which at the
moment is built into Wine. Although it mimics a 16 bit driver it will work
with both 16 and 32 bit apps, just as win9x drivers do.
To install it add
Wine PostScript Driver=WINEPS,LPT1:
to the [devices] section of win.ini and to set it as the default printer also
add
device=Wine PostScript Driver,WINEPS,LPT1:
to the [windows] section of win.ini and
To run 32 bit apps (and 16 bit apps using the builtin commdlg) you also need to
add certain entries to the registry. The easiest way to do that at the moment
is to use the winelib program programs/regapi/regapi with the file
documentation/psdrv.reg . To do this cd to programs/regapi/regapi and type
`make' to actually make the program, then type
`./regapi setValue <../../documentation/psdrv.reg' . You can obviously edit
psdrv.reg to suit your requirements.
You will need Adobe Font Metric (AFM) files for the (type 1 PostScript) fonts
that you wish to use. You can get these from
ftp://ftp.adobe.com/pub/adobe/type/win/all/afmfiles . The directories base17
or base35 are good places to start. Note that these are only the font metrics
and not the fonts themselves. At the moment the driver does not download
additional fonts, so you can only use fonts that are already present on the
printer.
Then create a [afmfiles] section in your wine.conf (or ~/.winerc) and add a
line of the form
file<n>=/unix/path/name/filename.afm
for each AFM file that you wish to use. [This might change in the future]
You also require a PPD file for your printer. This describes certain
characteristics of the printer such as which fonts are installed, how to select
manual feed etc. Adobe also has many of these on its website, have a look in
ftp://ftp.adobe.com/pub/adobe/printerdrivers/win/all/
Create a [psdrv] section in your wine.conf (or ~/.winerc) and add the
following entry:
ppdfile=/somewhere/file.ppd
By default, the driver will look for a file named default.ppd in the directory
from which you started wine.
To enable colour printing you need to have the *ColorDevice entry in the PPD
set to true, otherwise the driver will generate greyscale.
Note that you need not set printer=on in the [wine] section of wine.conf, this
enables printing via external printer drivers and does not affect wineps.
If you're lucky you should now be able to produce PS files from Wine!
I've tested it with win3.1 notepad/write, Winword6 and Origin4.0 and 32 bit
apps such as win98 wordpad, Winword97, Powerpoint2000 with some degree of
success - you should be able to get something out, it may not be in the right
place.
If you don't have a PostScript printer here is a short additional description
how to get the Wine PostScript Driver running with ghostscript. I had some
success with ghostscript 5.10 from the SuSE 6.2 distribution. My ghostscript
package contains some AFM files in the directory /usr/share/ghostscript/fonts.
I have used these for the [afmfiles] section in my wine.conf (or ~/.winerc)
file.
There are also two PPD file in my ghostscript package. They are located in the
directory /usr/share/ghostscript/5.10. I have used the file cbjc600.ppd because
of the supported papersize. Because my PPD file needed some changes i have
copyed it to /usr/local/etc/gs.ppd and enterd it into the [psdrv] section in
my wine.conf (or ~/.winerc) file.
When i started wine after this settings i got an error when wine tried to pars
the PPD file. There was the ':' missing in the line:
*CloseUI: *PrintColors
After this fix the PPD file was successfull parsed, but printing was still not
possible. The reason is that the PPD file contains no font information. To
create the font information I run wine with -debugmsg +font and redirected the
output into a file. Than I filterd the file for lines containing 'FontName'
using the grep command and extracted the names of the fonts with the cut
command into a new file.
grep FontName LOGFILE | cut -f 2 -d\' | sort -u > add.ppd
Now '*Font ' needs to be inserted at the beginning of each line of the new
file. The end of each line needs to become ': Standard'. The last step is to
add these line to the PPD file. After this I was able to print some text using
wines buildin PostScript driver and ghostscript.
TODO / Bugs
-----------
Driver does read PPD files, but ignores all constraints and doesn't let you
specify whether you have optional extras such as envelope feeders. You will
therefore find a larger than normal selection of input bins in the print setup
dialog box. I've only really tested ppd parsing on the hp4m6_v1.ppd file.
No TrueType download.
StretchDIBits uses level 2 PostScript.
AdvancedSetup dialog box.
Many partially implemented functions.
ps.c is becoming messy.
Notepad often starts text too far to the left depending on the margin
settings. However the win3.1 pscript.drv (under wine) also does this.
Probably many more...
Please contact me if you want to help so that we can avoid duplication.
Huw Davies <h.davies1@physics.ox.ac.uk>
documentation/registry deleted 100644 → 0
View file @ c4fac786
The Registry
------------
After Win3.x, the registry became a fundamental part of Windows. It is
the place where both Windows itself, and all
Win95/98/NT/2000/whatever-compliant applications, store configuration
and state data. While most sane system administrators (and Wine
developers) curse badly at the twisted nature of the Windows registry,
it is still necessary for Wine to support it somehow.
Registry structure
The Windows registry is an elaborate tree structure, and not even most
Windows programmers are fully aware of how the registry is laid out,
with its different "hives" and numerous links between them; a full
coverage is out of the scope of this document. But here are the basic
registry keys you might need to know about for now.
HKEY_LOCAL_MACHINE
This fundamental root key (in win9x, stored in the hidden file
system.dat) contains everything pertaining to the current
Windows installation.
HKEY_USERS
This fundamental root key (in win9x, stored in the hidden file
user.dat) contains configuration data for every user of the
installation.
HKEY_CLASSES_ROOT
This is a link to HKEY_LOCAL_MACHINE\Software\Classes. It
contains data describing things like file associations, OLE
document handlers, and COM classes.
HKEY_CURRENT_USER
This is a link to HKEY_USERS\your_username, i.e., your personal
configuration.
Using a Windows registry
If you point Wine at an existing MS Windows installation (by setting
the appropriate directories in wine.conf/.winerc), then Wine is able
to load registry data from it. However, Wine will not save anything to
the real Windows registry, but rather to its own registry files (see
below). Of course, if a particular registry value exists in both the
Windows registry and in the Wine registry, then Wine will use the
latter.
Occasionally, Wine may have trouble loading the Windows registry.
Usually, this is because the registry is inconsistent or damaged in
some way. If that becomes a problem, you may want to download the
regclean.exe from the MS website and use it to clean up the registry.
Alternatively, you can always use regedit.exe to export the registry
data you want into a text file, and then import it in Wine.
Wine registry data files
In the user's home directory, there is a subdirectory named .wine,
where Wine will try to save its registry by default. It saves into
four files, which are:
system.reg
This file contains HKEY_LOCAL_MACHINE.
user.reg
This file contains HKEY_CURRENT_USER.
userdef.reg
This file contains HKEY_USERS\.Default (i.e. the default user
settings).
wine.userreg
Wine saves HKEY_USERS to this file (both current and default
user), but does not load from it, unless userdef.reg is
missing.
All of these files are human-readable text files, so unlike Windows,
you can actually use an ordinary text editor on them if you must.
In addition to these files, Wine can also optionally load from global
registry files residing in the same directory as the global wine.conf
(i.e. /usr/local/etc if you compiled from source). These are:
wine.systemreg
Contains HKEY_LOCAL_MACHINE.
wine.userreg
Contains HKEY_USERS.
System administration
With the above file structure, it is possible for a system
administrator to configure the system so that a system Wine
installation (and applications) can be shared by all the users, and
still let the users all have their own personalized configuration. An
administrator can, after having installed Wine and any Windows
application software he wants the users to have access to, copy the
resulting system.reg and wine.userreg over to the global registry
files (which we assume will reside in /usr/local/etc here), with:
cd ~/.wine
cp system.reg /usr/local/etc/wine.systemreg
cp wine.userreg /usr/local/etc/wine.userreg
and perhaps even symlink these back to the administrator's account, to
make it easier to install apps system-wide later:
ln -sf /usr/local/etc/wine.systemreg system.reg
ln -sf /usr/local/etc/wine.userreg wine.userreg
Note that the tools/wineinstall script already does all of this for
you, if you install Wine as root. If you then install Windows
applications while logged in as root, all your users will
automatically be able to use them. While the application setup will be
taken from the global registry, the users' personalized configurations
will be saved in their own home directories.
But be careful with what you do with the administrator account - if
you do copy or link the administrator's registry to the global
registry, any user might be able to read the administrator's
preferences, which might not be good if sensitive information
(passwords, personal information, etc) is stored there. Only use the
administrator account to install software, not for daily work; use an
ordinary user account for that.
The default registry
A Windows registry contains many keys by default, and some of them are
necessary for even installers to operate correctly. The keys that the
Wine developers have found necessary to install applications are
distributed in a file called "winedefault.reg". It is automatically
installed for you if you use the tools/wineinstall script, but if you
want to install it manually, you can do so by using the regapi tool.
You can find more information about this in the
documentation/no-windows document in the Wine distribution.
The [registry] section
With the above information fresh in mind, let's look at the
wine.conf/.winerc options for handling the registry.
LoadGlobalRegistryFiles
Controls whether to try to load the global registry files, if
they exist.
LoadHomeRegistryFiles
Controls whether to try to load the user's registry files (in
the .wine subdirectory of the user's home directory).
LoadWindowsRegistryFiles
Controls whether Wine will attempt to load registry data from a
real Windows registry in an existing MS Windows installation.
WritetoHomeRegistryFiles
Controls whether registry data will be written to the user's
registry files. (Currently, there is no alternative, so if you
turn this off, Wine cannot save the registry on disk at all;
after you exit Wine, your changes will be lost.)
UseNewFormat
This option is obsolete. Wine now always use the new format;
support for the old format was removed a while ago.
PeriodicSave
If this option is set to a nonzero value, it specifies that you
want the registry to be saved to disk at the given interval. If
it is not set, the registry will only be saved to disk when the
wineserver terminates.
SaveOnlyUpdatedKeys
Controls whether the entire registry is saved to the user's
registry files, or only subkeys the user have actually changed.
Considering that the user's registry will override any global
registry files and Windows registry files, it usually makes
sense to only save user-modified subkeys; that way, changes to
the rest of the global or Windows registries will still affect
the user.
- Ove Kåven
documentation/resources deleted 100644 → 0
View file @ c4fac786
This document desribes tools for handling resources within wine
### bin2res ###
This tool allows the editing of embedded binary resources within
*.rc files. These resources are stored as hex dump so they can be
stored within the cvs. This makes the editing of the embedded
bitmaps and icons harder.
### Create binary files from.rc ###
the resources in the .rc file have to be marked by a header:
/* BINRES idb_std_small.bmp */
IDB_STD_SMALL BITMAP LOADONCALL DISCARDABLE
{
'42 4D 20 07 00 00 00 00 00 00 76 00 00 00 28 00'
BINRES is the keyword followed by a filename.
"bin2res -d bin rsrc.rc" generates binary files from all marked
resources. If the binary file is newer it gets not overwritten.
To force overwriting use the -f switch.
### Create a .rc file from binaries ###
Put a header followed by empty brackets in the.rc file.
/* BINRES idb_std_small.bmp */
{}
Then run "bin2res rsrc.rc". It will merge the resources into the
.rc file if the binary resources are newer than the.rc file.
To force the resources into the.rc file use the -f switch.
If there is already a resource with the same filename in the.rc
file it gets overwritten.
### output of bin2res ###
bash-2.03# ../../tools/bin2res -d bin shres.rc
[000.ico:c][003.ico:c][008.ico:s][015.ico:s][034.ico:s]
s means skiped, c means changed
---
juergen.schmied@debitel.net (11/99)
documentation/running.sgml 0 → 100644
View file @ 1e8e5ba8
<chapter id="running">
<title>Running Wine</title>
<para>Explain the command-line options you can use to run Wine</para>
<sect1 id="running-wine">
<title>How to run Wine</title>
<para>
The first thing you need to do is...
</para>
</sect1>
</chapter>
<!-- Keep this comment at the end of the file
Local variables:
mode: sgml
sgml-parent-document:("wine-doc.sgml" "book" "chapter" "")
End:
-->
documentation/tools.sgml 0 → 100644
View file @ 1e8e5ba8
<chapter id="tools">
<title>Tools</title>
<sect1 id="bin2res">
<title>bin2res</title>
<para>
written by juergen.schmied@debitel.net (11/99)
</para>
<para>
(Extracted from <filename>wine/documentation/resources</filename>)
</para>
<para>
This document desribes tools for handling resources within wine
</para>
<sect2>
<title>bin2res</title>
<para>
This tool allows the editing of embedded binary resources
within <filename>*.rc</filename> files. These resources are
stored as hex dump so they can be stored within the cvs
tree. This makes the editing of the embedded bitmaps and
icons harder.
</para>
</sect2>
<sect2>
<title>Create binary files from an <filename>.rc</filename> file</title>
<para>
The resources in the <filename>.rc</filename> file have to
be marked by a header:
</para>
<programlisting>
/* BINRES idb_std_small.bmp */
IDB_STD_SMALL BITMAP LOADONCALL DISCARDABLE
{
'42 4D 20 07 00 00 00 00 00 00 76 00 00 00 28 00'
</programlisting>
<para>
<constant>BINRES</constant> is the keyword followed by a
filename. <command>bin2res -d bin rsrc.rc</command>
generates binary files from all marked resources. If the
binary file is newer it gets not overwritten. To force
overwriting use the <parameter>-f</parameter> switch.
</para>
</sect2>
<sect2>
<title>Create a <filename>.rc</filename> file from binaries</title>
<para>
Put a header followed by empty brackets in the
<filename>.rc</filename> file.
</para>
<programlisting>
/* BINRES idb_std_small.bmp */
{}
</programlisting>
<para>
Then run <command>bin2res rsrc.rc</command>. It will merge
the resources into the <filename>.rc</filename> file if the
binary resources are newer than the.rc file. To force the
resources into the <filename>.rc</filename> file use the
<parameter>-f</parameter> switch. If there is already a
resource with the same filename in the
<filename>.rc</filename> file it gets overwritten.
</para>
</sect2>
<sect2>
<title>output of <command>bin2res</command></title>
<programlisting>
bash-2.03# ../../tools/bin2res -d bin shres.rc
[000.ico:c][003.ico:c][008.ico:s][015.ico:s][034.ico:s]
</programlisting>
<para>
<literal>s</literal> means skipped, <literal>c</literal>
means changed.
</para>
</sect2>
</sect1>
</chapter>
<!-- Keep this comment at the end of the file
Local variables:
mode: sgml
sgml-parent-document:("wine-doc.sgml" "book" "part" "chapter" "")
End:
-->
documentation/ttfserver deleted 100644 → 0
View file @ c4fac786
1. Get freetype-1.0.full.tar.gz
2. Read docus, unpack, configure and install
3. Test the library, e.g. "ftview 20 /dosc/win95/fonts/times "
4. Get xfsft-beta1e.linux-i586
5. Install it and start it when booting, e.g. in an rc-script.
The manpage for xfs applies.
6. Follow the hints given by williamc@dai.ed.ac.uk
==========
I got xfsft from http://www.dcs.ed.ac.uk/home/jec/progindex.html.
I have it running all the time. Here is /usr/X11R6/lib/X11/fs/config:
clone-self = on
use-syslog = off
catalogue = /c/windows/fonts
error-file = /usr/X11R6/lib/X11/fs/fs-errors
default-point-size = 120
default-resolutions = 75,75,100,100
Obviously /c/windows/fonts is where my Windows fonts on my
Win95 C: drive live; could be e.g. /mnt/dosC/windows/system
for Win31.
In /c/windows/fonts/fonts.scale I have
14
arial.ttf -monotype-arial-medium-r-normal--0-0-0-0-p-0-iso8859-1
arialbd.ttf -monotype-arial-bold-r-normal--0-0-0-0-p-0-iso8859-1
arialbi.ttf -monotype-arial-bold-o-normal--0-0-0-0-p-0-iso8859-1
ariali.ttf -monotype-arial-medium-o-normal--0-0-0-0-p-0-iso8859-1
cour.ttf -monotype-courier-medium-r-normal--0-0-0-0-p-0-iso8859-1
courbd.ttf -monotype-courier-bold-r-normal--0-0-0-0-p-0-iso8859-1
courbi.ttf -monotype-courier-bold-o-normal--0-0-0-0-p-0-iso8859-1
couri.ttf -monotype-courier-medium-o-normal--0-0-0-0-p-0-iso8859-1
times.ttf -monotype-times-medium-r-normal--0-0-0-0-p-0-iso8859-1
timesbd.ttf -monotype-times-bold-r-normal--0-0-0-0-p-0-iso8859-1
timesbi.ttf -monotype-times-bold-i-normal--0-0-0-0-p-0-iso8859-1
timesi.ttf -monotype-times-medium-i-normal--0-0-0-0-p-0-iso8859-1
symbol.ttf -monotype-symbol-medium-r-normal--0-0-0-0-p-0-microsoft-symbol
wingding.ttf -microsoft-wingdings-medium-r-normal--0-0-0-0-p-0-microsoft-symbol
In /c/windows/fonts/fonts.dir I have exactly the same.
In /usr/X11R6/lib/X11/XF86Config I have
FontPath "tcp/localhost:7100"
in front of the other FontPath lines.
That's it! As an interesting by-product of course, all those web
pages which specify Arial come up in Arial in Netscape ...
=======
7. Shut down X and restart ( and debug errors you did while setting
up everything.
8. Test with e.g "xlsfont |grep arial"
Hope this helps
\ No newline at end of file
documentation/win95look deleted 100644 → 0
View file @ c4fac786
Win95/Win98 interface code is being introduced.
Instead of compiling Wine for Win3.1 vs. Win95 using #define switches,
the code now looks in a special [Tweak.Layout] section of wine.conf
for a "WineLook=Win95" or "WineLook=Win98" entry.
A few new sections and a number of entries have been added to the
wine.conf file -- these are for debugging the Win95 tweaks only and may
be removed in a future release! These entries/sections are:
[Tweak.Fonts]
System.Height=<point size> # Sets the height of the system typeface
System.Bold=[true|false] # Whether the system font should be boldfaced
System.Italic=[true|false] # Whether the system font should be italicized
System.Underline=[true|false] # Whether the system font should be underlined
System.StrikeOut=[true|false] # Whether the system font should be struck out
OEMFixed.xxx # Same parameters for the OEM fixed typeface
AnsiFixed.xxx # Same parameters for the Ansi fixed typeface
AnsiVar.xxx # Same parameters for the Ansi variable typeface
SystemFixed.xxx # Same parameters for the System fixed typeface
[Tweak.Layout]
WineLook=[Win31|Win95|Win98] # Changes Wine's look and feel
documentation/wine-doc.sgml 0 → 100644
View file @ 1e8e5ba8
<!doctype book PUBLIC "-//OASIS//DTD DocBook V3.1//EN" [
<!entity running SYSTEM "running.sgml">
<!entity installing SYSTEM "installing.sgml">
<!entity configuring SYSTEM "configuring.sgml">
<!entity registry SYSTEM "registry.sgml">
<!entity bugs SYSTEM "bugs.sgml">
<!entity fonts SYSTEM "fonts.sgml">
<!entity printing SYSTEM "printing.sgml">
<!entity compiling SYSTEM "compiling.sgml">
<!entity debugging SYSTEM "debugging.sgml">
<!entity documentation SYSTEM "documentation.sgml">
<!entity patches SYSTEM "patches.sgml">
<!entity i18n SYSTEM "i18n.sgml">
<!entity porting SYSTEM "porting.sgml">
<!entity packaging SYSTEM "packaging.sgml">
<!entity architecture SYSTEM "architecture.sgml">
<!entity debugger SYSTEM "debugger.sgml">
<!entity consoles SYSTEM "consoles.sgml">
<!entity implementation SYSTEM "implementation.sgml">
<!entity opengl SYSTEM "opengl.sgml">
<!entity build SYSTEM "build.sgml">
<!entity tools SYSTEM "tools.sgml">
<!entity dlls SYSTEM "dlls.sgml">
<!entity status SYSTEM "status.sgml">
]>
<book id="index">
<bookinfo>
<title>Wine Documentation</title>
</bookinfo>
<preface id="preface">
<title>Notes About this Document</title>
<para>
The following documentation has been extracted from the Wine
source tree, from the <filename>wine/documentation</filename>
directory. So far, no new content has been added aside from
marking it up for DocBook and a few minor tweaks to smooth
that process. All credit should go to the original authors,
who are attributed according the the "written by" comments
in those files. If I've missed anyone, please contact
<email>John R. Sheets &lt;jsheets@codeweavers.com></email>
</para>
</preface>
<part id="part-one">
<title>Using Wine</title>
&running;
&installing;
&configuring;
&bugs;
&fonts;
&printing;
</part>
<part id="part-two">
<title>Developing Wine</title>
&compiling;
&debugging;
&documentation;
&patches;
&i18n;
&porting;
</part>
<part id="part-three">
<title>Distributing Wine</title>
&packaging;
</part>
<part id="part-four">
<title>Wine Architecture</title>
&architecture;
&debugger;
&consoles;
&implementation;
&opengl;
&build;
&tools;
&dlls;
</part>
</book>
documentation/wine_os2 deleted 100644 → 0
View file @ c4fac786
Running & Compiling WINE in OS/2
If you want to help for the port of WINE to OS/2,
send me a message at krynos@clic.net
I currently don't want beta testers. It must work before we can test it.
Here is what you need to (try to) compile Wine for OS/2:
EMX 0.9c (fix 2)
XFree86 3.2 OS/2 (with development libraries)
bash, gnu make, grep, tar, bison, flex
sed (a working copy of)
xpm
diff and patch are recommended
Lots of disk space (about 40-50 megs after EMX and XFree installed)
To compile:
sh
tools/make_os2.sh
make depend
make
emxbind wine
Currently:
- configure and make depend work...
- make compiles (with a modified Linux mman.h), but doesn't link.
- signal handling is horrible... (if any)
- EMX doesn't support mmap (and related), SysV IPC and stafs()
- XFree86/OS2 3.2 doesn't support XShmQueryExtension() and XShmPixmapFormat()
due to the same lack in EMX...
What needs to be redone:
- LDT (using DosAllocSeg in memory/ldt.c) *
- implement mmap() and SysV IPC in EMX *
- File functions,
- I/O access (do it!),
- Communication (modem),
- Interrupt (if int unknown, call current RealMode one...),
- verify that everything is thread safe (how does Win95/NT handle multi-thread?),
- move X functions in some files (and make a wrapper, to use PM instead latter),
- return right CPU type,
- make winsock work
* Top priority
The good things:
- OS/2 have DOS interrupts
- OS/2 have I/O port access
- OS/2 have multi-thread
- Merlin have Open32 (to be used later...)
Robert Pouliot <krynos@clic.net>
January 9, 1997

documentation/x11drv deleted 100644 → 0
View file @ c4fac786
The X11 driver
--------------
Most Wine users run Wine under the windowing system known as X11.
During most of Wine's history, this was the only display driver
available, but in recent years, parts of Wine has been reorganized to
allow for other display drivers (although the only alternative
currently available is Patrik Stridvall's ncurses-based ttydrv, which
he claims works for displaying calc.exe). The display driver is chosen
with the "GraphicsDriver" option in the [wine] section of
wine.conf/.winerc, but I will only cover the x11drv in this document.
x11drv modes of operation
The x11drv consists of two conceptually distinct pieces, the graphics
driver (GDI part), and the windowing driver (USER part). Both of these
are linked into the libx11drv.so module, though (which you load with
the "GraphicsDriver" option). In Wine, running on X11, the graphics
driver must draw on drawables (window interiors) provided by the
windowing driver. This differs a bit from the Windows model, where the
windowing system creates and configures device contexts controlled by
the graphics driver, and applications are allowed to hook into this
relationship anywhere they like. Thus, to provide any reasonable
tradeoff between compatibility and usability, the x11drv has three
different modes of operation.
Unmanaged/Normal
The default. Window-manager-independent (any running window
manager is ignored completely). Window decorations (title bars,
borders, etc) are drawn by Wine to look and feel like the real
Windows. This is compatible with applications that depend on
being able to compute the exact sizes of any such decorations,
or that want to draw their own.
Managed
Specified by using the --managed command-line option or the
Managed wine.conf option (see below). Ordinary top-level frame
windows with thick borders, title bars, and system menus will
be managed by your window manager. This lets these applications
integrate better with the rest of your desktop, but may not
always work perfectly. (A rewrite of this mode of operation, to
make it more robust and less patchy, is highly desirable,
though, and is planned to be done before the Wine 1.0 release.)
Desktop-in-a-Box
Specified by using the --desktop command-line option (with a
geometry, e.g. --desktop 800x600 for a such-sized desktop, or
even --desktop 800x600+0+0 to automatically position the
desktop at the upper-left corner of the display). This is the
mode most compatible with the Windows model. All application
windows will just be Wine-drawn windows inside the
Wine-provided desktop window (which will itself be managed by
your window manager), and Windows applications can roam freely
within this virtual workspace and think they own it all,
without disturbing your other X apps.
The [x11drv] section
AllocSystemColors
Applies only if you have a palette-based display, i.e. if your
X server is set to a depth of 8bpp, and if you haven't
requested a private color map. It specifies the maximum number
of shared colormap cells (palette entries) Wine should occupy.
The higher this value, the less colors will be available to
other applications.
PrivateColorMap
Applies only if you have a palette-based display, i.e. if your
X server is set to a depth of 8bpp. It specifies that you don't
want to use the shared color map, but a private color map,
where all 256 colors are available. The disadvantage is that
Wine's private color map is only seen while the mouse pointer
is inside a Wine window, so psychedelic flashing and funky
colors will become routine if you use the mouse a lot.
PerfectGraphics
This option only determines whether fast X11 routines or exact
Wine routines will be used for certain ROP codes in blit
operations. Most users won't notice any difference.
ScreenDepth
Applies only to multi-depth displays. It specifies which of the
available depths Wine should use (and tell Windows apps about).
Display
This specifies which X11 display to use, and if specified, will
override both the DISPLAY environment variable and the
--display command-line option.
Managed
Wine can let frame windows be managed by your window manager.
This option specifies whether you want that by default.
UseDGA
This specifies whether you want DirectDraw to use XFree86's
Direct Graphics Architecture (DGA), which is able to take over
the entire display and run the game full-screen at maximum
speed. (With DGA1 (XFree86 3.x), you still have to configure
the X server to the game's requested bpp first, but with DGA2
(XFree86 4.x), runtime depth-switching may be possible,
depending on your driver's capabilities.) But be aware that if
Wine crashes while in DGA mode, it may not be possible to
regain control over your computer without rebooting. DGA
normally requires either root privileges or read/write access
to /dev/mem.
UseXShm
If you don't want DirectX to use DGA, you can at least use X
Shared Memory extensions (XShm). It is much slower than DGA,
since the app doesn't have direct access to the physical frame
buffer, but using shared memory to draw the frame is at least
faster than sending the data through the standard X11 socket,
even though Wine's XShm support is still known to crash
sometimes.
DXGrab
If you don't use DGA, you may want an alternative means to
convince the mouse cursor to stay within the game window. This
option does that. Of course, as with DGA, if Wine crashes,
you're in trouble (although not as badly as in the DGA case,
since you can still use the keyboard to get out of X).
DesktopDoubleBuffered
Applies only if you use the --desktop command-line option to
run in a desktop window. Specifies whether to create the
desktop window with a double-buffered visual, something most
OpenGL games need to run correctly.
- Ove Kåven
Markdown is supported
0% or
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment