Skip to content
Snippets Groups Projects
Commit 1e8e5ba8 authored by John R. Sheets's avatar John R. Sheets Committed by Alexandre Julliard
Browse files

Converted Wine documentation to SGML format.

parent c4fac786
No related branches found
No related tags found
No related merge requests found
Showing
with 5984 additions and 2412 deletions
......@@ -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
......
*.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
......@@ -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:
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.
This diff is collapsed.
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
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 :-)
<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:
-->
<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:
-->
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
COMMON CONTROLS
their development status
and their UNDOCUMENTED features and functions
-----------------------------------------------------
1. Introduction
---------------
The information provided herein is based on the dll version 4.72 which
is included in MS Internet Explorer 4.01.
All information about common controls should be collected in this document.
All Wine programmers are encouraged to add their knowledge to this document.
2. General Information
----------------------
Further information about common controls can be found in the MS Platform SDK
and the MS Internet Client SDK (most recent). Information from these SDK's
will NOT be repeated here. Only information which can NOT be found in these
SDK's will be collected here. Some information in the SDK's mentioned above
is (intentionally???) WRONG. Corrections to wrong information will be
collected here too.
2.1 Structure sizes of different common control versions
--------------------------------------------------------
The common controls have been continously improved in the past. Some of the
orignal structures had to be extended and their size changed. Most of the
common control structures include their size as the first parameter. If
a control gets the wrong size in a message or function a failure is very
likely to occur. To avoid this, MS defined new constants that reflect the
structure size of older COMCTL32.DLL versions. The following list shows the
structure size constants that are currently defined in the original
COMCTL32.DLL.
NOTE: Some stuctures are NOT defined in wine's COMCTL32 yet.
HDITEM_V1_SIZE:
The size of the HDITEM structure in version 4.00.
LVCOLUMN_V1_SIZE:
The size of the LVCOLUMN structure in version 4.00.
LVHITTESTINFO_V1_SIZE:
The size of the LVHITTESTINFO structure in version 4.00.
LVITEM_V1_SIZE:
The size of the LVITEM structure in version 4.00.
NMLVCUSTOMDRAW_V3_SIZE:
The size of the NMLVCUSTOMDRAW structure in version 4.70.
NMTTDISPINFO_V1_SIZE:
The size of the NMTTDISPINFO structure in version 4.00.
NMTVCUSTOMDRAW_V3_SIZE:
The size of the NMTVCUSTOMDRAW structure in version 4.70.
PROPSHEETHEADER_V1_SIZE:
The size of the PROPSHEETHEADER structure in version 4.00.
PROPSHEETPAGE_V1_SIZE:
The size of the PROPSHEETPAGE structure in version 4.00.
REBARBANDINFO_V3_SIZE:
The size of the REBARBANDINFO structure in version 4.70.
TTTOOLINFO_V1_SIZE:
The size of the TOOLINFO structure in version 4.00.
TVINSERTSTRUCT_V1_SIZE:
The size of the TVINSERTSTRUCT structure in version 4.00.
3. Controls
-----------
This paragraph describes the development status of the common controls.
3.1 Animation Control
---------------------
Author:
Dummy written by Eric Kohl. <ekohl@abo.rhein-zeitung.de>
Status:
Dummy control. No functionality.
Notes:
Author needed!! Any volunteers??
3.2 Combo Box Ex Control
------------------------
Author:
Dummy written by Eric Kohl. <ekohl@abo.rhein-zeitung.de>
Status:
Dummy control. No functionality.
Notes:
Author needed!! Any volunteers??
3.3 Date and Time Picker Control
--------------------------------
Author:
Dummy written by Eric Kohl. <ekohl@abo.rhein-zeitung.de>
Status:
Dummy control. No functionality.
Notes:
Author needed!! Any volunteers??
3.4 Drag List Box Control
-------------------------
Author:
Dummy written by Eric Kohl. <ekohl@abo.rhein-zeitung.de>
Status:
Dummy control. No functionality.
Notes:
Author needed!! Any volunteers??
3.5 Flat Scroll Bar Control
---------------------------
Author:
Dummy written by Alex Priem. <alexp@sci.kun.nl>
Status:
Dummy control. No functionality.
Notes:
Author needed!! Any volunteers??
3.6 Header Control
------------------
Author:
Eric Kohl <ekohl@abo.rhein-zeitung.de>
Status:
Almost finished.
Unicode notifications are not supported (WM_NOTIFYFORMAT).
Order array not supported.
3.7 Hot Key Control
-------------------
Author:
Dummy written by Eric Kohl. <ekohl@abo.rhein-zeitung.de>
Status:
Dummy control. No functionality.
Notes:
Author needed!! Any volunteers??
3.8 Image List (no control)
---------------------------
Author:
Eric Kohl <ekohl@abo.rhein-zeitung.de>
Status:
Almost finished.
3.9 IP Address Control
----------------------
Author:
Dummy written by Eric Kohl. <ekohl@abo.rhein-zeitung.de>
Alex Priem <alexp@sci.kun.nl>
Status:
Under construction.
3.10 List View Control
----------------------
Author:
Dummy written by Eric Kohl. <ekohl@abo.rhein-zeitung.de>
Luc Tourangeau <luc@macadamian.com>
Koen Deforche <jozef@kotnet.org>
Francis Beaudet <francis@macadamian.com> and the "Corel-Team"
Status:
Under construction.
Notes:
Basic data structure with related messages are supported.
No painting supported yet.
3.11 Month Calendar Control
---------------------------
Author:
Dummy written by Eric Kohl. <ekohl@abo.rhein-zeitung.de>
Status:
Dummy control. No functionality.
Notes:
Author needed!! Any volunteers??
3.12 Native font control
------------------------
Author:
Dummy written by Eric Kohl. <ekohl@abo.rhein-zeitung.de>
Status:
Dummy control. No functionality.
Notes:
Author needed!! Any volunteers??
3.13 Pager Control
------------------
Author:
Dummy written by Eric Kohl. <ekohl@abo.rhein-zeitung.de>
Status:
Under construction.
Many missing features.
Notes:
Author needed!! Any volunteers??
3.14 Progress Bar Control
-------------------------
Author:
Original implementation by Dimitrie O. Paun.
Fixes and improvements by Eric Kohl.
Status:
Finished!
3.15 Property Sheet
-------------------
Author:
Anders Carlsson <anders.carlsson@linux.nu>
Francis Beaudet <francis@macadamian.com>
Status:
Development in progress.
Notes:
Tab control must be implemented first.
3.16 Rebar Control (Cool Bar)
-----------------------------
Author:
Eric Kohl <ekohl@abo.rhein-zeitung.de>
Status:
Development in progress.
Many bugs and missing features.
Notes:
Author needed!! Any volunteers??
3.17 Status Bar Control
-----------------------
Author:
Original implementation by Bruce Milner.
Fixes and improvements by Eric Kohl.
Status:
Almost finished.
Notes:
Tooltip integration is almost complete.
3.18 Tab Control
----------------
Author:
Anders Carlsson <anders.carlsson@linux.nu>
Status:
Development in progress.
3.19 Toolbar Control
--------------------
Author:
Eric Kohl <ekohl@abo.rhein-zeitung.de>
Status:
Development in progress.
Basic functionality is almost done. (dll version 4.0)
3.20 Tooltip Control
--------------------
Author:
Eric Kohl <ekohl@abo.rhein-zeitung.de>
Status:
Almost finished.
Notes:
Unicode support is incomplete (WM_NOTIFYFORMAT).
3.21 Trackbar Control
---------------------
Author:
Dummy written by Eric Kohl <ekohl@abo.rhein-zeitung.de>
Alex Priem <alexp@sci.kun.nl>
Status:
Under construction.
3.22 Tree View Control
----------------------
Author:
Dummy written by Eric Kohl.
Alex Priem <alexp@sci.kun.nl>
Status:
Under construction.
3.23 Updown Control
-------------------
Author:
Original implementation by Dimitrie O. Paun.
Some minor changes by Eric Kohl <ekohl@abo.rhein-zeitung.de>.
Status:
Unknown.
Notes:
Have a look at controls/updown.c for a list of bugs and missing
features.
The status is unknown, because I did not have a close look at this
control. One test-program looked quite good, but in Win95's
cdplayer.exe the control does not show at all.
Any volunteers??
4. Additional Information
-------------------------
Has to be written...
5. Undocumented features
------------------------
There are quite a lot of undocumented functions like:
- DSA (Dynamic Storage Array) functions.
- DPA (Dynamic Pointer Array) functions.
- MRU ("Most Recently Used" List) functions.
- other unknown functions.
Have a look at relay32/comctl32.spec.
5.1 Dymnamic Storage Array (DSA)
---------------------------------
The DSA functions are used to store and manage dynamic arrays of fixed size
memory blocks. They are used by TASKMAN.EXE, Explorer, IE4 and other
Programs and DLL's that are "parts of the Windows Operating System".
The implementation should be complete.
Have a look at the source code to get more information.
5.2 Dynamic Pointer Array (DPA)
------------------------------------
Similar to the DSA functions, but they just store pointers. They are used by
Explorer, IE4 and other Programs and DLL's that are "parts of the Windows
Operating System". The implementation should be complete.
Have a look at the source code to get more information.
5.3 "Most Recently Used" - List (MRU)
-------------------------------------
Only stubs are implemented to keep Explorer from bailing out.
No more information available at this time!
5.4 MenuHelp
------------
Has to be written...
5.5 GetEffectiveClientRect
--------------------------
Has to be written...
5.6 ShowHideMenuCtl
-------------------
The official documentation provided by MS is incomplete.
lpInfo:
...
Both values of the first pair must be the handle to the applications main
menu.
...
5.7 Other undocumented functions
--------------------------------
Several other undocumented functions are used by IE4.
String functions:
(will be written...)
6. Epilogue
-----------
You see, much work has still to be done. If you are interested in writing
a control send me an e-mail. If you like to fix bugs or add some
functionality send an e-mail to the author of the control.
Eric Kohl <ekohl@abo.rhein-zeitung.de>
<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:
-->
Copyright 1999 Adam Sacarny (magicbox@bestweb.net)
1. WHAT IS THE WINE CONFIG FILE?
The Wine config file stores various settings for Wine. These include:
Drives and Information about them
Directory Settings
Port Settings
The Wine look and feel
Wine's DLL Usage
2. HOW DO I MAKE ONE?
This section will guide you through the process of making a config file. Take a
look at the file <dirs to wine>/wine.ini
It is organized by section.
Name | Needed? | What it does
----------------------------------------------------------------
[Drive X] | yes | Sets up drives recognized by wine
[wine] | yes | Settings for wine directories
[DllDefaults] | recmd | Defaults for loading DLL's
[DllPairs] | recmd | Sanity checkers for DLL's
[DllOverrides] | recmd | Overides defaults for DLL loading
[options] | no | No one seems to know
[fonts] | yes | Font appearance and recognition
[serialports] | no | COM ports seen by wine
[parallelports] | no | LPT ports seen by wine
[spooler] | no | Print spooling
[ports] | no | Direct port access
[spy] | no | What to do with certain debug messages
[Registry] | no | Specifies locations of windows registry files
[tweak.layout] | recmd | Appearance of wine
[programs] | no | Programs to be run automatically
[Console] | no | Console settings
Recmd-Recommended
2.1 THE [Drive X] SECTION
It should be pretty self explanatory, but here is an in-depth tutorial about
them.
There are up to 6 lines for each drive in Wine.
[Drive X]
The above line begins the section for a drive whose letter is X.
Path=/dir/to/path
This path is where the drive will begin. When Wine is browsing in drive X, it
will see the files that are in the directory "/dir/to/path". Don't forget to
leave off the trailing slash!
Type=floppy|hd|cdrom|network <--- the |'s mean Type=<one of the options>
Sets up the type of drive Wine will see it as. Type must equal one of the four
"floppy", "hd", "cdrom", or "network". They are self-explanatory.
Label=blah
Defines the drive label. Generally only needed for programs that look for a
special CD-ROM. Info on finding the lable is in <dirs to
wine>/documentation/cdrom-labels. The label may be up to 11 characters.
Serial=deadbeef
Tells Wine the serial number of the drive. A few programs with intense
protection for pirating might need this, but otherwise don't use it. Up to 8
characters and hexadecimal.
Filesystem=msdos|win95|unix
Sets up the way Wine looks at files on the drive.
msdos -> Case insensitive filesystem. Alike to DOS and Windows 3.x.
8.3 is the maximum length of files (eightdot.123) - longer ones will be
truncated. (NOTE: this is a very bad choice if you plan on running apps
that use long filenames. win95 should work fine with apps that were
designed to run under the msdos system. In other words, you might not
want to use this.)
win95 -> Case insensitive. Alike to Windows 9x/NT 4. This is the long
filename filesystem you are probably used to working with. The
filesystem of choice for most applications to be run under wine.
PROBABLY THE ONE YOU WANT
unix -> Case sensitive. This filesystem has almost no use (Windows apps
expect case insensitive filenames). Try it if you dare, but win95 is a
much better choice.
Device=/dev/xx
Use this ONLY for floppy and cdrom devices. Using it on Extended2 partitions can
have dire results (When a windows app tries to do a lowlevel write, they do it
in a FAT way -- FAT does not mix with Extended2).
NOTE: This setting is not really important, almost all apps will have no
problem if it remains unspecified. For CD-ROMs you might want to add it to get
automatic label detection, though. If you are unsure about specifying device
names, just leave out this setting for your drives.
Here is a setup for Drive X, a generic hard drive:
[Drive X]
Path=/dos-a
Type=hd
Label=Hard Drive
Filesystem=win95
This is a setup for Drive X, a generic CD-ROM drive:
[Drive X]
Path=/dos-d
Type=cdrom
Label=Total Annihilation
Filesystem=win95
Device=/dev/hdc
And here is a setup for Drive X, a generic floppy drive:
[Drive X]
Type=floppy
Path=/mnt/floppy
Label=Floppy Drive
Serial=87654321
Filesystem=win95
Device=/dev/fd0
2.2 THE [wine] SECTION
The [wine] section of the configuration file contains information wine uses for
directories. When specifying the directories for the settings, make them as they
would appear in wine. If your drive C has a Path of /dos, and your windows
directory is located in /dos/windows, Windows=c:\windows.
Windows=c:\windows
Sets up the windows directory. Make one if you don't have windows. NO TRAILING
SLASH (NOT C:\windows\)!
System=c:\windows\system
Sets up where the windows system files are. Should reside in the directory used
for the "Windows" setting. If you don't have windows then this is where the
system files will go. NO TRAILING SLASH!
Temp=c:\temp
This should be the directory you want your temp files stored in. YOU MUST HAVE
WRITE ACCESS TO IT.
Path=c:\windows;c:\windows\system;c:\blanco
Behaves like the PATH setting on unix boxes. When wine is run like "wine
sol.exe", if sol.exe resides in a directory specified in the "Path" setting,
wine will run it (Of course, if sol.exe resides in the current directory, wine
will run that one). Make sure it always has your windows directory and system
directory (For this setup, it must have c:\windows;c:\windows\system).
SymbolTableFile=wine.sym
Sets up the symbol table file for the wine debugger. You probably don't need to
fiddle with this. May be useful if your wine is stripped.
printer=off|on
Tells wine whether to allow printer drivers and printing to work. Using these
things are pretty alpha, so you might want to watch out. Some people might find
it useful, however. If you're not planning on working on printing, don't even
add this to your wine.ini (It probably isn't already in it). Check out the
[spooler] and [parallelports] sections too.
2.3 INTRODUCTION TO DLL SECTIONS
There are a few things you will need to know before configuring the DLL sections
in your wine configuration file.
2.3.1 WINDOWS DLL PAIRS
Most windows DLL's have a win16 (Windows 3.x) and win32 (Windows 9x/NT)
form. The combination of the win16 and win32 DLL versions are called
the "DLL pair". This is a list of the most common pairs:
Win16 | Win32 | Native*
-----------------------------
KERNEL | KERNEL32 | No!
USER | USER32 | No!
SHELL | SHELL32 | Yes
GDI | GDI32 | No!
COMMDLG | COMDLG32 | Yes
VER | VERSION | Yes
*-Is it possible to use native dll with wine?(See next section)
2.3.2 DIFFERENT FORMS OF DLL'S
There are a few different forms of DLL's wine can load:
native -> The DLL's that are included with windows. Many windows
DLL's can be loaded in their native form. Many times these
native versions work better than their non-Microsoft equivalent
-- other times they don't.
elfdll -> ELF encapsulated windows DLL's. This is currently
experimental (Not working yet).
so -> Native ELF libraries. Will not work yet.
builtin -> The most common form of DLL loading. This is what you
will use if the DLL is error-prone in native form (KERNEL for
example), you don't have the native DLL, or you just want to be
Microsoft-free.
2.4 THE [DllDefaults] SECTION
These settings provide wine's default handling of DLL loading.
EXTRA_LD_LIBRARY_PATH=/dirs
The directory specified here is appended to the normal search path for certain
forms of DLL's (elfdll and .so).
DefaultLoadOrder = native, elfdll, so, builtin
This setting is a comma-delimited list of which order to attempt loading DLL's.
If the first option fails, it will try the second, and so on. The order
specified above is probably the best in most conditions.
2.5 THE [DllPairs] SECTION
This section is optional, but strongly recommended. If you try to use native
SHELL32, but builtin SHELL, you could have some big problems (native and
builtin/so/elfdll do certain things in different ways). Using different forms of
a pair is a *very*, **very** bad idea. By specifying DLL pairs here, wine will
print out a message if you use different forms of a pair.
You shouldn't need to change anything in this section, the following should work
fine in all cases:
[DllPairs]
kernel = kernel32
gdi = gdi32
user = user32
commdlg = comdlg32
commctrl= comctl32
ver = version
shell = shell32
lzexpand= lz32
winsock = wsock32
2.6 THE [DllOverrides] SECTION
The format for this section is the same for each line:
<DLL>{,<DLL>,<DLL>...} = <FORM>{,<FORM>,<FORM>...}
For example, to load builtin KERNEL pair (Case doesn't matter here):
kernel,kernel32 = builtin
To load the native COMMDLG pair, but if that doesn't work try builtin:
commdlg,comdlg32 = native,builtin
To load the native COMCTL32:
comctl32 = native
Here is a good generic setup (As it is defined in wine.ini that was included
with your wine package):
[DllOverrides]
kernel32, gdi32, user32 = builtin
kernel, gdi, user = builtin
toolhelp = builtin
comdlg32, commdlg = elfdll, builtin, native
version, ver = elfdll, builtin, native
shell32, shell = builtin, native
lz32, lzexpand = builtin, native
commctrl, comctl32 = builtin, native
wsock32, winsock = builtin
advapi32, crtdll, ntdll = builtin, native
mpr, winspool = builtin, native
ddraw, dinput, dsound = builtin, native
winmm, w32skrnl, msvfw32= builtin
wnaspi32, wow32 = builtin
system, display, wprocs = builtin
wineps = builtin
NOTE: You see that elfdll or so is the first option for a few of these dll's.
This will fail for you, but you won't notice it as wine will just use the second
or third option.
2.7 THE [options] SECTION
No one seems to know what this section is...
AllocSystemColors=100
System colors to allocate? Just leave it at 100.
2.8 THE [fonts] SECTION
This section sets up wine's font handling.
Resolution = 96
Since the way X handles fonts is different from the way Windows does, wine uses
a special mechanism to deal with them. It must scale them using the number
defined in the "Resolution" setting. 60-120 are reasonable values, 96 is a nice
in the middle one. If you have the real windows fonts available (<dirs to
wine>/documentation/ttfserver and fonts), this parameter will not be as
important. Of course, it's always good to get your X fonts working acceptably in
wine.
Default = -adobe-times-
The default font wine uses. Fool around with it if you'd like.
OPTIONAL:
The "Alias" setting allows you to map an X font to a font used in wine. This is
good for apps that need a special font you don't have, but a good replacement
exists. The syntax is like so:
AliasX = [Fake windows name],[Real X name]<,optional "masking" section>
Pretty straightforward. Replace "AliasX" with "Alias0", then "Alias1" and so on.
The fake windows name is the name that the font will be under a windows app in
wine. The real X name is the font name as seen by X (Run "xfontsel").
The optional "masking" section allows you to utilize the fake windows name you
define. If it is not used, then wine will just try to extract the fake windows
name itself and not use the value you enter.
Here is an example of an alias without masking. The font will show up in windows
apps as "Google". When defining an alias in a config file, forget about my
comment text (The "<-- blah" stuff)
Alias0 = Foo,--google- <-- Note the no spaces after the " = ". Important!
Here is an example with masking enabled. The font will show up as "Foo" in
windows apps.
Alias1 = Foo,--google-,subst
For more info check out <dirs to wine>/documentation/fonts
2.9 THE [serialports], [parallelports], [spooler], AND [ports] SECTIONS
Even though it sounds like a lot of sections, these are all closely related.
They all are for communications and parallel ports.
The [serialports] section tells wine what serial ports it is allowed to use.
ComX=/dev/cuaY
Replace X with the number of the COM port in Windows (1-8) and Y with the
number of it in X (Usually the number of the port in Windows minus 1). ComX can
actually equal any device (/dev/modem is acceptable). It is not always necessary
to define any COM ports (An optional setting). Here is an example:
Com1=/dev/cua0
Use as many of these as you like in the section to define all of the COM ports
you need.
The [parallelports] section sets up any parallel ports that will be allowed
access under wine.
LptX=/dev/lpY
Seem farmiliar? Syntax is just like the COM port setting. Replace X with a value
from 1-4 as it is in Windows and Y with a value from 0-3 (Y is usually the value
in windows minus 1, just like for COM ports). You don't always need to define a
parallel port (AKA, it's optional). As with the other section, LptX can equal
any device (Maybe /dev/printer). Here is an example:
Lpt1=/dev/lp0
The [spooler] section will inform wine where to spool print jobs. Use this if
you want to try printing. Wine docs claim that spooling is "rather primitive" at
this time, so it won't work perfectly. IT IS OPTIONAL
The only setting you use in this section works to map a port (LPT1, for example)
to a file or a command. Here is an example, mapping LPT1 to the file "out.ps":
LPT1:=out.ps
The following command maps printing jobs to LPT1 to the command "lpr". Notice
the |:
LPT1:=|lpr
The [ports] section is usually useful only for people who need direct port
access for programs requiring dongles or scanners. IF YOU DON'T NEED IT, DON'T
USE IT!
read=0x779,0x379,0x280-0x2a0
Gives direct read access to those IO's.
write=0x779,0x379,0x280-0x2a0
Gives direct write access to those IO's. It probably a good idea to keep the
values of the "read" and "write" settings the same. This stuff will only work
when you're root.
2.10 THE [spy], [Registry], [tweak.layout], and [programs] SECTIONS
[spy] is used to Include or exclude debug messages, and to output them to a
file. The latter is rarely used. THESE ARE ALL OPTIONAL AND YOU PROBABLY DON'T
NEED TO ADD OR REMOVE ANYTHING IN THIS SECTION TO YOUR CONFIG.
File=/blanco
Sets the logfile for wine. Set to CON to log to standard out. THIS IS RARELY
USED
Exclude=WM_SIZE;WM_TIMER;
Excludes debug messages about WM_SIZE and WM_TIMER in the logfile.
Include=WM_SIZE;WM_TIMER;
Includes debug messages about WM_SIZE and WM_TIMER in the logfile.
[Registry] can be used to tell wine where your old windows registry files exist. This
section is completely optional and useless to people using wine without an existing
windows installation.
UserFileName=/dirs/to/user.reg
The location of your old user.reg file.
LocalMachineFileName=/dirs/to/system.reg
The location of your old system.reg file.
[tweak.layout] is devoted to wine's look. There is only one setting for it.
WineLook=win31|win95|win98
Will change the look of wine from Windows 3.1 to Windows 95. "win98" behaves
just like "win95" most of the time.
[programs] can be used to say what programs run under special conditions.
Default=/program/to/execute.exe
Sets the program to be run if wine is started without specifying a program.
Startup=/program/to/execute.exe
Sets the program to automatically be run at startup every time.
3. WHERE DO I PUT IT?
The wine config file can go in two places.
/usr/local/etc/wine.conf <--- A systemwide config file, used for anyone
who doesn't have their own.
$HOME/.winerc <--- Your own config file, that only is used for your
user.
So copy the file you made to be the wine.conf to /usr/local/etc/wine.conf or
$HOME/.winerc for wine to recognize it.
4. WHAT IF IT DOESN'T WORK?
There is always a chance that things will go wrong. If the unthinkable happens,
try the newsgroup, comp.emulators.ms-windows.wine
Make sure that you have looked over this document thoroughly, and have also
read:
README
documentation/bugreports
http://www.westfalen.de/witch/wine-HOWTO.txt (Optional but recommended)
If indeed it looks like you've done your research, be prepared for helpful
suggestions. If you haven't, brace yourself for heaving flaming.
This diff is collapsed.
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.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
0% Loading or .
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment