Lots of spelling fixes that accumulated in my tree again, made several
error msgs more verbose, doc updates.
This commit is contained in:
parent
0d18aad17a
commit
2e011a5243
|
@ -2238,7 +2238,7 @@ static HMENU MENU_PtMenu( HMENU hMenu, POINT16 pt )
|
|||
*
|
||||
* Execute a menu item (for instance when user pressed Enter).
|
||||
* Return the wID of the executed item. Otherwise, -1 indicating
|
||||
* that no menu item wase executed;
|
||||
* that no menu item was executed;
|
||||
* Have to receive the flags for the TrackPopupMenu options to avoid
|
||||
* sending unwanted message.
|
||||
*
|
||||
|
|
|
@ -493,14 +493,14 @@ static HRESULT WINAPI Xlib_IDirectDrawImpl_SetDisplayMode(
|
|||
return DDERR_UNSUPPORTEDMODE;
|
||||
|
||||
case -1:
|
||||
/* No convertion */
|
||||
/* No conversion */
|
||||
This->d.pixel_convert = NULL;
|
||||
This->d.palette_convert = NULL;
|
||||
break;
|
||||
|
||||
default:
|
||||
DPRINTF("DirectDraw warning: running in depth-convertion mode. Should run using a %ld depth for optimal performances.\n", depth);
|
||||
/* Set the depth convertion routines */
|
||||
DPRINTF("DirectDraw warning: running in depth-conversion mode. Should run using a %ld depth for optimal performances.\n", depth);
|
||||
/* Set the depth conversion routines */
|
||||
This->d.pixel_convert = ModeEmulations[c].funcs.pixel_convert;
|
||||
This->d.palette_convert = ModeEmulations[c].funcs.palette_convert;
|
||||
}
|
||||
|
|
|
@ -198,7 +198,7 @@ struct IDirectDrawPaletteImpl
|
|||
DWORD ref;
|
||||
|
||||
/* IDirectDrawPalette fields */
|
||||
IDirectDrawImpl* ddraw; /* direct draw, no referencecount */
|
||||
IDirectDrawImpl* ddraw; /* direct draw, no reference count */
|
||||
PALETTEENTRY palents[256];
|
||||
|
||||
/* This is to store the palette in 'screen format' */
|
||||
|
|
|
@ -1,7 +1,7 @@
|
|||
/* MESA private include file
|
||||
(c) 1998 Lionel ULMER
|
||||
|
||||
This files contains all the structure that are not exported
|
||||
This file contains all structures that are not exported
|
||||
through d3d.h and all common macros. */
|
||||
|
||||
#ifndef __GRAPHICS_WINE_MESA_PRIVATE_H
|
||||
|
|
|
@ -41,7 +41,7 @@ typedef struct IDirectPlay4Impl IDirectPlay4Impl;
|
|||
/*****************************************************************************
|
||||
* IDirectPlay implementation structure
|
||||
*
|
||||
* The philosophy behind this extra pointer derefernce is that I wanted to
|
||||
* The philosophy behind this extra pointer dereference is that I wanted to
|
||||
* have the same structure for all types of objects without having to do
|
||||
* alot of casting. I also only wanted to implement an interface in the
|
||||
* object it was "released" with IUnknown interface being implemented in the 1 version.
|
||||
|
|
|
@ -680,7 +680,7 @@ static DWORD wodOpen(WORD wDevID, LPWAVEOPENDESC lpDesc, DWORD dwFlags)
|
|||
audio = open(SOUND_DEV, O_WRONLY|O_NDELAY, 0);
|
||||
if (audio == -1) {
|
||||
WARN("can't open (%d)!\n", errno);
|
||||
return MMSYSERR_ALLOCATED ;
|
||||
return MMSYSERR_ALLOCATED;
|
||||
}
|
||||
|
||||
WOutDev[wDevID].wFlags = HIWORD(dwFlags & CALLBACK_TYPEMASK);
|
||||
|
|
|
@ -253,7 +253,7 @@ static BOOL OSS_MidiInit(void)
|
|||
minfo.device = i;
|
||||
status = ioctl(midiSeqFD, SNDCTL_MIDI_INFO, &minfo);
|
||||
if (status == -1) {
|
||||
ERR("ioctl on midi info failed.\n");
|
||||
ERR("ioctl on midi info for device %d failed.\n", i);
|
||||
midiCloseSeq();
|
||||
return TRUE;
|
||||
}
|
||||
|
|
|
@ -90,11 +90,10 @@ 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). Currently, it is useless when
|
||||
used on cdrom's, however functionality could be implemented later to allow wine
|
||||
to automatically find the cdrom label.
|
||||
NOTE: This setting is not terribly important, almost all apps will have no
|
||||
problem if it remains unspecified. If you are unsure about specifying device
|
||||
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:
|
||||
|
|
|
@ -1,9 +1,10 @@
|
|||
A small WINE distribution guide.
|
||||
|
||||
While packaging WINE for one of the Linux distributions I came across
|
||||
several points which have been clarified yet. Particular a how-to for WINE
|
||||
packaging distributors is missing. This document tries to give a brief
|
||||
overview over the rationales I thought up and how I tried to implement it.
|
||||
several points which have not been clarified yet. Particularly a how-to
|
||||
for WINE packaging distributors is missing. This document tries to give
|
||||
a brief overview over the rationales I thought up and how I tried to
|
||||
implement it.
|
||||
(While the examples use "rpm" most of this stuff can be applied to other
|
||||
packagers too.)
|
||||
|
||||
|
@ -16,11 +17,11 @@ environment !
|
|||
|
||||
A WINE install should:
|
||||
a. Not have a world writeable directory (-tree).
|
||||
b. Require only as much user input as possible. It would be very good if it
|
||||
b. Require only as much user input as needed. It would be very good if it
|
||||
would not require any at all. Just let the system administrator do "rpm
|
||||
-i wine.rpm" and let any user be able to run "wine sol.exe" instantly.
|
||||
c. Give the user as much flexibility to install his own applications, do
|
||||
his own configuring etc.
|
||||
c. Give the user as much flexibility as possible to install his own
|
||||
applications, do his own configuring etc.
|
||||
d. Come as preconfigured as possible, so the user does not need to change
|
||||
any configuration files.
|
||||
e. Use only as much diskspace as needed per user.
|
||||
|
@ -68,7 +69,7 @@ Example (split this into %build and %install section for rpm):
|
|||
|
||||
Here we unfortunately do need to create wineuser.reg and winesystem.reg
|
||||
from the WINE distributed winedefault.reg. This can be done using
|
||||
./regapi once for one example user and the reusing his .wine/user.reg
|
||||
./regapi once for one example user and then reusing his .wine/user.reg
|
||||
and .wine/system.reg files. [FIXME: this needs to be done better]
|
||||
|
||||
install -m 644 wine.sytemreg $BR/etc/wine/
|
||||
|
@ -175,7 +176,7 @@ WINE. This script should:
|
|||
|
||||
- Symlink all .dll and .exe files from the original windows installation to
|
||||
the windows directory. Why? Some program reference "%windowsdir%/file.dll"
|
||||
or "%systemdir%/file.dll" directly and fail if there are not present.
|
||||
or "%systemdir%/file.dll" directly and fail if they are not present.
|
||||
|
||||
This will give a huge number of symlinks, yes. However, if an installer
|
||||
later overwrites on of those files, it will overwrite the symlink (so
|
||||
|
|
|
@ -12,11 +12,11 @@ How To Convert Windows Fonts
|
|||
If you have access to a Windows installation you should use
|
||||
fnt2bdf utility (found in the 'tools)' directory to convert
|
||||
bitmap fonts (VGASYS.FON, SSERIFE.FON, and SERIFE.FON) into
|
||||
the format that X Window System can recognize.
|
||||
the format that the X Window System can recognize.
|
||||
|
||||
Step 1. Extract bitmap fonts with 'fnt2bdf'.
|
||||
|
||||
Step 2. Convert .bdf files produced by the Step 1 into
|
||||
Step 2. Convert .bdf files produced by Step 1 into
|
||||
.pcf files with 'bdftopcf'.
|
||||
|
||||
Step 3. Copy .pcf files to the font server directory which
|
||||
|
|
|
@ -35,9 +35,10 @@ designed to make this possible. Here are some tips by Juergen Schmied
|
|||
(and others) on how to proceed. This assumes that your C:\windows
|
||||
directory in the configuration file does not point to a native Windows
|
||||
installation but is in a separate Unix file system. (For instance,
|
||||
C:\windows is really /home/ego/wine/drives/c).
|
||||
"C:\windows" is really subdirectory "windows" located in
|
||||
"/home/ego/wine/drives/c").
|
||||
|
||||
- Run the application with -debugmsg +module,+file to find out
|
||||
- Run the application with --debugmsg +module,+file to find out
|
||||
which files are needed. Copy the required DLL's one by one to the
|
||||
C:\windows\system directory. Do not copy KERNEL/KERNEL32, GDI/GDI32,
|
||||
or USER/USER32. These implement the core functionality of the
|
||||
|
|
|
@ -128,7 +128,7 @@ static void REGISTRY_Init(void) {
|
|||
RegSetValueExA(hkey,"Identifier",0,REG_SZ,"SystemType WINE",strlen("SystemType WINE"));
|
||||
RegCloseKey(hkey);
|
||||
|
||||
/* \\SOFTWARE\\Microsoft\\Window NT\\CurrentVersion
|
||||
/* \\SOFTWARE\\Microsoft\\Windows NT\\CurrentVersion
|
||||
* CurrentVersion
|
||||
* CurrentBuildNumber
|
||||
* CurrentType
|
||||
|
@ -248,7 +248,7 @@ static char* _wine_read_USTRING( char *buf, LPWSTR *str )
|
|||
s++;
|
||||
if (!*s) {
|
||||
/* Dangling \ ... may only happen if a registry
|
||||
* write was short. FIXME: What do to?
|
||||
* write was short. FIXME: What to do?
|
||||
*/
|
||||
break;
|
||||
}
|
||||
|
@ -1435,7 +1435,8 @@ void SHELL_LoadRegistry( void )
|
|||
REGISTRY_Init();
|
||||
SetLoadLevel(0);
|
||||
|
||||
if (RegCreateKeyA(HKEY_USERS, ".Default", &hkey_users_default)) hkey_users_default = 0;
|
||||
if (RegCreateKeyA(HKEY_USERS, ".Default", &hkey_users_default))
|
||||
hkey_users_default = 0;
|
||||
|
||||
GetWindowsDirectoryA( windir, MAX_PATHNAME_LEN );
|
||||
|
||||
|
@ -1577,7 +1578,7 @@ void SHELL_LoadRegistry( void )
|
|||
_wine_loadreg( HKEY_USERS, SAVE_USERS_DEFAULT );
|
||||
|
||||
/*
|
||||
* Load the global machine defaults directly form sysconfdir
|
||||
* Load the global machine defaults directly from sysconfdir
|
||||
*/
|
||||
_wine_loadreg( HKEY_LOCAL_MACHINE, SAVE_LOCAL_MACHINE_DEFAULT );
|
||||
}
|
||||
|
|
|
@ -144,8 +144,8 @@ static LPVOID _loadthunk(LPCSTR module, LPCSTR func, LPCSTR module32,
|
|||
if ( !(ordinal = NE_GetOrdinal(hmod, func))
|
||||
|| !(TD16 = PTR_SEG_TO_LIN(NE_GetEntryPointEx(hmod, ordinal, FALSE))))
|
||||
{
|
||||
ERR("(%s, %s, %s): Unable to find '%s'\n",
|
||||
module, func, module32, func);
|
||||
ERR("Unable to find thunk data '%s' in %s, required by %s (conflicting/incorrect DLL versions !?).\n",
|
||||
func, module, module32);
|
||||
return 0;
|
||||
}
|
||||
|
||||
|
@ -552,7 +552,7 @@ void WINAPI FT_Exit56(CONTEXT86 *context) { FT_Exit(context, 56); }
|
|||
* 00: DWORD length ? don't know exactly
|
||||
* 04: SEGPTR ptr ? where does it point to?
|
||||
* The pointer ptr is written into the first DWORD of 'thunk'.
|
||||
* (probably correct implemented)
|
||||
* (probably correctly implemented)
|
||||
* [ok probably]
|
||||
* RETURNS
|
||||
* segmented pointer to thunk?
|
||||
|
|
|
@ -814,7 +814,7 @@ HDRVR16 WINAPI OpenDriver16(LPCSTR lpDriverName, LPCSTR lpSectionName, LPARAM lP
|
|||
hDriver = DRIVER_TryOpenDriver16(drvName, lParam, FALSE);
|
||||
}
|
||||
if (!hDriver)
|
||||
ERR("Failed to open driver %s from section %s\n", lpDriverName, lpSectionName);
|
||||
ERR("Failed to open driver %s from system.ini file, section %s\n", lpDriverName, lpSectionName);
|
||||
else
|
||||
TRACE("=> %08x\n", hDriver);
|
||||
return hDriver;
|
||||
|
|
|
@ -1971,7 +1971,7 @@ DWORD WINAPI MsgWaitForMultipleObjects( DWORD nCount, HANDLE *pHandles,
|
|||
/*
|
||||
* This is a temporary solution to a big problem.
|
||||
* You see, the main thread of all Win32 programs is created as a 16 bit
|
||||
* task. This means that if you want on an event using Win32 synchronization
|
||||
* task. This means that if you wait on an event using Win32 synchronization
|
||||
* methods, the 16 bit scheduler is stopped and things might just stop happening.
|
||||
* This implements a semi-busy loop that checks the handles to wait on and
|
||||
* also the message queue. When either one is ready, the wait function returns.
|
||||
|
|
Loading…
Reference in New Issue