Assorted spelling fixes.
This commit is contained in:
Francois Gouget
Alexandre Julliard
parent
a2b2456b99
commit
02c25a8981
|
|
@ -590,7 +590,7 @@ static BOOL fci_flushfolder_copy_cfdata(HFCI hfci, char* buffer, UINT cbReserveC
|
|||
read_result=pcfdata->cbData;
|
||||
/* Modify the size of the compressed data to store only a part of the */
|
||||
/* data block into the current cabinet. This is done to prevent */
|
||||
/* that the maximum cabinet size will be exceeded. The remainer */
|
||||
/* that the maximum cabinet size will be exceeded. The remainder */
|
||||
/* will be stored into the next following cabinet. */
|
||||
|
||||
/* The cabinet will be of size "p_fci_internal->oldCCAB.cb". */
|
||||
|
|
@ -678,7 +678,7 @@ static BOOL fci_flushfolder_copy_cfdata(HFCI hfci, char* buffer, UINT cbReserveC
|
|||
p_fci_internal->statusFolderCopied += pcfdata->cbData;
|
||||
(*payload)+=pcfdata->cbUncomp;
|
||||
/* if cabinet size too large and data has been split */
|
||||
/* write the remainer of the data block to the new CFDATA1 file */
|
||||
/* write the remainder of the data block to the new CFDATA1 file */
|
||||
if( split_block ) { /* This does not include the */
|
||||
/* abused one (just search for "abused" )*/
|
||||
/* copy all CFDATA structures from handleCFDATA1 to handleCFDATA1new */
|
||||
|
|
@ -687,7 +687,7 @@ static BOOL fci_flushfolder_copy_cfdata(HFCI hfci, char* buffer, UINT cbReserveC
|
|||
return FALSE;
|
||||
}
|
||||
|
||||
/* set cbData the size of the remainer of the data block */
|
||||
/* set cbData to the size of the remainder of the data block */
|
||||
pcfdata->cbData = read_result - pcfdata->cbData;
|
||||
/*recover former value of cfdata.cbData; read_result will be the offset*/
|
||||
read_result -= pcfdata->cbData;
|
||||
|
|
@ -704,7 +704,7 @@ static BOOL fci_flushfolder_copy_cfdata(HFCI hfci, char* buffer, UINT cbReserveC
|
|||
/* TODO write error */
|
||||
return FALSE;
|
||||
}
|
||||
/* TODO error handling of err dont forget PFCI_FREE(hfci, reserved) */
|
||||
/* TODO error handling of err don't forget PFCI_FREE(hfci, reserved) */
|
||||
|
||||
*psizeFileCFDATA1new += sizeof(CFDATA)+cbReserveCFData;
|
||||
|
||||
|
|
@ -723,7 +723,7 @@ static BOOL fci_flushfolder_copy_cfdata(HFCI hfci, char* buffer, UINT cbReserveC
|
|||
|
||||
*psizeFileCFDATA1new += pcfdata->cbData;
|
||||
/* the two blocks of the split data block have been written */
|
||||
/* dont reset split_data yet, because it is still needed see below */
|
||||
/* don't reset split_data yet, because it is still needed see below */
|
||||
}
|
||||
|
||||
/* report status with pfnfcis about copied size of folder */
|
||||
|
|
@ -768,7 +768,7 @@ static BOOL fci_flushfolder_copy_cfdata(HFCI hfci, char* buffer, UINT cbReserveC
|
|||
/* TODO read error */
|
||||
return FALSE;
|
||||
}
|
||||
/* TODO error handling of err dont forget PFCI_FREE(hfci, reserved) */
|
||||
/* TODO error handling of err don't forget PFCI_FREE(hfci, reserved) */
|
||||
|
||||
/* write cfdata with checksum to handleCFDATA1new */
|
||||
if( PFCI_WRITE(hfci, handleCFDATA1new, /* file handle */
|
||||
|
|
@ -778,7 +778,7 @@ static BOOL fci_flushfolder_copy_cfdata(HFCI hfci, char* buffer, UINT cbReserveC
|
|||
/* TODO write error */
|
||||
return FALSE;
|
||||
}
|
||||
/* TODO error handling of err dont forget PFCI_FREE(hfci, reserved) */
|
||||
/* TODO error handling of err don't forget PFCI_FREE(hfci, reserved) */
|
||||
|
||||
*psizeFileCFDATA1new += sizeof(CFDATA)+cbReserveCFData;
|
||||
|
||||
|
|
@ -826,7 +826,7 @@ static BOOL fci_flushfolder_copy_cffolder(HFCI hfci, int* err, UINT cbReserveCFF
|
|||
/* absolute offset cannot be set yet, because the size of cabinet header, */
|
||||
/* the number of CFFOLDERs and the number of CFFILEs may change. */
|
||||
/* Instead the size of all previous data blocks will be stored and */
|
||||
/* the remainer of the offset will be added when the cabinet will be */
|
||||
/* the remainder of the offset will be added when the cabinet will be */
|
||||
/* flushed to disk. */
|
||||
/* This is exactly the way the original CABINET.DLL works!!! */
|
||||
cffolder.coffCabStart=sizeFileCFDATA2old;
|
||||
|
|
|
|||
|
|
@ -621,7 +621,7 @@ HRESULT WINAPI D3D8CB_CreateAdditionalSwapChain(IUnknown *device,
|
|||
*pPresentationParameters->BackBufferFormat = localParameters.BackBufferFormat;
|
||||
*pPresentationParameters->BackBufferCount = localParameters.BackBufferCount;
|
||||
*pPresentationParameters->MultiSampleType = localParameters.MultiSampleType;
|
||||
/* *pPresentationParameters->MultiSampleQuality leave alone incase wineD3D set something internally */
|
||||
/* *pPresentationParameters->MultiSampleQuality leave alone in case wined3d set something internally */
|
||||
*pPresentationParameters->SwapEffect = localParameters.SwapEffect;
|
||||
*pPresentationParameters->hDeviceWindow = localParameters.hDeviceWindow;
|
||||
*pPresentationParameters->Windowed = localParameters.Windowed;
|
||||
|
|
@ -629,7 +629,7 @@ HRESULT WINAPI D3D8CB_CreateAdditionalSwapChain(IUnknown *device,
|
|||
*pPresentationParameters->AutoDepthStencilFormat = localParameters.AutoDepthStencilFormat;
|
||||
*pPresentationParameters->Flags = localParameters.Flags;
|
||||
*pPresentationParameters->FullScreen_RefreshRateInHz = localParameters.FullScreen_RefreshRateInHz;
|
||||
/* *pPresentationParameters->PresentationInterval leave alone incase wineD3D set something internally */
|
||||
/* *pPresentationParameters->PresentationInterval leave alone in case wined3d set something internally */
|
||||
|
||||
return res;
|
||||
}
|
||||
|
|
|
|||
|
|
@ -57,7 +57,7 @@
|
|||
*
|
||||
* - ORPC is RPC for OLE; once we have a working RPC framework, we can
|
||||
* use it to implement out-of-process OLE client/server communications.
|
||||
* ATM there is maybe a disconnect between the marshalling in the OLE DLL's
|
||||
* ATM there is maybe a disconnect between the marshalling in the OLE DLLs
|
||||
* and the marshalling going on here [TODO: well, is there or not?]
|
||||
*
|
||||
* - In-source API Documentation, at least for those functions which we have
|
||||
|
|
|
|||
|
|
@ -139,7 +139,7 @@ BOOL WINAPI SHAboutInfoW(LPWSTR,DWORD);
|
|||
The reason for these functions to be there is to provide a wrapper
|
||||
for unicode functions to provide these functions on systems without
|
||||
unicode functions eg. win95/win98. Since we have such functions we just
|
||||
call these. If running Wine with native DLL's, some late bound calls may
|
||||
call these. If running Wine with native DLLs, some late bound calls may
|
||||
fail. However, it is better to implement the functions in the forward DLL
|
||||
and recommend the builtin rather than reimplementing the calls here!
|
||||
*/
|
||||
|
|
|
|||
|
|
@ -3140,8 +3140,8 @@ HRESULT WINAPI IWineD3DDeviceImpl_GetRenderState(IWineD3DDevice *iface, D3DRENDE
|
|||
HRESULT WINAPI IWineD3DDeviceImpl_SetSamplerState(IWineD3DDevice *iface, DWORD Sampler, WINED3DSAMPLERSTATETYPE Type, DWORD Value){
|
||||
IWineD3DDeviceImpl *This = (IWineD3DDeviceImpl *)iface;
|
||||
/**
|
||||
* SetSampler is designed to allow for more than the standard upto 8 textures
|
||||
* and Geforce has stopped suporting more than 6 standards texture in openGL,
|
||||
* SetSampler is designed to allow for more than the standard up to 8 textures
|
||||
* and Geforce has stopped supporting more than 6 standard textures in openGL.
|
||||
* So I have to use ARB for Gforce. (maybe if the sampler > 4 then use ARB?)
|
||||
*
|
||||
* http://developer.nvidia.com/object/General_FAQ.html#t6
|
||||
|
|
|
|||
|
|
@ -1292,7 +1292,7 @@ HRESULT WINAPI IWineD3DImpl_GetDeviceCaps(IWineD3D *iface, UINT Adapter, D3DDEVT
|
|||
if (This->dxVersion > 8) {
|
||||
*pCaps->TextureCaps |= D3DPTEXTURECAPS_NONPOW2CONDITIONAL;
|
||||
|
||||
} else { /* NONPOW2 isn't accessable by d3d8 yet */
|
||||
} else { /* NONPOW2 isn't accessible by d3d8 yet */
|
||||
*pCaps->TextureCaps |= D3DPTEXTURECAPS_POW2;
|
||||
}
|
||||
|
||||
|
|
|
|||
|
|
@ -792,7 +792,7 @@ typedef struct IWineD3DSwapChainImpl
|
|||
GLXContext glCtx;
|
||||
XVisualInfo *visInfo;
|
||||
GLXContext render_ctx;
|
||||
/* This has been left in device for now, but needs moving off into a rendertarget mamangement class and seperated out from swapchains and devices. */
|
||||
/* This has been left in device for now, but needs moving off into a rendertarget management class and separated out from swapchains and devices. */
|
||||
Drawable drawable;
|
||||
} IWineD3DSwapChainImpl;
|
||||
|
||||
|
|
|
|||
|
|
@ -188,7 +188,7 @@ WINE COMPONENTS
|
|||
- progman : A Program Manager replacement.
|
||||
- regedit : A graphical tool to edit your registry or for
|
||||
importing a windows registry to Wine.
|
||||
- regsvr32 : A program to register/unregister .DLL's and .OCX files.
|
||||
- regsvr32 : A program to register/unregister .DLL and .OCX files.
|
||||
Only works on those dlls that can self-register.
|
||||
- taskmgr : A clone of the windows taskmgr, used for debugging and
|
||||
managing running Windows and Winlib processes.
|
||||
|
|
|
|||
|
|
@ -5,21 +5,21 @@ Background
|
|||
----------
|
||||
|
||||
Most of the functions available in Windows, and in Windows applications, are
|
||||
made available to applications from DLL's. Wine implements the Win32 API by
|
||||
providing replacement's for the essential Windows DLL's in the form of Unix
|
||||
made available to applications from DLLs. Wine implements the Win32 API by
|
||||
providing replacements for the essential Windows DLLs in the form of Unix
|
||||
shared library (.so) files, and provides a tool, winebuild, to allow Winelib
|
||||
applications to link to functions exported from shared libraries/DLL's.
|
||||
applications to link to functions exported from shared libraries/DLLs.
|
||||
|
||||
The first thing to note is that there are many DLL's that aren't yet
|
||||
The first thing to note is that there are many DLLs that aren't yet
|
||||
implemented in Wine. Mostly this doesn't present a problem because the native
|
||||
Win32 versions of lots of DLL's can be used without problems, at least on
|
||||
Win32 versions of lots of DLLs can be used without problems, at least on
|
||||
x86 platforms. However, one of Wine's goals is the eventual replacement of
|
||||
every essential O/S DLL so that the whole API is implemented. This not only
|
||||
means that a copy of the real O/S is not needed, but also that non-x86
|
||||
platforms can run most Win32 programs after recompiling.
|
||||
|
||||
The second thing to note is that applications commonly use their own or 3rd
|
||||
party DLL's to provide functionality. In order to call these functions with
|
||||
party DLLs to provide functionality. In order to call these functions with
|
||||
a Winelib program, some 'glue' is needed. This 'glue' comes in the form of
|
||||
a .spec file. The .spec file, along with some dummy code, is used to create
|
||||
a Wine .so corresponding to the Windows DLL. The winebuild program can then
|
||||
|
|
@ -32,7 +32,7 @@ Wine to use the .so version instead [1].
|
|||
These two factors mean that if you are:
|
||||
|
||||
A: Reimplementing a Win32 DLL for use within Wine, or
|
||||
B: Compiling a Win32 application with Winelib that uses x86 DLL's
|
||||
B: Compiling a Win32 application with Winelib that uses x86 DLLs
|
||||
|
||||
Then you will need to create a .spec file (amongst other things). If you
|
||||
won't be doing either of the above, then you won't need winedump.
|
||||
|
|
@ -54,7 +54,7 @@ Usage
|
|||
Winedump is a command line tool. For the list of options and the basic usage
|
||||
see the the winedump(1) man page.
|
||||
|
||||
Spec mode: Generating stub DLL's
|
||||
Spec mode: Generating stub DLLs
|
||||
-------------------------------
|
||||
|
||||
If all you want to do is generate a stub DLL to allow you to link your
|
||||
|
|
@ -75,7 +75,7 @@ Export 2 - '_UnZipFile' ... [Ignoring]
|
|||
...
|
||||
|
||||
"[Ignoring]" Just tells you that winedump isn't trying to determine the
|
||||
parameters or return types of the functions, its just creating stubs.
|
||||
parameters or return types of the functions, it's just creating stubs.
|
||||
|
||||
The following files are created:
|
||||
|
||||
|
|
@ -103,7 +103,7 @@ will not be part of Wine, or you don't wish to build it this way,
|
|||
you should look at the Wine tool 'winemaker' to generate a DLL project.
|
||||
|
||||
FIXME: winemaker could run this tool automatically when generating projects
|
||||
that use extra DLL's (*.lib in the "ADD LINK32" line in .dsp) ....
|
||||
that use extra DLLs (*.lib in the "ADD LINK32" line in .dsp) ....
|
||||
|
||||
zipextra_install
|
||||
A shell script for adding zipextra to the Wine source tree (see below).
|
||||
|
|
@ -135,7 +135,7 @@ If you have problems with this step, you can post to the wine-devel mailing
|
|||
list for help. The build process can change regularly and winebuild may lag
|
||||
behind in support.
|
||||
|
||||
NOTE: **DO NOT** submit patches to Wine for 3rd party DLL's! Building DLL's
|
||||
NOTE: **DO NOT** submit patches to Wine for 3rd party DLLs! Building DLLs
|
||||
into your copy of the tree is just a simple way for you to link. When
|
||||
you release your application you won't be distributing the Unix .so
|
||||
anyway, just the Win32 DLL. As you update your version of Wine
|
||||
|
|
@ -314,7 +314,7 @@ Spec mode: Problems compiling a DLL containing generated code
|
|||
|
||||
Unless you are very lucky, you will need to do a small amount of work to
|
||||
get a DLL generated with -c, -t or -f to compile. The reason for this is
|
||||
that most DLL's will use custom types such as structs whose definition
|
||||
that most DLLs will use custom types such as structs whose definition
|
||||
is not known to the code in the DLL.
|
||||
|
||||
Heres an example prototype from crtdll:
|
||||
|
|
@ -329,8 +329,8 @@ compiling the function in order to be compatible with the native DLL. (In
|
|||
general this is not an issue, but you need to be aware of such issues if you
|
||||
encounter problems with your forwarding DLL).
|
||||
|
||||
For third party (non C++) DLL's, the header(s) supplied with the DLL can
|
||||
normally be added as an include to the generated DLL header. For other DLL's
|
||||
For third party (non C++) DLLs, the header(s) supplied with the DLL can
|
||||
normally be added as an include to the generated DLL header. For other DLLs
|
||||
I suggest creating a separate header in the DLL directory and adding any
|
||||
needed types to that. This allows you to rebuild the DLL at whim, for example
|
||||
if a new version of winedump brings increased functionality, then you
|
||||
|
|
|
|||
|
|
@ -26,9 +26,9 @@
|
|||
* relies on Patrik Stridvall's 'function_grep.pl' script to work.
|
||||
*
|
||||
* http://msdn.microsoft.com/library/periodic/period96/msj/S330.htm
|
||||
* This article provides both a description and freely downloadble
|
||||
* This article provides both a description and freely downloadable
|
||||
* implementation, in source code form, of how to extract symbols
|
||||
* from Win32 PE executables/DLL's.
|
||||
* from Win32 PE executables/DLLs.
|
||||
*
|
||||
* http://www.kegel.com/mangle.html
|
||||
* Gives information on the name mangling scheme used by MS compilers,
|
||||
|
|
|
|||
|
|
@ -15,7 +15,7 @@ is a Wine tool which aims to help:
|
|||
.nf
|
||||
A: Reimplementing a Win32 DLL for use within Wine, or
|
||||
.nf
|
||||
B: Compiling a Win32 application with Winelib that uses x86 DLL's
|
||||
B: Compiling a Win32 application with Winelib that uses x86 DLLs
|
||||
.PP
|
||||
For both tasks in order to be able to link to the Win functions some
|
||||
glue code is needed. This 'glue' comes in the form of a \fI.spec\fR file.
|
||||
|
|
@ -47,7 +47,7 @@ Basic usage help is printed.
|
|||
.IP \fBdump\fR
|
||||
To dump the contents of a PE file.
|
||||
.IP \fBspec\fR
|
||||
For generating .spec files and stub DLL's.
|
||||
For generating .spec files and stub DLLs.
|
||||
.IP \fBsym\fR
|
||||
Symbol mode.
|
||||
Used to demangle C++ symbols.
|
||||
|
|
@ -85,7 +85,7 @@ into a file, since a lot of output will be produced.
|
|||
Use dll for input file and generate implementation code.
|
||||
.IP "\fB-I \fIdir\fR"
|
||||
Look for prototypes in '\fIdir\fR' (implies \fB-c\fR). In the case of
|
||||
Windows DLL's, this could be either the standard include
|
||||
Windows DLLs, this could be either the standard include
|
||||
directory from your compiler, or a SDK include directory.
|
||||
If you have a text document with prototypes (such as
|
||||
documentation) that can be used also, however you may need
|
||||
|
|
|
|||
Loading…
Reference in New Issue