Skip to content

W
wine-winehq
Commit 12f9bb7a authored by Dimi Paun's avatar Dimi Paun Committed by Alexandre Julliard
Browse files
Options

Moved the SGML documentation over to SourceForge.

parent 15ac6847
Expand all Hide whitespace changes
Inline Side-by-side
Showing with 8 additions and 1907 deletions
README
View file @ 12f9bb7a
...@@ -19,10 +19,8 @@ of the Wine source (which contains this file), run: ...@@ -19,10 +19,8 @@ of the Wine source (which contains this file), run:
./tools/wineinstall ./tools/wineinstall
Run programs as "wine [options] program". For more information and Run programs as "wine [options] program". For more information and
problem resolution, read the rest of this file, the Wine man page, problem resolution, read the rest of this file, the Wine man page, and
the files in the documentation directory of the Wine source especially the wealth of information found at http://www.winehq.org.
(see "DOCUMENTATION"), and especially the wealth of information
found at http://www.winehq.org.
3. REQUIREMENTS 3. REQUIREMENTS
...@@ -90,9 +88,6 @@ Optional support libraries: ...@@ -90,9 +88,6 @@ Optional support libraries:
If you want CUPS printing support, please install both cups and cups-devel If you want CUPS printing support, please install both cups and cups-devel
packages. packages.
For requirements in case you intend to build the documentation yourself,
see "DOCUMENTATION" section.
4. COMPILATION 4. COMPILATION
In case you chose to not use wineinstall, run the following commands In case you chose to not use wineinstall, run the following commands
...@@ -129,17 +124,8 @@ Don't forget to uninstall any conflicting previous Wine installation ...@@ -129,17 +124,8 @@ Don't forget to uninstall any conflicting previous Wine installation
first. Try either "dpkg -r wine" or "rpm -e wine" or "make uninstall" first. Try either "dpkg -r wine" or "rpm -e wine" or "make uninstall"
before installing. before installing.
If you want to read the documentation supplied with the Wine source, See the Support area at http://www.winehq.org/ for configuration
see the "DOCUMENTATION" section. hints.
Wine requires a configuration file named named "config" in your
~/.wine directory. The format of this file is explained in the config file
man page (documentation/wine.conf.man).
The file documentation/samples/config contains an example configuration file
which has to be adapted and copied to the location mentioned above.
See the Support area at http://www.winehq.org/ for further
configuration hints.
In case of library loading errors In case of library loading errors
(e.g. "Error while loading shared libraries: libntdll.so"), make sure (e.g. "Error while loading shared libraries: libntdll.so"), make sure
...@@ -180,19 +166,7 @@ as they launch Explorer somehow. This particular corruption (!$!$!$!$.pfr) ...@@ -180,19 +166,7 @@ as they launch Explorer somehow. This particular corruption (!$!$!$!$.pfr)
can at least partially be fixed by using can at least partially be fixed by using
http://home.nexgo.de/andi.mohr/download/decorrupt_explorer http://home.nexgo.de/andi.mohr/download/decorrupt_explorer
7. DOCUMENTATION 7. GETTING MORE INFORMATION
Some documentation (various Wine Guides etc.) can be found in the
documentation/ directory (apart from also being available on WineHQ).
If you want to process the SGML files in there, then you can run "make doc"
in the documentation/ directory.
Doing so requires the sgml tools package (for db2html, db2ps, db2pdf) named:
Debian: docbook-utils
Mandrake: sgml-tools-A.B.C-DDmdk
SuSE: docbktls-A.BB.C-DD
8. GETTING MORE INFORMATION
WWW: A great deal of information about Wine is available from WineHQ at WWW: A great deal of information about Wine is available from WineHQ at
http://www.winehq.org/ : various Wine Guides, application database, http://www.winehq.org/ : various Wine Guides, application database,
......
configure
View file @ 12f9bb7a
...@@ -311,7 +311,7 @@ ac_includes_default="\ ...@@ -311,7 +311,7 @@ ac_includes_default="\
# include <unistd.h> # include <unistd.h>
#endif" #endif"
ac_subst_vars='SHELL PATH_SEPARATOR PACKAGE_NAME PACKAGE_TARNAME PACKAGE_VERSION PACKAGE_STRING PACKAGE_BUGREPORT exec_prefix prefix program_transform_name bindir sbindir libexecdir datadir sysconfdir sharedstatedir localstatedir libdir includedir oldincludedir infodir mandir build_alias host_alias target_alias DEFS ECHO_C ECHO_N ECHO_T LIBS WIN16_FILES WIN16_INSTALL DLLDEFS build build_cpu build_vendor build_os host host_cpu host_vendor host_os SET_MAKE CC CFLAGS LDFLAGS CPPFLAGS ac_ct_CC EXEEXT OBJEXT CXX CXXFLAGS ac_ct_CXX CPPBIN ac_ct_CPPBIN TOOLSDIR CPP X_CFLAGS X_PRE_LIBS X_LIBS X_EXTRA_LIBS LEX LEXLIB LEX_OUTPUT_ROOT XLEX BISON AS ac_ct_AS LD ac_ct_LD AR ac_ct_AR RANLIB ac_ct_RANLIB STRIP ac_ct_STRIP WINDRES ac_ct_WINDRES LN_S LN EGREP LDCONFIG INSTALL_PROGRAM INSTALL_SCRIPT INSTALL_DATA LINT LINTFLAGS DB2HTML DB2PDF DB2PS DB2TXT FONTFORGE LIBPTHREAD XLIB XFILES OPENGLFILES GLU32FILES OPENGL_LIBS GLUT_LIBS GLUT32FILES NASLIBS CURSESLIBS sane_devel SANELIBS SANEINCL ICULIBS ft_devel ft_devel2 FREETYPELIBS FREETYPEINCL FONTSSUBDIRS ARTSCCONFIG ARTSLIBS ARTSINCL ALSALIBS AUDIOIOLIBS EXTRACFLAGS DLLEXT DLLFLAGS DLLIBS LDSHARED LDDLLFLAGS LIBEXT IMPLIBEXT DLLTOOL ac_ct_DLLTOOL DLLWRAP ac_ct_DLLWRAP LDEXECFLAGS LDLIBWINEFLAGS COREFOUNDATIONLIB IOKITLIB CROSSTEST CROSSCC CROSSWINDRES LDPATH CRTLIBS SOCKETLIBS WINE_BINARIES MAIN_BINARY LDD ALLOCA LIBOBJS LTLIBOBJS' ac_subst_vars='SHELL PATH_SEPARATOR PACKAGE_NAME PACKAGE_TARNAME PACKAGE_VERSION PACKAGE_STRING PACKAGE_BUGREPORT exec_prefix prefix program_transform_name bindir sbindir libexecdir datadir sysconfdir sharedstatedir localstatedir libdir includedir oldincludedir infodir mandir build_alias host_alias target_alias DEFS ECHO_C ECHO_N ECHO_T LIBS WIN16_FILES WIN16_INSTALL DLLDEFS build build_cpu build_vendor build_os host host_cpu host_vendor host_os SET_MAKE CC CFLAGS LDFLAGS CPPFLAGS ac_ct_CC EXEEXT OBJEXT CXX CXXFLAGS ac_ct_CXX CPPBIN ac_ct_CPPBIN TOOLSDIR CPP X_CFLAGS X_PRE_LIBS X_LIBS X_EXTRA_LIBS LEX LEXLIB LEX_OUTPUT_ROOT XLEX BISON AS ac_ct_AS LD ac_ct_LD AR ac_ct_AR RANLIB ac_ct_RANLIB STRIP ac_ct_STRIP WINDRES ac_ct_WINDRES LN_S LN EGREP LDCONFIG INSTALL_PROGRAM INSTALL_SCRIPT INSTALL_DATA LINT LINTFLAGS FONTFORGE LIBPTHREAD XLIB XFILES OPENGLFILES GLU32FILES OPENGL_LIBS GLUT_LIBS GLUT32FILES NASLIBS CURSESLIBS sane_devel SANELIBS SANEINCL ICULIBS ft_devel ft_devel2 FREETYPELIBS FREETYPEINCL FONTSSUBDIRS ARTSCCONFIG ARTSLIBS ARTSINCL ALSALIBS AUDIOIOLIBS EXTRACFLAGS DLLEXT DLLFLAGS DLLIBS LDSHARED LDDLLFLAGS LIBEXT IMPLIBEXT DLLTOOL ac_ct_DLLTOOL DLLWRAP ac_ct_DLLWRAP LDEXECFLAGS LDLIBWINEFLAGS COREFOUNDATIONLIB IOKITLIB CROSSTEST CROSSCC CROSSWINDRES LDPATH CRTLIBS SOCKETLIBS WINE_BINARIES MAIN_BINARY LDD ALLOCA LIBOBJS LTLIBOBJS'
ac_subst_files='MAKE_RULES MAKE_DLL_RULES MAKE_TEST_RULES MAKE_LIB_RULES MAKE_PROG_RULES' ac_subst_files='MAKE_RULES MAKE_DLL_RULES MAKE_TEST_RULES MAKE_LIB_RULES MAKE_PROG_RULES'
# Initialize some variables set by options. # Initialize some variables set by options.
...@@ -5590,170 +5590,6 @@ then ...@@ -5590,170 +5590,6 @@ then
for ac_prog in docbook2html db2html
do
# Extract the first word of "$ac_prog", so it can be a program name with args.
set dummy $ac_prog; ac_word=$2
echo "$as_me:$LINENO: checking for $ac_word" >&5
echo $ECHO_N "checking for $ac_word... $ECHO_C" >&6
if test "${ac_cv_prog_DB2HTML+set}" = set; then
echo $ECHO_N "(cached) $ECHO_C" >&6
else
if test -n "$DB2HTML"; then
ac_cv_prog_DB2HTML="$DB2HTML" # Let the user override the test.
else
as_save_IFS=$IFS; IFS=$PATH_SEPARATOR
for as_dir in $PATH
do
IFS=$as_save_IFS
test -z "$as_dir" && as_dir=.
for ac_exec_ext in '' $ac_executable_extensions; do
if $as_executable_p "$as_dir/$ac_word$ac_exec_ext"; then
ac_cv_prog_DB2HTML="$ac_prog"
echo "$as_me:$LINENO: found $as_dir/$ac_word$ac_exec_ext" >&5
break 2
fi
done
done
fi
fi
DB2HTML=$ac_cv_prog_DB2HTML
if test -n "$DB2HTML"; then
echo "$as_me:$LINENO: result: $DB2HTML" >&5
echo "${ECHO_T}$DB2HTML" >&6
else
echo "$as_me:$LINENO: result: no" >&5
echo "${ECHO_T}no" >&6
fi
test -n "$DB2HTML" && break
done
test -n "$DB2HTML" || DB2HTML="false"
for ac_prog in docbook2pdf db2pdf
do
# Extract the first word of "$ac_prog", so it can be a program name with args.
set dummy $ac_prog; ac_word=$2
echo "$as_me:$LINENO: checking for $ac_word" >&5
echo $ECHO_N "checking for $ac_word... $ECHO_C" >&6
if test "${ac_cv_prog_DB2PDF+set}" = set; then
echo $ECHO_N "(cached) $ECHO_C" >&6
else
if test -n "$DB2PDF"; then
ac_cv_prog_DB2PDF="$DB2PDF" # Let the user override the test.
else
as_save_IFS=$IFS; IFS=$PATH_SEPARATOR
for as_dir in $PATH
do
IFS=$as_save_IFS
test -z "$as_dir" && as_dir=.
for ac_exec_ext in '' $ac_executable_extensions; do
if $as_executable_p "$as_dir/$ac_word$ac_exec_ext"; then
ac_cv_prog_DB2PDF="$ac_prog"
echo "$as_me:$LINENO: found $as_dir/$ac_word$ac_exec_ext" >&5
break 2
fi
done
done
fi
fi
DB2PDF=$ac_cv_prog_DB2PDF
if test -n "$DB2PDF"; then
echo "$as_me:$LINENO: result: $DB2PDF" >&5
echo "${ECHO_T}$DB2PDF" >&6
else
echo "$as_me:$LINENO: result: no" >&5
echo "${ECHO_T}no" >&6
fi
test -n "$DB2PDF" && break
done
test -n "$DB2PDF" || DB2PDF="false"
for ac_prog in docbook2ps db2ps
do
# Extract the first word of "$ac_prog", so it can be a program name with args.
set dummy $ac_prog; ac_word=$2
echo "$as_me:$LINENO: checking for $ac_word" >&5
echo $ECHO_N "checking for $ac_word... $ECHO_C" >&6
if test "${ac_cv_prog_DB2PS+set}" = set; then
echo $ECHO_N "(cached) $ECHO_C" >&6
else
if test -n "$DB2PS"; then
ac_cv_prog_DB2PS="$DB2PS" # Let the user override the test.
else
as_save_IFS=$IFS; IFS=$PATH_SEPARATOR
for as_dir in $PATH
do
IFS=$as_save_IFS
test -z "$as_dir" && as_dir=.
for ac_exec_ext in '' $ac_executable_extensions; do
if $as_executable_p "$as_dir/$ac_word$ac_exec_ext"; then
ac_cv_prog_DB2PS="$ac_prog"
echo "$as_me:$LINENO: found $as_dir/$ac_word$ac_exec_ext" >&5
break 2
fi
done
done
fi
fi
DB2PS=$ac_cv_prog_DB2PS
if test -n "$DB2PS"; then
echo "$as_me:$LINENO: result: $DB2PS" >&5
echo "${ECHO_T}$DB2PS" >&6
else
echo "$as_me:$LINENO: result: no" >&5
echo "${ECHO_T}no" >&6
fi
test -n "$DB2PS" && break
done
test -n "$DB2PS" || DB2PS="false"
for ac_prog in docbook2txt db2txt
do
# Extract the first word of "$ac_prog", so it can be a program name with args.
set dummy $ac_prog; ac_word=$2
echo "$as_me:$LINENO: checking for $ac_word" >&5
echo $ECHO_N "checking for $ac_word... $ECHO_C" >&6
if test "${ac_cv_prog_DB2TXT+set}" = set; then
echo $ECHO_N "(cached) $ECHO_C" >&6
else
if test -n "$DB2TXT"; then
ac_cv_prog_DB2TXT="$DB2TXT" # Let the user override the test.
else
as_save_IFS=$IFS; IFS=$PATH_SEPARATOR
for as_dir in $PATH
do
IFS=$as_save_IFS
test -z "$as_dir" && as_dir=.
for ac_exec_ext in '' $ac_executable_extensions; do
if $as_executable_p "$as_dir/$ac_word$ac_exec_ext"; then
ac_cv_prog_DB2TXT="$ac_prog"
echo "$as_me:$LINENO: found $as_dir/$ac_word$ac_exec_ext" >&5
break 2
fi
done
done
fi
fi
DB2TXT=$ac_cv_prog_DB2TXT
if test -n "$DB2TXT"; then
echo "$as_me:$LINENO: result: $DB2TXT" >&5
echo "${ECHO_T}$DB2TXT" >&6
else
echo "$as_me:$LINENO: result: no" >&5
echo "${ECHO_T}no" >&6
fi
test -n "$DB2TXT" && break
done
test -n "$DB2TXT" || DB2TXT="false"
for ac_prog in fontforge for ac_prog in fontforge
do do
# Extract the first word of "$ac_prog", so it can be a program name with args. # Extract the first word of "$ac_prog", so it can be a program name with args.
...@@ -21068,10 +20904,6 @@ s,@INSTALL_SCRIPT@,$INSTALL_SCRIPT,;t t ...@@ -21068,10 +20904,6 @@ s,@INSTALL_SCRIPT@,$INSTALL_SCRIPT,;t t
s,@INSTALL_DATA@,$INSTALL_DATA,;t t s,@INSTALL_DATA@,$INSTALL_DATA,;t t
s,@LINT@,$LINT,;t t s,@LINT@,$LINT,;t t
s,@LINTFLAGS@,$LINTFLAGS,;t t s,@LINTFLAGS@,$LINTFLAGS,;t t
s,@DB2HTML@,$DB2HTML,;t t
s,@DB2PDF@,$DB2PDF,;t t
s,@DB2PS@,$DB2PS,;t t
s,@DB2TXT@,$DB2TXT,;t t
s,@FONTFORGE@,$FONTFORGE,;t t s,@FONTFORGE@,$FONTFORGE,;t t
s,@LIBPTHREAD@,$LIBPTHREAD,;t t s,@LIBPTHREAD@,$LIBPTHREAD,;t t
s,@XLIB@,$XLIB,;t t s,@XLIB@,$XLIB,;t t
......
configure.ac
View file @ 12f9bb7a
...@@ -123,10 +123,6 @@ AC_SUBST(LINT) ...@@ -123,10 +123,6 @@ AC_SUBST(LINT)
AC_SUBST(LINTFLAGS) AC_SUBST(LINTFLAGS)
dnl Check for various programs dnl Check for various programs
AC_CHECK_PROGS(DB2HTML, docbook2html db2html, false)
AC_CHECK_PROGS(DB2PDF, docbook2pdf db2pdf, false)
AC_CHECK_PROGS(DB2PS, docbook2ps db2ps, false)
AC_CHECK_PROGS(DB2TXT, docbook2txt db2txt, false)
AC_CHECK_PROGS(FONTFORGE, fontforge, false) AC_CHECK_PROGS(FONTFORGE, fontforge, false)
dnl **** Check for some libraries **** dnl **** Check for some libraries ****
......
documentation/.cvsignore
View file @ 12f9bb7a
*.aux
*.dvi
*.junk
*.log
*.out
*.tex
DBTOHTML_OUTPUT_DIR*
Makefile Makefile
wine-devel.html
wine-devel.pdf
wine-devel.ps
wine-devel.txt
wine-faq.html
wine-faq.txt
wine-user.html
wine-user.pdf
wine-user.ps
wine-user.txt
wine.man wine.man
winelib-user.html
winelib-user.pdf
winelib-user.ps
winelib-user.txt
documentation/Makefile.in
View file @ 12f9bb7a
...@@ -3,110 +3,18 @@ TOPOBJDIR = .. ...@@ -3,110 +3,18 @@ TOPOBJDIR = ..
SRCDIR = @srcdir@ SRCDIR = @srcdir@
VPATH = @srcdir@ VPATH = @srcdir@
MODULE = none MODULE = none
DB2HTML = @DB2HTML@
DB2PDF = @DB2PDF@
DB2PS = @DB2PS@
DB2TXT = @DB2TXT@
EXTRASUBDIRS = samples EXTRASUBDIRS = samples
WINE_USER_SRCS = \
bugs.sgml \
configuring.sgml \
fonts.sgml \
getting.sgml \
glossary.sgml \
introduction.sgml \
printing.sgml \
registry.sgml \
running.sgml
WINE_DEVEL_SRCS = \
address-space.sgml \
architecture.sgml \
ddraw.sgml \
debugger.sgml \
debugging.sgml \
documentation.sgml \
multimedia.sgml \
ole.sgml \
opengl.sgml \
patches.sgml \
testing.sgml \
winedev-coding.sgml \
winedev-graphical.sgml \
winedev-kernel.sgml \
winedev-otherdebug.sgml \
winedev-windowing.sgml
WINELIB_USER_SRCS = \
winelib-bindlls.sgml \
winelib-intro.sgml \
winelib-mfc.sgml \
winelib-porting.sgml \
winelib-toolkit.sgml
WINE_FAQ_SRCS = \
faq.sgml
MAN_TARGETS = wine.man MAN_TARGETS = wine.man
ALLBOOKS = \
wine-devel \
wine-user \
winelib-user
all: $(MAN_TARGETS) all: $(MAN_TARGETS)
@MAKE_RULES@ @MAKE_RULES@
everything: $(MAN_TARGETS) doc
doc: html pdf ps txt
html: $(ALLBOOKS:%=%.html) wine-faq.html
pdf: $(ALLBOOKS:%=%.pdf)
ps: $(ALLBOOKS:%=%.ps)
txt: $(ALLBOOKS:%=%.txt)
.PHONY: everything doc html pdf ps dist
.SUFFIXES: .sgml .html .pdf .ps .txt
.sgml.html:
$(DB2HTML) -u $<
.sgml.pdf:
$(DB2PDF) $<
.sgml.ps:
$(DB2PS) $<
.sgml.txt:
$(DB2TXT) $<
wine-devel.pdf wine-devel.ps wine-devel.html wine-devel.txt: $(WINE_DEVEL_SRCS)
wine-user.pdf wine-user.ps wine-user.html wine-user.txt: $(WINE_USER_SRCS)
wine-faq.pdf wine-faq.ps wine-faq.html wine-faq.txt: $(WINE_FAQ_SRCS)
winelib-user.pdf winelib-user.ps winelib-user.html winelib-user.txt: $(WINELIB_USER_SRCS)
wine.man: wine.man.in wine.man: wine.man.in
sed -e 's,@bindir\@,$(bindir),g' -e 's,@dlldir\@,$(dlldir),g' -e 's,@PACKAGE_STRING\@,@PACKAGE_STRING@,g' $(SRCDIR)/wine.man.in >$@ || ($(RM) $@ && false) sed -e 's,@bindir\@,$(bindir),g' -e 's,@dlldir\@,$(dlldir),g' -e 's,@PACKAGE_STRING\@,@PACKAGE_STRING@,g' $(SRCDIR)/wine.man.in >$@ || ($(RM) $@ && false)
# Rules for distribution tarballs of formatted docs
dist: wine-doc-ps.tar.gz wine-doc-pdf.tar.gz wine-doc-html.tar.gz wine-doc-txt.tar.gz wine-faq.txt
wine-doc-ps.tar.gz: $(ALLBOOKS:%=%.ps)
tar cf - $(ALLBOOKS:%=%.ps) | gzip -9 > $@ || ($(RM) $@ && false)
wine-doc-pdf.tar.gz: $(ALLBOOKS:%=%.pdf)
tar cf - $(ALLBOOKS:%=%.pdf) | gzip -9 > $@ || ($(RM) $@ && false)
wine-doc-html.tar.gz: $(ALLBOOKS:%=%.html)
tar cf - $(ALLBOOKS:%=%.html) | gzip -9 > $@ || ($(RM) $@ && false)
wine-doc-txt.tar.gz: $(ALLBOOKS:%=%.txt)
tar cf - $(ALLBOOKS:%=%.txt) | gzip -9 > $@ || ($(RM) $@ && false)
install:: $(MAN_TARGETS) install:: $(MAN_TARGETS)
$(MKINSTALLDIRS) $(mandir)/man$(prog_manext) $(mandir)/man$(conf_manext) $(mandir)/man$(api_manext) $(MKINSTALLDIRS) $(mandir)/man$(prog_manext) $(mandir)/man$(conf_manext) $(mandir)/man$(api_manext)
$(INSTALL_DATA) wine.man $(mandir)/man$(prog_manext)/wine.$(prog_manext) $(INSTALL_DATA) wine.man $(mandir)/man$(prog_manext)/wine.$(prog_manext)
...@@ -120,8 +28,7 @@ install-api-man:: ...@@ -120,8 +28,7 @@ install-api-man::
for i in $(SRCDIR)/man$(api_manext)/*; do $(INSTALL_DATA) $$i $(mandir)/man$(api_manext); done for i in $(SRCDIR)/man$(api_manext)/*; do $(INSTALL_DATA) $$i $(mandir)/man$(api_manext); done
clean:: clean::
$(RM) *.aux *.dvi *.out *.tex *.log wine-doc-*.tar.gz wine-faq.html wine-faq.txt $(MAN_TARGETS) $(RM) $(MAN_TARGETS)
$(RM) $(ALLBOOKS:%=%.ps) $(ALLBOOKS:%=%.pdf) $(ALLBOOKS:%=%.html) $(ALLBOOKS:%=%.txt) $(RM) -r html api-guide man$(api_manext)
$(RM) -r html api-guide man$(api_manext) *.junk DBTOHTML_OUTPUT_DIR*
### Dependencies: ### Dependencies:
documentation/address-space.sgml deleted 100644 → 0
View file @ 15ac6847
<chapter id="address-space">
<title> Address space management </title>
<para>
A good understanding of memory layout in Unix and Windows is
required before reading the next section (<xref
linkend="arch-mem"> gives some basic insight).
</para>
<sect1>
<title> Laying out the address space </title>
<para>
Up until about the start of 2004, the Linux address space very much resembled the Windows 9x
layout: the kernel sat in the top gigabyte, the bottom pages were unmapped to catch null
pointer dereferences, and the rest was free. The kernels mmap algorithm was predictable: it
would start by mapping files at low addresses and work up from there.
</para>
<para>
The development of a series of new low level patches violated many of these assumptions, and
resulted in Wine needing to force the Win32 address space layout upon the system. This
section looks at why and how this is done.
</para>
<para>
The exec-shield patch increases security by randomizing the kernels mmap algorithms. Rather
than consistently choosing the same addresses given the same sequence of requests, the kernel
will now choose randomized addresses. Because the Linux dynamic linker (ld-linux.so.2) loads
DSOs into memory by using mmap, this means that DSOs are no longer loaded at predictable
addresses, so making it harder to attack software by using buffer overflows. It also attempts
to relocate certain binaries into a special low area of memory known as the ASCII armor so
making it harder to jump into them when using string based attacks.
</para>
<para>
Prelink is a technology that enhances startup times by precalculating ELF global offset
tables then saving the results inside the native binaries themselves. By grid fitting each
DSO into the address space, the dynamic linker does not have to perform as many relocations
so allowing applications that heavily rely on dynamic linkage to be loaded into memory much
quicker. Complex C++ applications such as Mozilla, OpenOffice and KDE can especially benefit
from this technique.
</para>
<para>
The 4G VM split patch was developed by Ingo Molnar. It gives the Linux kernel its own address
space, thereby allowing processes to access the maximum addressable amount of memory on a
32-bit machine: 4 gigabytes. It allows people with lots of RAM to fully utilise that in any
given process at the cost of performance: the reason behind
giving the kernel a part of each processes address space was to avoid the overhead of switching on
each syscall.
</para>
<para>
Each of these changes alter the address space in a way incompatible with Windows. Prelink and
exec-shield mean that the libraries Wine uses can be placed at any point in the address
space: typically this meant that a library was sitting in the region that the EXE you wanted
to run had to be loaded (remember that unlike DLLs, EXE files cannot be moved around in
memory). The 4G VM split means that programs could receive pointers to the top gigabyte of
address space which some are not prepared for (they may store extra information in the high
bits of a pointer, for instance). In particular, in combination with exec-shield this one is
especially deadly as it's possible the process heap could be allocated beyond
ADDRESS_SPACE_LIMIT which causes Wine initialization to fail.
</para>
<para>
The solution to these problems is for Wine to reserve particular parts of the address space
so that areas that we don't want the system to use will be avoided. We later on
(re/de)allocate those areas as needed. One problem is that some of these mappings are put in
place automatically by the dynamic linker: for instance any libraries that Wine
is linked to (like libc, libwine, libpthread etc) will be mapped into memory before Wine even
gets control. In order to solve that, Wine overrides the default ELF initialization sequence
at a low level and reserves the needed areas by using direct syscalls into the kernel (ie
without linking against any other code to do it) before restarting the standard
initialization and letting the dynamic linker continue. This is referred to as the
preloader and is found in loader/preloader.c.
</para>
<para>
Once the usual ELF boot sequence has been completed, some native libraries may well have been
mapped above the 3gig limit: however, this doesn't matter as 3G is a Windows limit, not a
Linux limit. We still have to prevent the system from allocating anything else above there
(like the heap or other DLLs) though so Wine performs a binary search over the upper gig of
address space in order to iteratively fill in the holes with MAP_NORESERVE mappings so the
address space is allocated but the memory to actually back it is not. This code can be found
in libs/wine/mmap.c:reserve_area.
</para>
</sect1>
</chapter>
documentation/configuring.sgml deleted 100644 → 0
View file @ 15ac6847
This source diff could not be displayed because it is too large. You can view the blob instead.
documentation/ddraw.sgml deleted 100644 → 0
View file @ 15ac6847
<chapter id="ddraw">
<title>Outline of DirectDraw Architecture</title>
<para>
This is an outline of the architecture. Many details are
skipped, but hopefully this is useful.
</para>
<sect1 id="ddinheritance">
<title>DirectDraw inheritance tree</title>
<programlisting>
Main
|
User
|-----------\
XVidMode DGA2
</programlisting>
<para>
Most of the DirectDraw functionality is implemented in a common base
class. Derived classes are responsible for providing display
mode functions (Enum, Set, Restore), GetCaps, GetDevice identifier
and internal functions called to create primary and backbuffer
surfaces.
</para>
<para>
User provides for DirectDraw capabilities based on drawing to a
Wine window. It uses the User DirectDrawSurface implementation
for primary and backbuffer surfaces.
</para>
<para>
XVidMode attempt to use the XFree86 VidMode extension to set the
display resolution to match the parameters to SetDisplayMode.
</para>
<para>
DGA2 attempt to use the XFree86 DGA 2.x extension to set the
display resolution and direct access to the framebuffer, if the
full-screen-exclusive cooperative level is used. If not, it just
uses the User implementation.
</para>
</sect1>
<sect1 id="ddsurfaceinheritance">
<title>DirectDrawSurface inheritance tree</title>
<programlisting>
Main
|--------------\
| |
DIB Fake Z-Buffer
|
|------\---------\
| | |
User DGA2 DIBTexture
</programlisting>
<para>
Main provides a very simple base class that does not implement any of
the image-related functions. Therefore it does not place any
constraints on how the surface data is stored.
</para>
<para>
DIB stores the surface data in a DIB section. It is used by the Main
DirectDraw driver to create off-screen surfaces.
</para>
<para>
User implements primary and backbuffer surfaces for the User DirectDraw
driver. If it is a primary surface, it will attempt to keep itself
synchronized to the window.
</para>
<para>
DGA2 surfaces claims an appropriate section of framebuffer space and
lets DIB build its DIB section on top of it.
</para>
<para>
Fake Z-Buffer surfaces are used by Direct3D to indicate that a primary
surface has an associated z-buffer. For a first implementation, it
doesn't need to store any image data since it is just a placeholder.
</para>
<para>
(Actually 3D programs will rarely use Lock or GetDC on primary
surfaces, backbuffers or z-buffers so we may want to arrange for
lazy allocation of the DIB sections.)
</para>
</sect1>
<sect1 id="interfacethunks">
<title>Interface Thunks</title>
<para>
Only the most recent version of an interface needs to be implemented.
Other versions are handled by having thunks convert their parameters
and call the root version.
</para>
<para>
Not all interface versions have thunks. Some versions could be combined
because their parameters were compatible. For example if a structure
changes but the structure has a dwSize field, methods using that structure
are compatible, as long as the implementation remembers to take the dwSize
into account.
</para>
<para>
Interface thunks for Direct3D are more complicated since the paradigm
changed between versions.
</para>
</sect1>
<sect1 id="logicalobjectlayout">
<title>Logical Object Layout</title>
<para>
The objects are split into the generic part (essentially the fields for
Main) and a private part. This is necessary because some objects
can be created with CoCreateInstance, then Initialized later. Only
at initialization time do we know which class to use. Each class
except Main declares a Part structure and adds that to its Impl.
</para>
<para>
For example, the DIBTexture DirectDrawSurface implementation looks
like this:
</para>
<programlisting>
struct DIBTexture_DirectDrawSurfaceImpl_Part
{
union DIBTexture_data data; /*declared in the real header*/
};
typedef struct
{
struct DIB_DirectDrawSurfaceImpl_Part dib;
struct DIBTexture_DirectDrawSurfaceImpl_Part dibtexture;
} DIBTexture_DirectDrawSurfaceImpl;
</programlisting>
<para>
So the DIBTexture surface class is derived from the DIB surface
class and it adds one piece of data, a union.
</para>
<para>
Main does not have a Part structure. Its fields are stored in
IDirectDrawImpl/IDirectDrawSurfaceImpl.
</para>
<para>
To access private data, one says
</para>
<programlisting>
DIBTexture_DirectDrawSurfaceImpl* priv = This->private;
do_something_with(priv->dibtexture.data);
</programlisting>
</sect1>
<sect1 id="creatingobject">
<title>Creating Objects</title>
<para>
Classes have two functions relevant to object creation, Create and
Construct. To create a new object, the class' Create function is
called. It allocates enough memory for IDirectDrawImpl or
IDirectDrawSurfaceImpl as well as the private data for derived
classes and then calls Construct.
</para>
<para>
Each class's Construct function calls the base class's Construct,
then does the necessary initialization.
</para>
<para>
For example, creating a primary surface with the user ddraw driver
calls User_DirectDrawSurface_Create which allocates memory for the
object and calls User_DirectDrawSurface_Construct to initialize it.
This calls DIB_DirectDrawSurface_Construct which calls
Main_DirectDrawSurface_Construct.
</para>
</sect1>
</chapter>
<!-- Keep this comment at the end of the file
Local variables:
mode: sgml
sgml-parent-document:("wine-devel.sgml" "set" "book" "chapter" "")
End:
-->
documentation/glossary.sgml deleted 100644 → 0
View file @ 15ac6847
<glossary id="glossary">
<title>Glossary</title>
<!--
EXAMPLE:
<glossdiv>
<title>test</title>
<glossentry sortas="rme">
<glossterm id="bad_mistake">Very Stupid Mistake</glossterm>
<glosssee>things_to_avoid</glosssee>
<acronym>VSM</acronym>
<abbrev>Doh!</abbrev>
<glossseealso otherterm="accident">
<glossdef>
<para>Something you should try to avoid at all costs.</para>
</glossdef>
</glossentry>
</glossdiv>
-->
<glossdiv>
<title></title>
<glossentry>
<glossterm>Binary</glossterm>
<glossdef>
<para>
A file which is in machine executable, compiled form: hex data (as opposed to a source code file).
</para>
</glossdef>
</glossentry>
<glossentry>
<glossterm>CVS</glossterm>
<glossdef>
<para>
Concurrent Versions System, a software package to manage software development done by several people. See the CVS chapter in the Wine Developers Guide for detailed usage information.
</para>
</glossdef>
</glossentry>
<glossentry>
<glossterm>Distribution</glossterm>
<glossdef>
<para>
A distribution is usually the way in which some "vendor" ships operating system CDs (usually mentioned in the context of Linux).
A Linux environment can be shipped in lots of different configurations: e.g. distributions could be built to be suitable for games, scientific
applications, server operation, desktop systems, etc.
</para>
</glossdef>
</glossentry>
<glossentry>
<glossterm>DLL</glossterm>
<glossdef>
<para>
A DLL (Dynamic Link Library) is a file that can be loaded and executed by programs dynamically. Basically it's an external code repository for programs.
Since usually several different programs reuse the same DLL instead of having that code in their own file, this dramatically reduces required storage space.
A synonym for a DLL would be library.
</para>
</glossdef>
</glossentry>
<glossentry>
<glossterm>Editor</glossterm>
<glossdef>
<para>
An editor is usually a program to create or modify text files.
There are various graphical and text mode editors available on
Linux.
</para>
<para>
Examples of graphical editors are: nedit, gedit, kedit, xemacs,
gxedit.
</para>
<para>
Examples of text mode editors are: joe, ae, emacs, vim, vi.
In a <glossterm>terminal</glossterm>, simply run them via:
</para>
<screen>
<prompt>$ </><userinput><replaceable>editorname</replaceable>
<replaceable>filename</replaceable></>
</screen>
</glossdef>
</glossentry>
<glossentry>
<glossterm>Environment variable</glossterm>
<glossdef>
<para>
Environment variables are text definitions used in a <glossterm>Shell</glossterm> to store important system settings.
In a <command>bash</command> shell (the most commonly used one in Linux),
you can view all environment variables by executing:
</para>
<screen>
<userinput>set</userinput>
</screen>
<para>
If you want to change an environment variable, you could run:
</para>
<screen>
<userinput>export <replaceable>MYVARIABLE</>=<replaceable>mycontent</></userinput>
</screen>
<para>
For deleting an environment variable, use:
</para>
<screen>
<userinput>unset <replaceable>MYVARIABLE</></userinput>
</screen>
</glossdef>
</glossentry>
<glossentry>
<glossterm>Package</glossterm>
<glossdef>
<para>
A package is a compressed file in a
<glossterm>distribution</glossterm> specific format. It contains the
files for a particular program you want to install. Packages are
usually installed via the <command>dpkg</command> or
<command>rpm</command> package managers.
</para>
</glossdef>
</glossentry>
<glossentry>
<glossterm>root</glossterm>
<glossdef>
<para>
root is the account name of the system administrator.
In order to run programs as root, simply open a
<glossterm>Terminal</glossterm> window, then run:
</para>
<screen>
<prompt>$ </><userinput>su -</>
</screen>
<para>
This will prompt you for the password of the root user of your system,
and after that you will be able to system administration tasks
that require special root privileges. The root account is indicated by the
</para>
<screen>
<prompt># </>
</screen>
<para>
prompt, whereas '$' indicates a normal user account.
</para>
</glossdef>
</glossentry>
<glossentry>
<glossterm>Shell</glossterm>
<glossdef>
<para>
A shell is a tool to enable users to interact with the
system. Usually shells are text based and command line oriented.
Examples of popular shells include <command>bash</command>,
<command>tcsh</command> and <command>ksh</command>. Wine assumes
that for Wine installation tasks, you use <command>bash</command>,
since this is the most popular shell on Linux.
Shells are usually run in a <glossterm>Terminal</glossterm> window.
</para>
<!-- <glossseealso otherterm="Terminal"> -->
</glossdef>
</glossentry>
<glossentry>
<glossterm>Source code</glossterm>
<glossdef>
<para>
Source code is the code that a program consists of before the program
is being compiled, i.e. it's the original building instructions of a
program that tell a compiler what the program should look like once
it's been compiled to a <glossterm>Binary</glossterm>.
</para>
</glossdef>
</glossentry>
<glossentry>
<glossterm>Terminal</glossterm>
<glossdef>
<para>
A terminal window is usually a graphical window that one uses to
execute a <command>Shell</command>. If Wine asks you to open a
terminal, then you usually need to click on an icon on your desktop
that shows a big black window (or, in other cases, an icon displaying a
maritime shell).
Wine assumes you're using the <command>bash</command> shell in a
terminal window, so if your terminal happens to use a different
shell program, simply type:
</para>
<screen>
<userinput>bash</>
</screen>
<para>
in the terminal window.
</para>
</glossdef>
</glossentry>
</glossdiv>
</glossary>
documentation/patches.sgml deleted 100644 → 0
View file @ 15ac6847
<chapter id="patches">
<title>Submitting Patches</title>
<sect1 id="patch-format">
<title>Patch Format</title>
<para>
Patches are submitted via email to the Wine patches mailing list,
<email>wine-patches@winehq.org</email>. Your patch should include:
</para>
<itemizedlist>
<listitem>
<para>
A meaningful subject (very short description of patch)
</para>
</listitem>
<listitem>
<para>
A long (paragraph) description of what was wrong and what is now
better. (recommended)
</para>
</listitem>
<listitem>
<para>
A change log entry (short description of what was changed).
</para>
</listitem>
<listitem>
<para>
The patch in <command>diff -u</command> format
</para>
</listitem>
</itemizedlist>
<para>
</para>
<para>
<command>cvs diff -u</command> works great for the common case
where a file is edited. However, if you add or remove a file
<command>cvs diff</command> will not report that correctly so
make sure you explicitly take care of this rare case.
</para>
<para>
For additions simply include them by appending the
<command>diff -u /dev/null /my/new/file</command> output of them
to any <command>cvs diff -u</command> output you may have.
Alternatively, use <command>diff -Nu olddir/ newdir/</command>
in case of multiple new files to add.
</para>
<para>
For removals, clearly list the files in the description of the patch.
</para>
<para>
Since wine is constantly changing due to development it is strongly
recommended that you use cvs for patches, if you cannot use cvs for
some reason, you can submit patches against the latest tarball.
To do this make a copy of the files that you will be modifying and
<command>diff -u</command> against the old file. I.E.
</para>
<screen>
diff -u file.old file.c > file.txt
</screen>
</sect1>
<sect1 id="Style-notes">
<title>Some notes about style</title>
<para>
There are a few conventions that about coding style that have been
adopted over the years of development. The rational for these
<quote>rules</quote> is explained for each one.
</para>
<itemizedlist>
<listitem>
<para>
No HTML mail, since patches should be in-lined and HTML turns the
patch into garbage. Also it is considered bad etiquette as it
uglifies the message, and is not viewable by many of the subscribers.
</para>
</listitem>
<listitem>
<para>
Only one change set per patch. Patches should address only one
bug/problem at a time. If a lot of changes need to be made then it
is preferred to break it into a series of patches. This makes it
easier to find regressions.
</para>
</listitem>
<listitem>
<para>
Tabs are not forbidden but discouraged. A tab is defined as
8 characters and the usual amount of indentation is 4
characters.
</para>
</listitem>
<listitem>
<para>
C++ style comments are discouraged since some compilers choke on
them.
</para>
</listitem>
<listitem>
<para>
Commenting out a block of code is usually done by enclosing it in
<command>#if 0 ... #endif</command> Statements. For example.
</para>
<screen>
/* note about reason for commenting block */
#if 0
code
code /* comments */
code
#endif
</screen>
<para>
The reason for using this method is that it does not require that
you edit comments that may be inside the block of code.
</para>
</listitem>
<listitem>
<para>
Patches should be in-lined (if you can configure your email client to
not wrap lines), or attached as plain text attachments so they can
be read inline. This may mean some more work for you. However it
allows others to review your patch easily and decreases the chances
of it being overlooked or forgotten.
</para>
</listitem>
<listitem>
<para>
Code is usually limited to 80 columns. This helps prevent mailers
mangling patches by line wrap. Also it generally makes code easier
to read.
</para>
</listitem>
<listitem>
<para>
If the patch fixes a bug in Bugzilla please provide a link to the
bug in the comments of the patch. This will make it easier for the
maintainers of Bugzilla.
</para>
</listitem>
</itemizedlist>
<sect2 id="Inline-Attachments-with-OE">
<title>Inline attachments with Outlook Express</title>
<para>
Outlook Express is notorious for mangling attachments. Giving the
patch a <filename>.txt</filename> extension and attaching will solve
the problem for most mailers including Outlook. Also, there is a way
to enable Outlook Express send <filename>.diff</filename>
attachments.
</para>
<para>
You need following two things to make it work.
</para>
<orderedlist>
<listitem>
<para>
Make sure that <filename>.diff</filename> files have \r\n line
ends, because if OE detects that there is no \r\n line endings it
switches to quoted-printable format attachments.
</para>
</listitem>
<listitem>
<para>
Using regedit add key "Content Type" with value "text/plain"
to the .diff extension under HKEY_CLASSES_ROOT (same as for .txt
extension). This tells OE to use Content-Type: text/plain instead
of application/octet-stream.
</para>
</listitem>
</orderedlist>
<para>
Item #1 is important. After you hit "Send" button, go to "Outbox"
and using "Properties" verify the message source to make sure that
the mail has correct format. You might want to send several test
emails to yourself too.
</para>
</sect2>
<sect2 id="Alexandre-Bottom-Line">
<title>Alexandre's Bottom Line</title>
<para>
<quote>The basic rules are: no attachments, no mime crap, no
line wrapping, a single patch per mail. Basically if I can't
do <command>"cat raw_mail | patch -p0"</command> it's in the
wrong format.</quote>
</para>
</sect2>
</sect1>
<sect1 id="patch-quality">
<title>Quality Assurance</title>
<para>
(Or, "How do I get Alexandre to apply my patch quickly so I
can build on it and it will not go stale?")
</para>
<para>
Make sure your patch applies to the current CVS head
revisions. If a bunch of patches are committed to CVS that may
affect whether your patch will apply cleanly then verify that
your patch does apply! <command>cvs update</command> is your
friend!
</para>
<para>
Try to test your patch against more than just your current test
example. Experience will tell you how much effort to apply here.
If there are any conformance tests for the code you're working on,
run them and make sure they still pass after your patch is applied.
Running tests can be done by running <command>make test</command>.
You may need to run <command>make testclean</command> to undo the
results of a previous test run.
</para>
<para>
Please consider submitting a conformance test for your changes.
This will make it a lot clearer for everyone that your patch is
needed, and it will prevent future breakage. While you are not
strictly required to submit tests, it is highly encouraged to do so.
See the <quote>testing</quote> guide for more details on Wine's
conformance tests.
</para>
</sect1>
</chapter>
<!-- Keep this comment at the end of the file
Local variables:
mode: sgml
sgml-parent-document:("wine-devel.sgml" "set" "book" "part" "chapter" "")
End:
-->
documentation/printing.sgml deleted 100644 → 0
View file @ 15ac6847
<sect1 id="config-printing">
<title>Printing in Wine</title>
<para>How to print documents in Wine...</para>
<sect2 id="config-printing-intro">
<title>Printing</title>
<para>
Printing in Wine can be done using the built-in Wine PostScript driver (+ ghostscript to produce
output for non-PostScript printers).
</para>
<para>
Note that at the moment WinPrinters (cheap, dumb printers that require
the host computer to explicitly control the head) will not work with
their Windows printer drivers. It is unclear whether they ever will.
</para>
<sect3>
<title>Built-in Wine PostScript driver</title>
<para>
Enables printing of PostScript files via a driver built into Wine. See
below for installation instructions. The code for the PostScript
driver is in <filename>dlls/wineps/</filename>.
</para>
<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>
</sect3>
<sect3>
<title>Spooling</title>
<para>
Spooling is rather primitive. The [spooler] section of
the wine config file 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>
<para>
There are now also virtual spool queues called
<systemitem>LPR:printername</systemitem>, which send the data
to <command>lpr -Pprintername</command>. You do not need to
specify those in the config file, they are handled automatically by
<filename>dlls/gdi/printdrv.c</filename>.
</para>
</sect3>
</sect2>
<sect2 id="config-printing-psdriver">
<title>The Wine PostScript Driver</title>
<para>
This allows Wine to generate PostScript files without
needing an external printer driver. Wine in this case uses the
system provided PostScript printer filters, which almost all use
ghostscript if necessary. Those should be configured during the
original system installation or by your system administrator.
</para>
<sect3>
<title>Installation</title>
<sect4>
<title>Installation of CUPS printers</title>
<para>
If you are using CUPS, you do not need to configure .ini or
registry entries, everything is autodetected.
</para>
</sect4>
<sect4>
<title>Installation of LPR /etc/printcap based printers</title>
<para>
If your system is not yet using CUPS, it probably uses LPRng
or a LPR based system with configuration based on <filename>/etc/printcap</filename>.
</para>
<para>
If it does, your printers in <filename>/etc/printcap</filename>
are scanned with a heuristic whether they are PostScript capable
printers and also configured mostly automatic.
</para>
<para>
Since Wine cannot find out what type of printer this is, you
need to specify a PPD file in the [ppd] section of
<filename>~/.wine/config</filename>. Either use the shortcut
name and make the entry look like:
</para>
<screen>
[ppd]
"ps1" = "/usr/lib/wine/ps1.ppd"
</screen>
<para>
Or you can specify a generic PPD file that is to match for all
of the remaining printers. A generic PPD file can be found in
<filename>documentation/samples/generic.ppd</filename>.
</para>
</sect4>
<sect4>
<title>Installation of other printers</title>
<para>
You do not need to do this if the above 2 sections apply, only if
you have a special printer.
</para>
<screen>
Wine PostScript Driver=WINEPS,LPT1:
</screen>
<para>
to the [devices] section and
</para>
<screen>
Wine PostScript Driver=WINEPS,LPT1:,15,45
</screen>
<para>
to the [PrinterPorts] 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>.
</para>
<para>
You also need to add certain entries to the registry.
The easiest way to do this is to customize the PostScript
driver contents of <filename>wine.inf</filename> (see below) and use the
Winelib program <command>programs/regedit/regedit</command>. For
example, if you have installed the Wine source tree in
<filename>/usr/src/wine</filename>, you could use the following
series of commands:
<itemizedlist>
<listitem>
<para>
<userinput>#vi /usr/share/wine/wine.inf</userinput>
</para>
</listitem>
<listitem>
<para>
Edit the copy of <filename>wine.inf</filename> to suit your
PostScript printing requirements.
At a minimum, you must specify a PPD file for each printer.
</para>
</listitem>
<listitem>
<para>
<userinput>$wineprefixcreate</userinput>
</para>
</listitem>
</itemizedlist>
</para>
</sect4>
<sect4>
<title>Required configuration for all printer types</title>
<para>
You won't need Adobe Font Metric (AFM) files for the (type 1 PostScript)
fonts that you wish to use any more.
Wine now has this information built-in.
</para>
<para>
You'll need 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 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>.
See above for information on configuring the driver to use this
file.
</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 the wine config file, this
enables printing via external printer drivers and does not
affect the built-in PostScript driver.
</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>
</sect4>
</sect3>
</sect2>
</sect1>
<!-- Keep this comment at the end of the file
Local variables:
mode: sgml
sgml-parent-document:("wine-user.sgml" "set" "book" "chapter" "")
End:
-->
documentation/wine-devel.sgml deleted 100644 → 0
View file @ 15ac6847
<!doctype book PUBLIC "-//OASIS//DTD DocBook V3.1//EN" [
<!entity debugger SYSTEM "debugger.sgml">
<!entity debugging SYSTEM "debugging.sgml">
<!entity otherdebug SYSTEM "winedev-otherdebug.sgml">
<!entity codingpractice SYSTEM "winedev-coding.sgml">
<!entity testing SYSTEM "testing.sgml">
<!entity documentation SYSTEM "documentation.sgml">
<!entity architecture SYSTEM "architecture.sgml">
<!entity kernel SYSTEM "winedev-kernel.sgml">
<!entity graphical SYSTEM "winedev-graphical.sgml">
<!entity windowing SYSTEM "winedev-windowing.sgml">
<!entity ole SYSTEM "ole.sgml">
<!entity opengl SYSTEM "opengl.sgml">
<!entity ddraw SYSTEM "ddraw.sgml">
<!entity multimedia SYSTEM "multimedia.sgml">
]>
<book id="index">
<bookinfo>
<title>Wine Developer's Guide</title>
<!-- Until we learn how to format this thing nicely,
we can't really include it -->
<!--authorgroup>
<author>
<firstname>Uwe</firstname>
<surname>Bonnes</surname>
</author>
<author>
<firstname>Jonathan</firstname>
<surname>Buzzard</surname>
</author>
<author>
<firstname>Zoran</firstname>
<surname>Dzelajlija</surname>
</author>
<author>
<firstname>Klaas</firstname>
<surname>van Gend</surname>
</author>
<author>
<firstname>Francois</firstname>
<surname>Gouget</surname>
</author>
<author>
<firstname>Jon</firstname>
<surname>Griffiths</surname>
</author>
<author>
<firstname>Albert</firstname>
<surname>den Haan</surname>
</author>
<author>
<firstname>Mike</firstname>
<surname>Hearn</surname>
</author>
<author>
<firstname>Ove</firstname>
<surname>Kaaven</surname>
</author>
<author>
<firstname>Tony</firstname>
<surname>Lambregts</surname>
</author>
<author>
<firstname>Marcus</firstname>
<surname>Meissner</surname>
</author>
<author>
<firstname>Gerard</firstname>
<surname>Patel</surname>
</author>
<author>
<firstname>Dimitrie</firstname>
<surname>Paun</surname>
</author>
<author>
<firstname>Michele</firstname>
<surname>Petrovski</surname>
</author>
<author>
<firstname>Eric</firstname>
<surname>Pouech</surname>
</author>
<author>
<firstname>Douglas</firstname>
<surname>Ridgway</surname>
</author>
<author>
<firstname>John</firstname>
<surname>Sheets</surname>
</author>
<author>
<firstname>Lionel</firstname>
<surname>Ulmer</surname>
</author>
<author>
<firstname>Ulrich</firstname>
<surname>Weigand</surname>
</author>
<author>
<firstname>Morten</firstname>
<surname>Welinder</surname>
</author>
</authorgroup-->
</bookinfo>
<part id="part-one">
<title>Developing Wine</title>
&debugger;
&debugging;
&otherdebug;
&codingpractice;
&testing;
&documentation;
</part>
<part id="part-two">
<title>Wine Architecture</title>
&architecture;
&kernel;
&graphical;
&windowing;
&ole;
&opengl;
&ddraw;
&multimedia;
</part>
</book>
documentation/wine-faq.sgml deleted 100644 → 0
View file @ 15ac6847
<!doctype Article PUBLIC "-//OASIS//DTD DocBook V3.1//EN" [
<!entity faq SYSTEM "faq.sgml">
]>
<article class="faq" id="index">
&faq;
</article>
documentation/wine-user.sgml deleted 100644 → 0
View file @ 15ac6847
<!doctype book PUBLIC "-//OASIS//DTD DocBook V3.1//EN" [
<!entity introduction SYSTEM "introduction.sgml">
<!entity getting SYSTEM "getting.sgml">
<!entity configuring SYSTEM "configuring.sgml">
<!entity registry SYSTEM "registry.sgml">
<!entity fonts SYSTEM "fonts.sgml">
<!entity printing SYSTEM "printing.sgml">
<!entity running SYSTEM "running.sgml">
<!entity bugs SYSTEM "bugs.sgml">
<!entity glossary SYSTEM "glossary.sgml">
]>
<book id="index">
<bookinfo>
<title>Wine User Guide</title>
<!-- Until we learn how to format this thing nicely,
we can't really incude it -->
<!--authorgroup>
<author>
<firstname>Scott</firstname>
<surname>Ritchie</surname>
</author>
<author>
<firstname>Brian</firstname>
<surname>Vincent</surname>
</author>
<author>
<firstname>Huw</firstname>
<surname>Davies</surname>
</author>
<author>
<firstname>Steven</firstname>
<surname>Elliott</surname>
</author>
<author>
<firstname>Mike</firstname>
<surname>Hearn</surname>
</author>
<author>
<firstname>James</firstname>
<surname>Juran</surname>
</author>
<author>
<firstname>Ove</firstname>
<surname>Kaaven</surname>
</author>
<author>
<firstname>Alex</firstname>
<surname>Korobka</surname>
</author>
<author>
<firstname>Bruce</firstname>
<surname>Milner</surname>
</author>
<author>
<firstname>Andreas</firstname>
<surname>Mohr</surname>
</author>
<author>
<firstname>Dustin</firstname>
<surname>Navea</surname>
</author>
<author>
<firstname>Eric</firstname>
<surname>Pouech</surname>
</author>
<author>
<firstname>Adam</firstname>
<surname>Sacarny</surname>
</author>
<author>
<firstname>John</firstname>
<surname>Sheets</surname>
</author>
<author>
<firstname>Petr</firstname>
<surname>Tomasek</surname>
</author>
</authorgroup-->
</bookinfo>
&introduction;
&getting;
&configuring;
&running;
&bugs;
&glossary;
</book>
documentation/winedev-graphical.sgml deleted 100644 → 0
View file @ 15ac6847
<chapter>
<title>Graphical modules</title>
<sect1>
<title>GDI Module</title>
<sect2>
<title>X Windows System interface</title>
<para>
The X libraries used to implement X clients (such as Wine)
do not work properly if multiple threads access the same
display concurrently. It is possible to compile the X
libraries to perform their own synchronization (initiated
by calling <function>XInitThreads()</function>). However,
Wine does not use this approach. Instead Wine performs its
own synchronization using the
<function>wine_tsx11_lock()</function> / <function>wine_tsx11_unlock()</function>
functions. This locking protects library access
with a critical section, and also arranges things so that
X libraries compiled without <option>-D_REENTRANT</option>
(eg. with global <varname>errno</varname> variable) will
work with Wine.
</para>
<para>
In the past, all calls to X used to go through a wrapper called
<function>TSX...()</function> (for "Thread Safe X ...").
While it is still being used in the code, it's inefficient
as the lock is potentially aquired and released unnecessarily.
New code should explicitly aquire the lock.
</para>
</sect2>
</sect1>
</chapter>
<!-- Keep this comment at the end of the file
Local variables:
mode: sgml
sgml-parent-document:("wine-devel.sgml" "set" "book" "part" "chapter" "")
End:
-->
documentation/winedev-kernel.sgml deleted 100644 → 0
View file @ 15ac6847
This source diff could not be displayed because it is too large. You can view the blob instead.
documentation/winelib-mfc.sgml deleted 100644 → 0
View file @ 15ac6847
<chapter id="mfc">
<title id="mfc.title">Dealing with the MFC</title>
<sect1 id="mfc-introduction">
<title id="mfc-introduction.title">Introduction</title>
<para>
To use the MFC in a Winelib application you will first have to
recompile the MFC with Winelib. In theory it should be possible to
write a wrapper for the Windows MFC as described in
<xref linkend="bindlls" endterm="bindlls.title">. But in practice
it does not seem to be a realistic approach for the MFC:
</para>
<itemizedlist>
<listitem>
<para>
the huge number of APIs makes writing the wrapper a big task in
itself.
</para>
</listitem>
<listitem>
<para>
furthermore the MFC contain a huge number of APIs which are tricky
to deal with when making a wrapper.
</para>
</listitem>
<listitem>
<para>
even once you have written the wrapper you will need to modify
the MFC headers so that the compiler does not choke on them.
</para>
</listitem>
<listitem>
<para>
a big part of the MFC code is actually in your application in
the form of macros. This means even more of the MFC headers have
to actually work to in order for you to be able to compile an
MFC based application.
</para>
</listitem>
</itemizedlist>
<para>
This is why this guide includes a section dedicated to helping you
compile the MFC with Winelib.
</para>
</sect1>
<sect1 id="mfc-legal-issues">
<title id="mfc-legal-issues.title">Legal issues</title>
<para>
The purpose of this section is to make you aware of potential legal
problems. Be sure to read your licenses and to consult your lawyers.
In any case you should not consider the remainder of this section to
be authoritative since it has not been written by a lawyer.
</para>
<para>
During the compilation of your program, you will be combining code
from several sources: your code, Winelib code, Microsoft MFC code,
and possibly code from other vendor sources. As a result, you must
ensure that the licenses of all code sources are obeyed. What you are
allowed and not allowed to do can vary depending on how you combine
the code and if you will be distributing it. For example, if you
are releasing your code under the GPL or LGPL, you cannot use MFC
because these licenses do not allow covered code to depend on
libraries with non-compatible licenses.
There is a workaround - in the license for your
code you can make an exception for the MFC library.
For details see
<ulink url="http://www.gnu.org/licenses/gpl-faq.html">The GNU GPL FAQ</ulink>.
</para>
<para>
Wine/Winelib is distributed under the GNU Lesser General Public
License. See the license for restrictions on the modification and
distribution of Wine/Winelib code. In general it is possible to
satisfy these restrictions in any type of application.
On the other hand, MFC
is distributed under a very restrictive license and the restrictions
vary from version to version and between service packs. There are
basically three aspects you must be aware of when using the MFC.
</para>
<para>
First you must legally get MFC source code on your computer. The MFC
source code comes as a part of Visual Studio. The license for
Visual Studio implies it is a single product that cannot
be broken up into its components. So the cleanest way to get MFC on
your system is to buy Visual Studio and install it on a dual boot
Linux box.
</para>
<para>
Then you must check that you are allowed to recompile MFC on a
non-Microsoft operating system! This varies with the version of MFC.
The MFC license from Visual Studio 6.0 reads in part:
</para>
<blockquote>
<para>
1.1 General License Grant. Microsoft grants to you as an
individual, a personal, nonexclusive license to make and use
copies of the SOFTWARE PRODUCT for the sole purposes of designing,
developing, and testing your software product(s) that are designed
to operate in conjunction with any Microsoft operating system
product. [Other unrelated stuff deleted.]
</para>
</blockquote>
<para>
So it appears you cannot even compile MFC for Winelib using this
license. Fortunately the Visual Studio 6.0 service pack 3 license
reads (the Visual Studio 5.0 license is similar):
</para>
<blockquote>
<para>
1.1 General License Grant. Microsoft grants to you as an
individual, a personal, nonexclusive license to make and use
copies of the SOFTWARE PRODUCT for the purpose of designing,
developing, and testing your software product(s). [Other unrelated
stuff deleted]
</para>
</blockquote>
<para>
So under this license it appears you can compile MFC for Winelib.
</para>
<para>
Finally you must check whether you have the right to distribute an
MFC library. Check the relevant section of the license on
<quote>redistributables and your redistribution rights</quote>. The
license seems to specify that you only have the right to distribute
binaries of the MFC library if it has no debug information and if
you distribute it with an application that provides significant
added functionality to the MFC library.
<!-- FIXME: quote relevant sections of EULA in above paragraph. -->
</para>
</sect1>
<sect1 id="mfc-compiling">
<title id="mfc-compiling.title">Compiling the MFC</title>
<para>
Here is a set of recommendations for getting the MFC compiled with
WineLib:
</para>
<para>
We recommend running winemaker in
'<option>--interactive</option>' mode to specify the right
options for the MFC and the ATL part (to get the include paths
right, to not consider the MFC MFC-based, and to get it to
build libraries, not executables).
</para>
<para>
Then when compiling it you will indeed need a number of
<literal>_AFX_NO_XXX</literal> macros. But this is not enough
and there are other things you will need to
'<literal>#ifdef</literal>-out'. For instance Wine's richedit
support is not very good. Here are the AFX options I use:
</para>
<para>
<programlisting>
#define _AFX_PORTABLE
#define _FORCENAMELESSUNION
#define _AFX_NO_DAO_SUPPORT
#define _AFX_NO_DHTML_SUPPORT
#define _AFX_NO_OLEDB_SUPPORT
#define _AFX_NO_RICHEDIT_SUPPORT
</programlisting>
</para>
<para>
You will also need custom ones for
<function>CMonikerFile</function>, <function>OleDB</function>,
<function>HtmlView</function>, ...
</para>
<para>
We recommend using Wine's msvcrt headers (<literal>-isystem
$(WINE_INCLUDE_ROOT)/msvcrt</literal>), though it means you
will have to temporarily disable winsock support
(<literal>#ifdef</literal> it out in
<filename>windows.h</filename>).
</para>
<para>
You should use g++ compiler more recent than g++ 2.95. g++
2.95 does not support unnamed structs while the more recent
ones do, and this helps a lot. Here are the options worth
mentioning:
<itemizedlist>
<listitem>
<para>
<literal>-fms-extensions</literal> (helps get more code
to compile)
</para>
</listitem>
<listitem>
<para>
<literal>-fshort-wchar -DWINE_UNICODE_NATIVE</literal>
(helps with Unicode support)
</para>
</listitem>
<listitem>
<para>
<literal>-DICOM_USE_COM_INTERFACE_ATTRIBUTE</literal>
(to get the COM code to work)
</para>
</listitem>
</itemizedlist>
</para>
<para>
When you first reach the link stage you will get a lot of
undefined symbol errors. To fix these you will need to go back
to the source and <literal>#ifdef</literal>-out more code
until you reach a 'closure'. There are also some files that
don't need to be compiled.
</para>
<para>
Maybe we will have ready-made makefile here someday...
</para>
</sect1>
</chapter>
<!-- Keep this comment at the end of the file
Local variables:
mode: sgml
sgml-parent-document:("winelib-user.sgml" "book" "chapter" "")
End:
-->
documentation/winelib-porting.sgml deleted 100644 → 0
View file @ 15ac6847
<chapter id="portability-issues">
<title id="portability-issues.title">Portability issues</title>
<sect1 id="unicode">
<title id="unicode.title">Unicode</title>
<para>
The <literal>wchar_t</literal> type has different standard
sizes in Unix (4 bytes) and Windows (2 bytes). You need a
recent gcc version (2.9.7 or later) that supports the
<parameter>-fshort-wchar</parameter> option to set the
size of <literal>wchar_t</literal> to the one expected
by Windows applications.
</para>
<para>
If you are using Unicode and you want to be able to use
standard library calls (e.g. <function>wcslen</function>,
<function>wsprintf</function>), then you must use
the msvcrt runtime library instead of glibc. The functions in
glibc will not work correctly with 16 bit strings.
</para>
</sect1>
<sect1 id="C-library">
<title id="C-library.title">C library</title>
<para>
There are 2 choices available to you regarding which C library
to use: the native glibc C library or the msvcrt C library.
</para>
<para>
Note that under Wine, the crtdll library is implemented using
msvcrt, so there is no benefit in trying to use it.
</para>
<para>
Using glibc in general has the lowest overhead, but this is
really only important for file I/O, as many of the functions
in msvcrt are simply resolved to glibc.
</para>
<para>
To use glibc, you don't need to make changes to your
application; it should work straight away. There are a few
situations in which using glibc is not possible:
</para>
<orderedlist>
<listitem>
<para>
Your application uses Win32 and C library unicode
functions.
</para>
</listitem>
<listitem>
<para>
Your application uses MS specific calls like
<function>beginthread()</function>,
<function>loadlibrary()</function>, etc.
</para>
</listitem>
<listitem>
<para>
You rely on the precise semantics of the calls, for
example, returning <literal>-1</literal> rather than
non-zero. More likely, your application will rely on calls
like <function>fopen()</function> taking a Windows path
rather than a Unix one.
</para>
</listitem>
</orderedlist>
<para>
In these cases you should use msvcrt to provide your C runtime
calls.
</para>
<programlisting>import msvcrt.dll</programlisting>
<para>
to your applications <filename>.spec</filename> file. This
will cause <command>winebuild</command> to resolve your c
library calls to <filename>msvcrt.dll</filename>. Many simple
calls which behave the same have been specified as
non-importable from msvcrt; in these cases
<command>winebuild</command> will not resolve them and the
standard linker <command>ld</command> will link to the glibc
version instead.
</para>
<para>
In order to avoid warnings in C (and potential errors in C++)
from not having prototypes, you may need to use a set of MS
compatible header files. These are scheduled for inclusion
into Wine but at the time of writing are not available. Until
they are, you can try prototyping the functions you need, or
just live with the warnings.
</para>
<para>
If you have a set of include files (or when they are available
in Wine), you need to use the <parameter>-isystem
"include_path"</parameter> flag to gcc to tell it to use your
headers in preference to the local system headers.
</para>
<para>
To use option 3, add the names of any symbols that you don't
want to use from msvcrt into your applications
<filename>.spec</filename> file. For example, if you wanted
the MS specific functions, but not file I/O, you could have a
list like:
</para>
<programlisting>@ignore = ( fopen fclose fwrite fread fputs fgets )</programlisting>
<para>
Obviously, the complete list would be much longer. Remember
too that some functions are implemented with an underscore in
their name and <function>#define</function>d to that name in
the MS headers. So you may need to find out the name by
examining <filename>dlls/msvcrt/msvcrt.spec</filename> to get
the correct name for your <function>@ignore</function> entry.
</para>
</sect1>
<sect1 id="porting-compiling">
<title id="porting-compiling.title">Compiling Problems</title>
<para>
If you get undefined references to Win32 API calls when
building your application: if you have a VC++
<filename>.dsp</filename> file, check it for all the
<filename>.lib</filename> files it imports, and add them to
your applications <filename>.spec</filename>
file. <command>winebuild</command> gives you a warning for
unused imports so you can delete the ones you don't need
later. Failing that, just import all the DLL's you can find in
the <filename>dlls/</filename> directory of the Wine source
tree.
</para>
<para>
If you are missing GUIDs at the link stage, add
<parameter>-lwine_uuid</parameter> to the link line.
</para>
<para>
gcc is more strict than VC++, especially when compiling
C++. This may require you to add casts to your C++ to prevent
overloading ambiguities between similar types (such as two
overloads that take int and char respectively).
</para>
<para>
If you come across a difference between the Windows headers
and Wine's that breaks compilation, try asking for help on
<email>wine-devel@winehq.org</email>.
</para>
</sect1>
</chapter>
<!-- Keep this comment at the end of the file
Local variables:
mode: sgml
sgml-parent-document:("winelib-user.sgml" "book" "chapter" "")
End:
-->
documentation/winelib-user.sgml deleted 100644 → 0
View file @ 15ac6847
<!doctype book PUBLIC "-//OASIS//DTD DocBook V3.1//EN" [
<!entity intro SYSTEM "winelib-intro.sgml">
<!entity porting SYSTEM "winelib-porting.sgml">
<!entity toolkit SYSTEM "winelib-toolkit.sgml">
<!entity mfc SYSTEM "winelib-mfc.sgml">
<!entity bindlls SYSTEM "winelib-bindlls.sgml">
]>
<book id="index">
<bookinfo>
<title>Winelib User's Guide</title>
<!-- Until we learn how to format this thing nicely,
we can't really include it -->
<!--authorgroup>
<author>
<firstname>Wilbur</firstname>
<surname>Dale</surname>
</author>
<author>
<firstname>Francois</firstname>
<surname>Gouget</surname>
</author>
<author>
<firstname>John</firstname>
<surname>Sheets</surname>
</author>
<authorgroup-->
</bookinfo>
&intro;
&porting;
&toolkit;
&mfc;
&bindlls;
</book>
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