Lots of spelling fixes that accumulated in my tree again, made several

error msgs more verbose, doc updates.
This commit is contained in:
Andreas Mohr 2000-06-01 23:28:25 +00:00 committed by Alexandre Julliard
parent 0d18aad17a
commit 2e011a5243
15 changed files with 37 additions and 35 deletions

View File

@ -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.
*

View File

@ -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;
}

View File

@ -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' */

View File

@ -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

View File

@ -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.

View File

@ -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);

View File

@ -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;
}

View File

@ -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:

View File

@ -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

View File

@ -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

View File

@ -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

View File

@ -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 );
}

View File

@ -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?

View File

@ -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;

View File

@ -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.