- Wine-Devel - list.winehq.org

Re: "Unhandled exception: floating point stack check" early in program?
by Petr Tesarik March 31, 2006

March 31, 2006

Hi, I'm not online too often. :( So, I thought the patch for Linux must already be in CVS. It is not. The patch can be found here: http://www.winehq.org/pipermail/wine-patches/2006-March/025228.html However, the patch only works for Linux. Please, let me know if you're using a different platform, as it is very likely that it can be made to work too, but I won't send patches which I can't test. To the wine-devel list: Why was the patch rejected, anyway? Petr Tesarik On 03/29/06 at 09:35:04 (-0800), Dan Kegel wrote: > On 3/29/06, Petr Tesarik <hat(a)tesarici.cz> wrote: > > No, this is not normal. This problem was introduced on the i386 > > architecture, when floating point registers were added to winedbg. > > Currently, there are two pending patches by me, one which fixes the > > problem on Linux, and another which fixes it on all platforms but is > > most likely wrong. > >... > > Anyway, see also my next email. > > Looking forward to it. > Can you give me the URL of the i386 patche in the wine-patches archive? > Thanks, > Dan >

1 0

[PATCH] Don't enforce process handle access rights in Win98 mode (fixes dcom98 ncalrpc)
by Mike Hearn March 31, 2006

March 31, 2006

Sending here until wine-patches stops eating my email. IMHO this would best be done in get_obj_from_handle in the server, but this approach is what the registry APIs do and what Rob suggested, so here it is. diff --git a/dlls/kernel/process.c b/dlls/kernel/process.c index 4263a22..d5017c4 100644 --- a/dlls/kernel/process.c +++ b/dlls/kernel/process.c @@ -2265,6 +2265,8 @@ HANDLE WINAPI OpenProcess( DWORD access, attr.SecurityQualityOfService = NULL; attr.ObjectName = NULL; + if (GetVersion() & 0x80000000) access = PROCESS_ALL_ACCESS; + status = NtOpenProcess(&handle, access, &attr, &cid); if (status != STATUS_SUCCESS) {

1 0

winspool: [1/2] implement EnumMonitorsW
by Detlef Riekenberg March 31, 2006

March 31, 2006

Our Tests will work, when both Patches are in the Tree Changelog: - winspool: implement EnumMonitorsW -- By By ... ... Detlef

1 0

Re: [WIDL] Implement support for unique strings
by Robert Shearman March 31, 2006

March 31, 2006

Eric Kohl wrote: > Robert Shearman wrote: > >>> case PASS_OUT: >>> + if (in_attr && has_size && pointer_type == RPC_FC_UP && >>> phase == PHASE_FREE) >>> + break; >>> if (!out_attr) >>> continue; >>> break; >>> >>> >> >> I don't think this is correct. Firstly, it should continue, not >> break. Secondly, I think it only doesn't need to free the string if >> it has a size. I'm pretty sure it shouldn't depend on being a unique >> string. >> > > Robert, > this is exactly what I want! WIDL must generate a call to > NdrPointerFree for 'in', 'unique', sized pointers to strings. Other > 'in' pointers don't need to be freed. > > Why? Because three different versions of MIDL do it this way. > Counter-example with the following IDL: void ConformantString2Out([in] long size, [in, out, string, size_is(size)] char **pszString); void Test([in] long size, [in, out, size_is(size)] char **pszArray); Both generate NdrPointerFree calls and I believe both are satisfied by the test you introduced: void __RPC_STUB Tests_ConformantString2Out( PRPC_MESSAGE _pRpcMessage ) { MIDL_STUB_MESSAGE _StubMsg; unsigned char **pszString; long size; RPC_STATUS _Status; ((void)(_Status)); NdrServerInitializeNew( _pRpcMessage, &_StubMsg, &Tests_StubDesc); size = 0; ( unsigned char ** )pszString = 0; RpcTryFinally { RpcTryExcept { if ( (_pRpcMessage->DataRepresentation & 0X0000FFFFUL) != NDR_LOCAL_DATA_REPRESENTATION ) NdrConvert( (PMIDL_STUB_MESSAGE) &_StubMsg, (PFORMAT_STRING) &__MIDL_ProcFormatString.Format[44] ); _StubMsg.Buffer = (unsigned char *)(((long)_StubMsg.Buffer + 3) & ~ 0x3); if(_StubMsg.Buffer + 4 > _StubMsg.BufferEnd) { RpcRaiseException(RPC_X_BAD_STUB_DATA); } size = *(( long * )_StubMsg.Buffer)++; NdrConformantArrayUnmarshall( (PMIDL_STUB_MESSAGE) &_StubMsg, (unsigned char * *)&pszString, (PFORMAT_STRING) &__MIDL_TypeFormatString.Format[44], (unsigned char)0 ); if(_StubMsg.Buffer > _StubMsg.BufferEnd) { RpcRaiseException(RPC_X_BAD_STUB_DATA); } } RpcExcept( RPC_BAD_STUB_DATA_EXCEPTION_FILTER ) { RpcRaiseException(RPC_X_BAD_STUB_DATA); } RpcEndExcept ConformantString2Out(size,pszString); _StubMsg.BufferLength = 0; _StubMsg.MaxCount = ( unsigned long )size; NdrConformantArrayBufferSize( (PMIDL_STUB_MESSAGE) &_StubMsg, (unsigned char *)pszString, (PFORMAT_STRING) &__MIDL_TypeFormatString.Format[44] ); _pRpcMessage->BufferLength = _StubMsg.BufferLength; _Status = I_RpcGetBuffer( _pRpcMessage ); if ( _Status ) RpcRaiseException( _Status ); _StubMsg.Buffer = (unsigned char *) _pRpcMessage->Buffer; _StubMsg.MaxCount = ( unsigned long )size; NdrConformantArrayMarshall( (PMIDL_STUB_MESSAGE)& _StubMsg, (unsigned char *)pszString, (PFORMAT_STRING) &__MIDL_TypeFormatString.Format[44] ); } RpcFinally { _StubMsg.MaxCount = ( unsigned long )size; NdrPointerFree( &_StubMsg, (unsigned char *)pszString, &__MIDL_TypeFormatString.Format[40] ); } RpcEndFinally _pRpcMessage->BufferLength = (unsigned int)(_StubMsg.Buffer - (unsigned char *)_pRpcMessage->Buffer); } void __RPC_STUB Tests_Test( PRPC_MESSAGE _pRpcMessage ) { MIDL_STUB_MESSAGE _StubMsg; unsigned char **pszArray; long size; RPC_STATUS _Status; ((void)(_Status)); NdrServerInitializeNew( _pRpcMessage, &_StubMsg, &Tests_StubDesc); size = 0; ( unsigned char ** )pszArray = 0; RpcTryFinally { RpcTryExcept { if ( (_pRpcMessage->DataRepresentation & 0X0000FFFFUL) != NDR_LOCAL_DATA_REPRESENTATION ) NdrConvert( (PMIDL_STUB_MESSAGE) &_StubMsg, (PFORMAT_STRING) &__MIDL_ProcFormatString.Format[52] ); _StubMsg.Buffer = (unsigned char *)(((long)_StubMsg.Buffer + 3) & ~ 0x3); if(_StubMsg.Buffer + 4 > _StubMsg.BufferEnd) { RpcRaiseException(RPC_X_BAD_STUB_DATA); } size = *(( long * )_StubMsg.Buffer)++; NdrConformantArrayUnmarshall( (PMIDL_STUB_MESSAGE) &_StubMsg, (unsigned char * *)&pszArray, (PFORMAT_STRING) &__MIDL_TypeFormatString.Format[78], (unsigned char)0 ); if(_StubMsg.Buffer > _StubMsg.BufferEnd) { RpcRaiseException(RPC_X_BAD_STUB_DATA); } } RpcExcept( RPC_BAD_STUB_DATA_EXCEPTION_FILTER ) { RpcRaiseException(RPC_X_BAD_STUB_DATA); } RpcEndExcept Test(size,pszArray); _StubMsg.BufferLength = 0; _StubMsg.MaxCount = ( unsigned long )size; NdrConformantArrayBufferSize( (PMIDL_STUB_MESSAGE) &_StubMsg, (unsigned char *)pszArray, (PFORMAT_STRING) &__MIDL_TypeFormatString.Format[78] ); _pRpcMessage->BufferLength = _StubMsg.BufferLength; _Status = I_RpcGetBuffer( _pRpcMessage ); if ( _Status ) RpcRaiseException( _Status ); _StubMsg.Buffer = (unsigned char *) _pRpcMessage->Buffer; _StubMsg.MaxCount = ( unsigned long )size; NdrConformantArrayMarshall( (PMIDL_STUB_MESSAGE)& _StubMsg, (unsigned char *)pszArray, (PFORMAT_STRING) &__MIDL_TypeFormatString.Format[78] ); } RpcFinally { _StubMsg.MaxCount = ( unsigned long )size; NdrPointerFree( &_StubMsg, (unsigned char *)pszArray, &__MIDL_TypeFormatString.Format[74] ); } RpcEndFinally _pRpcMessage->BufferLength = (unsigned int)(_StubMsg.Buffer - (unsigned char *)_pRpcMessage->Buffer); } -- Rob Shearman

2 1

Re: advpack: Implement LaunchINFSectionEx [resend]
by Alexandre Julliard March 31, 2006

March 31, 2006

"James Hawkins" <truiken(a)gmail.com> writes: > +static LPWSTR get_parameter(LPWSTR parameters, WCHAR separator, DWORD index) > +{ > + LPWSTR param = NULL, ptr = parameters; > + DWORD i = 0; > + > + while (*parameters && i < index) > + { > + if (*parameters == separator) > + { > + ptr = parameters; > + i++; > + } > + > + parameters++; > + } > + > + if (!*parameters || *parameters == separator) > + return NULL; > + > + param = HeapAlloc(GetProcessHeap(), 0, (parameters - ptr) * sizeof(WCHAR)); > + lstrcpynW(param, parameters, parameters - ptr); > + > + return param; > +} That's a very inefficient way of splitting a string. It's much better to allocate a copy of the whole string and go through it just once, inserting nulls to separate the tokens. -- Alexandre Julliard julliard(a)winehq.org

1 0

advpack: The Plan
by James Hawkins March 31, 2006

March 31, 2006

Hey, As you've probably noticed, I've been working on implementing advpack for a couple months now; a lot of progress has been made, and I'm glad to say that the end is in sight. The rest of this email details the game plan for finishing advpack. advpack has five main install functions: DoInfInstall, ExecuteCab, LaunchINFSection, LaunchINFSectionEx, and RunSetupCommand. They all basically do the same thing with minor differences in functionality. ExecuteCab extracts the files to install from a cab archive, LaunchINFSectionEx provides backup and rollback capability, and RunSetupCommand can also launch executables. When installing an INF section, advpack calls setupapi to install the base INF commands, such as CopyFiles and AddReg. After this, advpack parses the Advanced INF for advanced commands that are only installable when using advpack. These commands include: Values: RequiredEngine - Use either setupapi or setupx, we will ignore it. CustomDestination - assigns ldids to extra directories. SmartReboot - same reboot options as LaunchINFSection. Cleanup - deletes the INF when the install/uninstall is finished if this is 1. CheckAdminRights - check if the user is admin if this is 1. Actions: RegisterOCXs UnregisterOCXs BeginPrompt EndPrompt RunPreSetupCommands RunPostSetupCommands DelDirs PerUserInstall Backup/Rollback: ComponentName ComponentVersion BackupReg PreRollBack BackupPath Internally, there will be three main install functions: install_init, which will open the INF, make sure it's legit, and other initializations, spapi_install, which will call setupapi to install the base INF commands, and adv_install, which will parse the install section and run the provided commands. Each advanced command will be implemented by a function of similar name, e.g., RegisterOCXs would be implemented by the function register_ocxs, etc. All the command functions will be in a hash map, the key being the command name, the value being a pointer to the function that implements the command. adv_install will use setupapi to parse the entries of the install section, calling the function returned by a query to the hash map. According to INF Web [1], some commands are run before others, so there will probably be three or four maps, the functions in the maps grouped according to the order in which the commands should be run. For example, RunPreSetupCommands is to be executed after the BeginPrompt command, so begin_prompt would be in the phase 1 map, and run_pre_setup_commands would be in the phase 2 map. We would call the parser like so: run_adv_commands("InstallSection", phase1_map); run_adv_commands("InstallSection", phase2_map); run_adv_commands("InstallSection", phase3_map); If a command in the install section is not in the map, we just ignore it. This is The Plan so far, so if anyone has any ideas or suggestions, I'd love to hear from you. Thanks, James Hawkins [1] http://www.winpack.org/petr/INF_web/

4 4

Very old Windows programs and Wine
by Segin March 31, 2006

March 31, 2006

I have come forth with a Windows program -- complete with source and binary -- designed for Windows 2.03 (as from the binary headers, i learned a bit about NE headers trying to hack Win9x 16-bit apps onto windows 3.1, i did manage to get Defrag to work that way) Case and point, would anyone like to take a look at what all Wine can do with the source (winelib) and the binary (admittedly designed for a 8086.)

1 0

Re: COMCTL32: Add comctl32 to the list of always builtin dlls.
by Vitaly Lipatov March 31, 2006

March 31, 2006

I do not agree with this patch. There is broken code in WINE's comctl32 realization (in treeview/listview code) and we need overrides builtin dll by native for get differences... В сообщении от 30 марта 2006 07:56 Mike McCormack написал(a): > --- > > dlls/ntdll/loadorder.c | 1 + > 1 files changed, 1 insertions(+), 0 deletions(-) -- Vitaly Lipatov, ALT Linux Team Russia, Saint-Petersburg, www.etersoft.ru

2 1

Why winetools is utterly useless, once and for all.
by Segin March 31, 2006

March 31, 2006

There is one reason, inarguable (if you reply to this you have a IQ of 0) as to why WineTools is useless: Most of the WineTools 'magic' is in it's ~/.wine/config file, which Wine no longer uses/acknoleges, thefore, WineTools is utterly useless and has no point in existing AT ALL, PERIOD.

14 25

Re: [WIDL] Implement support for unique strings
by Robert Shearman March 30, 2006

March 30, 2006

Eric Kohl wrote: > case PASS_OUT: >+ if (in_attr && has_size && pointer_type == RPC_FC_UP && phase == PHASE_FREE) >+ break; > if (!out_attr) > continue; > break; > > I don't think this is correct. Firstly, it should continue, not break. Secondly, I think it only doesn't need to free the string if it has a size. I'm pretty sure it shouldn't depend on being a unique string. -- Rob Shearman

1 0