something I intend working on that will help make wine "more complete"
Basicly, I am going to compare what functions WINE exports from different dlls, say, kernel32.dll or whatever with what Windows XP SP1 exports from the same dll. If there is anything "missing" from the WINE version, then it needs to be added (even if its just a "fixme" stub) Would such work be any use? Has this work already been dome by someone?
Le mer 16/07/2003 à 10:00, Jonathan Wilson a écrit :
Basicly, I am going to compare what functions WINE exports from different dlls, say, kernel32.dll or whatever with what Windows XP SP1 exports from the same dll. If there is anything "missing" from the WINE version, then it needs to be added (even if its just a "fixme" stub)
Would such work be any use? Has this work already been dome by someone?
If you don't have a program which crashes because of unimplemented API (ie, tries to call 0xdeadbeef), I'm not sure it's worth it to just stub the rest of the functions. Some stubs are adequate substitutes for a real implementation, while others will make the application behave strangely. It'll be difficult to discriminate between bad and don't care stubs, while an unimplemented function is easy to come by and then decide if only a stub is enough or not. Vincent
On Wed, 16 Jul 2003, Jonathan Wilson wrote:
Basicly, I am going to compare what functions WINE exports from different dlls, say, kernel32.dll or whatever with what Windows XP SP1 exports from the same dll. If there is anything "missing" from the WINE version, then it needs to be added (even if its just a "fixme" stub)
Would such work be any use?
IMHO the more complete our spec files the better. Even if we just add stubs.
Has this work already been dome by someone?
I have some pieces of it. In particular I have a list of all APIs exported by Windows dlls, documented in the latest Win32 SDK and missing from Wine's spec files. It would be nice to declare them as stubs in the spec files and to add them to Wine's headers whenever possible. It's that much less work to do when someone later implements them. advapi32: CreatePrivateObjectSecurityWithMultipleInheritance CreateWellKnownSid CredDeleteA CredDeleteW CredEnumerateA CredEnumerateW CredFree CredGetSessionTypes CredGetTargetInfoA CredGetTargetInfoW CredIsMarshaledCredentialA CredIsMarshaledCredentialW CredMarshalCredentialA CredMarshalCredentialW CredReadA CredReadDomainCredentialsA CredReadDomainCredentialsW CredReadW CredRenameA CredRenameW CredUnmarshalCredentialA CredUnmarshalCredentialW CredWriteA CredWriteDomainCredentialsA CredWriteDomainCredentialsW CredWriteW EnumerateTraceGuids EqualDomainSid FlushTraceA FlushTraceW FreeInheritedFromArray GetInheritanceSourceA GetInheritanceSourceW GetLocalManagedApplicationData GetManagedApplicationCategories GetWindowsAccountDomainSid IsTokenUntrusted IsWellKnownSid LogonUserExA LogonUserExW LsaLookupNames2 LsaQueryForestTrustInformation LsaSetForestTrustInformation MSChapSrvChangePassword MSChapSrvChangePassword2 QueryTraceA QueryTraceW RegSaveKeyExA RegSaveKeyExW SaferCloseLevel SaferComputeTokenFromLevel SaferCreateLevel SaferGetLevelInformation SaferGetPolicyInformation SaferIdentifyLevel SaferRecordEventLogEntry SaferSetLevelInformation SaferSetPolicyInformation SaferiIsExecutableFileType StopTraceA StopTraceW SystemFunction040 SystemFunction041 TraceMessage TraceMessageVa TreeResetNamedSecurityInfoA TreeResetNamedSecurityInfoW UpdateTraceA UpdateTraceW Wow64Win32ApiEntry crypt32: CertCreateCTLEntryFromCertificateContextProperties CertIsValidCRLForCertificate CertSetCertificateContextPropertiesFromCTLEntry CryptBinaryToStringA CryptBinaryToStringW CryptSIPRetrieveSubjectGuidForCatalogFile CryptStringToBinaryA CryptStringToBinaryW dplayx: DllRegisterServer DllUnregisterServer imagehlp: FindFileInPath SymEnumSourceFiles SymEnumSym SymEnumSymbols SymEnumTypes SymFindFileInPath SymFromAddr SymFromName SymGetTypeFromName SymGetTypeInfo SymMatchString SymSetContext kernel32: ActivateActCtx AddRefActCtx AddVectoredExceptionHandler AllocateUserPhysicalPages AssignProcessToJobObject AttachConsole BindIoCompletionCallback CancelTimerQueueTimer ConvertFiberToThread CopyLZFile CreateActCtxA CreateActCtxW CreateFiberEx CreateHardLinkA CreateHardLinkW CreateJobObjectA CreateJobObjectW CreateJobSet CreateMemoryResourceNotification CreateTimerQueue CreateTimerQueueTimer DeactivateActCtx DebugActiveProcessStop DebugBreakProcess DebugSetProcessKillOnExit DeleteTimerQueue DeleteTimerQueueEx DeleteTimerQueueTimer DeleteVolumeMountPointA DeleteVolumeMountPointW DnsHostnameToComputerNameA DnsHostnameToComputerNameW FindActCtxSectionGuid FindActCtxSectionStringA FindActCtxSectionStringW GetConsoleProcessList GetConsoleSelectionInfo GetCurrentActCtx GetExpandedNameA GetExpandedNameW GetFirmwareEnvironmentVariableA GetFirmwareEnvironmentVariableW GetModuleHandleExA GetModuleHandleExW GetNativeSystemInfo GetNumaAvailableMemoryNode GetNumaHighestNodeNumber GetNumaNodeProcessorMask GetNumaProcessorNode GetSystemWow64DirectoryA GetSystemWow64DirectoryW GetVolumePathNamesForVolumeNameA GetVolumePathNamesForVolumeNameW HeapQueryInformation HeapSetInformation InitializeSListHead InterlockedFlushSList InterlockedPopEntrySList InterlockedPushEntrySList IsProcessInJob IsWow64Process LZClose LZCopy LZDone LZInit LZOpenFileA LZOpenFileW LZRead LZSeek LZStart QueryActCtxW QueryDepthSList QueryMemoryResourceNotification ReleaseActCtx RemoveVectoredExceptionHandler RestoreLastError RtlCaptureContext SetFileShortNameA SetFileShortNameW SetFileValidData SetFirmwareEnvironmentVariableA SetFirmwareEnvironmentVariableW TzSpecificLocalTimeToSystemTime WTSGetActiveConsoleSessionId ZombifyActCtx netapi32: DsGetDcCloseW DsGetDcNextA DsGetDcNextW DsGetDcOpenA DsGetDcOpenW DsGetForestTrustInformationW DsMergeForestTrustInformationW NetAddAlternateComputerName NetEnumerateComputerNames NetRemoveAlternateComputerName NetSetPrimaryComputerName ntdll: RtlApplicationVerifierStop RtlCaptureContext RtlFirstEntrySList RtlInitializeSListHead RtlInterlockedFlushSList RtlInterlockedPopEntrySList RtlInterlockedPushEntrySList RtlQueryDepthSList RtlQueryHeapInformation RtlSetHeapInformation _vsnwprintf ole32: CoFreeUnusedLibrariesEx CoGetContextToken CoGetInterceptor CoGetInterceptorFromTypeInfo CoInvalidateRemoteMachineBindings oleaut32: VarBoolFromI8 VarBoolFromUI8 VarBstrFromI8 VarBstrFromUI8 VarCyFromI8 VarCyFromUI8 VarCyMulI8 VarDateFromI8 VarDateFromUI8 VarDecFromI8 VarDecFromUI8 VarI1FromI8 VarI1FromUI8 VarI2FromI8 VarI2FromUI8 VarI4FromI8 VarI4FromUI8 VarI8FromBool VarI8FromCy VarI8FromDate VarI8FromDec VarI8FromDisp VarI8FromI1 VarI8FromI2 VarI8FromR4 VarI8FromR8 VarI8FromStr VarI8FromUI1 VarI8FromUI2 VarI8FromUI4 VarI8FromUI8 VarR4FromI8 VarR4FromUI8 VarR8FromI8 VarR8FromUI8 VarUI1FromI8 VarUI1FromUI8 VarUI2FromI8 VarUI2FromUI8 VarUI4FromI8 VarUI4FromUI8 VarUI8FromBool VarUI8FromCy VarUI8FromDate VarUI8FromDec VarUI8FromDisp VarUI8FromI1 VarUI8FromI2 VarUI8FromI8 VarUI8FromR4 VarUI8FromR8 VarUI8FromStr VarUI8FromUI1 VarUI8FromUI2 VarUI8FromUI4 psapi: EnumPageFilesA EnumPageFilesW GetPerformanceInfo GetProcessImageFileNameA GetProcessImageFileNameW rasapi32: RasDeleteSubEntryW rpcrt4: I_RpcBindingHandleToAsyncHandle I_RpcBindingInqLocalClientPID I_RpcExceptionFilter I_RpcNegotiateTransferSyntax I_RpcServerInqLocalConnAddress I_RpcTurnOnEEInfoPropagation NdrCreateServerInterfaceFromStub NdrPartialIgnoreClientBufferSize NdrPartialIgnoreClientMarshall NdrPartialIgnoreServerInitialize NdrPartialIgnoreServerUnmarshall RpcErrorAddRecord RpcErrorClearInformation RpcErrorEndEnumeration RpcErrorGetNextRecord RpcErrorGetNumberOfRecords RpcErrorLoadErrorInfo RpcErrorResetEnumeration RpcErrorSaveErrorInfo RpcErrorStartEnumeration RpcFreeAuthorizationContext RpcGetAuthorizationContextForClient RpcServerInqCallAttributesA RpcServerInqCallAttributesW RpcServerUnregisterIfEx RpcSsContextLockExclusive RpcSsContextLockShared RpcUserFree setupapi: CM_Get_DevNode_Custom_PropertyA CM_Get_DevNode_Custom_PropertyW CM_Get_DevNode_Custom_Property_ExA CM_Get_DevNode_Custom_Property_ExW CM_Is_Version_Available CM_Is_Version_Available_Ex SetupDiGetActualSectionToInstallExA SetupDiGetActualSectionToInstallExW SetupDiGetClassRegistryPropertyA SetupDiGetClassRegistryPropertyW SetupDiGetCustomDevicePropertyA SetupDiGetCustomDevicePropertyW SetupDiSetClassRegistryPropertyA SetupDiSetClassRegistryPropertyW SetupDiSetDeviceInterfaceDefault SetupEnumInfSectionsA SetupEnumInfSectionsW SetupGetFileCompressionInfoExA SetupGetFileCompressionInfoExW SetupGetFileQueueCount SetupGetFileQueueFlags SetupGetNonInteractiveMode SetupPrepareQueueForRestoreA SetupPrepareQueueForRestoreW SetupSetFileQueueFlags SetupSetNonInteractiveMode SetupUninstallNewlyCopiedInfs SetupUninstallOEMInfA SetupUninstallOEMInfW SetupVerifyInfFileA SetupVerifyInfFileW shdocvw: DoPrivacyDlg ImportPrivacySettings shell32: SHCreateQueryCancelAutoPlayMoniker SHCreateShellItem SHEnableServiceObject SHEnumerateUnreadMailAccountsW SHGetFolderPathAndSubDirA SHGetFolderPathAndSubDirW SHGetUnreadMailCountW SHParseDisplayName SHSetLocalizedName SHSetUnreadMailCountW urlmon: CompareSecurityIds user32: BroadcastSystemMessageExA BroadcastSystemMessageExW DefRawInputProc DisableProcessWindowsGhosting GetLayeredWindowAttributes GetRawInputBuffer GetRawInputData GetRawInputDeviceInfoA GetRawInputDeviceInfoW GetRawInputDeviceList GetRegisteredRawInputDevices GetWindowRgnBox IsGUIThread IsWinEventHookInstalled PrintWindow RegisterRawInputDevices wininet: CreateMD5SSOHash InternetClearAllPerSiteCookieDecisions InternetEnumPerSiteCookieDecisionA InternetEnumPerSiteCookieDecisionW InternetGetCookieExA InternetGetCookieExW InternetGetPerSiteCookieDecisionA InternetGetPerSiteCookieDecisionW InternetSetCookieExA InternetSetCookieExW InternetSetPerSiteCookieDecisionA InternetSetPerSiteCookieDecisionW PrivacyGetZonePreferenceW PrivacySetZonePreferenceW wintrust: CryptCATAdminPauseServiceForBackup CryptCATAdminRemoveCatalog CryptCATAdminResolveCatalogPath ws2_32: WSANSPIoctl WSCUpdateProvider freeaddrinfo getaddrinfo getnameinfo -- Francois Gouget fgouget(a)free.fr http://fgouget.free.fr/ If it stinks, it's chemistry. If it moves, it's biology. If it does not work, It's computer science.
Francois Gouget <fgouget(a)free.fr> writes:
IMHO the more complete our spec files the better. Even if we just add stubs.
In many cases apps will check for a function existence and call it if it exists, so adding a stub can actually break things compared to not having the function at all. If you want to add all these stubs then I'd suggest commenting them out until they either get implemented, or we find an app that really needs the entry point. -- Alexandre Julliard julliard(a)winehq.com
Sorry for just jumping in here but that sounds good to me, at least that way we know that they are in the code.. One thing I may be able to do relatively soon is go thru and test apps that use those functions when they exist and uncomment them to see if it makes things better or worse, or if they just stay the same. Not totally sure tho --- Alexandre Julliard <julliard(a)winehq.org> wrote:
Francois Gouget <fgouget(a)free.fr> writes:
IMHO the more complete our spec files the better. Even if we just add stubs.
In many cases apps will check for a function existence and call it if it exists, so adding a stub can actually break things compared to not having the function at all. If you want to add all these stubs then I'd suggest commenting them out until they either get implemented, or we find an app that really needs the entry point.
-- Alexandre Julliard julliard(a)winehq.com
===== -- Dustin Navea Minor Contributor, winehq.com Buzilla Janitor, bugs.winehq.com Network Admin, irc.blynk.net (down) __________________________________ Do you Yahoo!? SBC Yahoo! DSL - Now only $29.95 per month! http://sbc.yahoo.com
On Sun, 20 Jul 2003, Alexandre Julliard wrote:
Francois Gouget <fgouget(a)free.fr> writes:
IMHO the more complete our spec files the better. Even if we just add stubs.
In many cases apps will check for a function existence and call it if it exists, so adding a stub can actually break things compared to not having the function at all. If you want to add all these stubs then I'd suggest commenting them out until they either get implemented, or we find an app that really needs the entry point.
We already have a lot of stubs in the spec files. Does it mean we should comment them out? Of course, that too could break applications. IMHO we should add all the stubs we want and comment out only those that are confirmed to cause an application to crash. And preferably after trying to implement the stub which is of course the best solution. -- Francois Gouget fgouget(a)free.fr http://fgouget.free.fr/ A black hole is just God dividing by zero.
Le dim 20/07/2003 à 14:47, Francois Gouget a écrit :
On Sun, 20 Jul 2003, Alexandre Julliard wrote:
Francois Gouget <fgouget(a)free.fr> writes:
IMHO the more complete our spec files the better. Even if we just add stubs.
In many cases apps will check for a function existence and call it if it exists, so adding a stub can actually break things compared to not having the function at all. If you want to add all these stubs then I'd suggest commenting them out until they either get implemented, or we find an app that really needs the entry point.
We already have a lot of stubs in the spec files. Does it mean we should comment them out? Of course, that too could break applications.
I don't see how it could break an application to remove it (comment it out). If it's only a stub in the spec file, it's calling address is 0xdeadbeef, and any call to it will crash the app. If the app doesn't crash with the stub in, it means it doesn't use it at all.
IMHO we should add all the stubs we want and comment out only those that are confirmed to cause an application to crash. And preferably after trying to implement the stub which is of course the best solution.
The preferable solution is to not have any stub left, either in the spec file or an actual useful implementation. Short from that, limit application crashing because of spec stubs. But then we'll never (easily) know which applications try to use those stubs, and there'll be less pressure to implement them. Would we need 2 kind of Wine releases, one with spec stubs (to find out what could be interesting to implement) and one without any (to allow a maximum of apps to run)? Vincent
Francois Gouget <fgouget(a)free.fr> writes:
We already have a lot of stubs in the spec files. Does it mean we should comment them out? Of course, that too could break applications.
For functions that exist in all versions of Windows, clearly there's no point in commenting them out since apps won't have fallbacks. But for functions that have been added recently it's usually better to leave them commented out until they are needed; and in fact that's how it's done already in some of the spec files.
IMHO we should add all the stubs we want and comment out only those that are confirmed to cause an application to crash. And preferably after trying to implement the stub which is of course the best solution.
There is little difference between a stub and a commented out entry point, so there's no real reason to add stubs unless an app requires the entry point (in which case we'll get an error message). Adding stubs for everything will only cause more crashes without improving other apps. -- Alexandre Julliard julliard(a)winehq.com
participants (5)
-
Alexandre Julliard -
Dustin Navea -
Francois Gouget -
Jonathan Wilson -
Vincent Béron