wine-devel

wine-devel@winehq.org

2 participants
84471 discussions

Re: "Unhandled exception: floating point stack check" early in program?
by Petr Tesarik 31 Mar '06

31 Mar '06

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 31 Mar '06

31 Mar '06

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 31 Mar '06

31 Mar '06

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 31 Mar '06

31 Mar '06

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 31 Mar '06

31 Mar '06

"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 31 Mar '06

31 Mar '06

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 31 Mar '06

31 Mar '06

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 31 Mar '06

31 Mar '06

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 31 Mar '06

31 Mar '06

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 30 Mar '06

30 Mar '06

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

Need Help for IniFileMapping
by Detlef Riekenberg 30 Mar '06

30 Mar '06

Hi all. I need your Help to see, how IniFileMapping works on different NT-Versions. An updated kernel32_crosstest.exe, that prints a lot of informations and a detailed description is here: http://bugs.winehq.org/show_bug.cgi?id=4096 Thanks for your Help (IniFile is the redirection from "*.ini" - Files to the Registry, by GetPrivateProfileString() and Friends.) -- By By ... ... Detlef

1 0

OT: General behaviour of the community (from 'Why winetools is utterly useless, once and for all')
by Dr J A Gow 30 Mar '06

30 Mar '06

I was interested to read several comments on this list in respect of such comments as 'IQ of zero'. Such comments were the final straw in leading me to take this action. A few days ago I sent a comment to the list. Nothing really sinister, just an observation and an experience. Before long I had a particularly vicious and vile diatribe sent in reply to my comment - to my private email address. I have appended the lower headers and the bulk of the message I received at the end of this message (trimming the html from the bottom). I thought long and hard before taking this action. It is not something I would normally do, but in this instance I was so incensed at this individual's behaviour that I felt that 'naming and shaming' was the only way forward. Not even so much as to the fact that he directed his comments to me, but more the fact that had I been a new prospective developer, the effect such diatribe would have would not in any way be positive. It certainly would taint their perception of the open-source community. Furthermore I sincerely doubt that I am the only one to experience this behaviour. Others may just suffer in silence. I have worked with many smaller community projects, on OS/2 and latterly on Linux, and never been subjected to this kind of abuse from members of the community. I joined this list because I felt that there was something I could contribute to Wine, and in the instance it turned out that there was. I did not join it to receive unsolicited email of an abusive nature from members of the community. Had he done this by telephone I could have had him prosecuted, at least in the UK. But he hides behind a gmail.com address and makes comments I seriously suspect he would not have the balls to say to my face. No, I do not believe that we need a 'net police force'. Common decency between individuals, however, is essential. Diversity, discussion, criticism, expression, even annoyance are all valuable when driving a project forward. Blatant personal abuse is not tolerable. It is not tolerable in society, it should not be tolerated in the developer community. The community needs to police itself, rather than be policed, and individuals who bring the community into disrepute need to be dealt with by the community. That is why I bring this into the open. How to prevent such actions? I do not think it that this is possible in its entirety. I can (and have) simply add this individual's address to my blocked list. However, I may have been a newcomer to open-source development who would not have been so tolerant, and whose opinions of the community may have been changed by this action. May I suggest that whoever is responsible for the hosting of the mailing list change the configuration so that email addresses are not placed in the header? (I am no expert on mailing-list software but it does not immediately seem to be impractical.) That way all replies have to go to the list and this would prevent such unsolicited email being sent. This is my last word on this matter. Make of it what you will. I refuse to be prevented from contributing to vital projects such as Wine when I can by the antics of some depraved individual. It has left a sour taste in my mouth though, and like it or not, it does not portray Wine developers in a good light. ------------------------------------------------------------------------------- Disposition-Notification-To: Segin <segin2005(a)gmail.com> Date: Fri, 24 Mar 2006 15:01:11 -0500 From: Segin <segin2005(a)gmail.com> User-Agent: Mozilla Thunderbird 1.0.7 (X11/20051202) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Dr J A Gow <J.A.Gow(a)furrybubble.co.uk> Subject: Re: Winetools -> wine doors References: <1143192770.25116.22.camel(a)despair.kent-music.com> <442441D7.7020107(a)furrybubble.co.uk> In-Reply-To: <442441D7.7020107(a)furrybubble.co.uk> Content-Type: multipart/alternative; boundary="------------010900050103010506060607" X-BV-Spam-Score: 0.4 (/) X-Envelope-From: segin2005(a)gmail.com X-Virus-Scanned: by amavisd-new This is a multi-part message in MIME format. --------------010900050103010506060607 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Dr J A Gow wrote: > >> I've looked through the winetools code and it is a clusterf*ck of >> nonsense. It appears to be in the final stages of code rot, however > > > This "clusterf*ck of nonsense" helped me to get a microcontroller > development suite running under Wine, which otherwise would not install You're a fucking retard, RTFM! You'd learn you need to use DLLOverrides in Winecfg. > natively. After over ten years designing and developing embedded systems, > there is one thing that stands out. That you're a dumbfuck? > Code that is 'nonsense' does not work > at all. That's 100% definitive of Winetools. > Code that works may not be elegant, it may not be pretty and > you may hate the style, but it _works_ Nope, wine doesn't do ~/.wine/config, which makes winetools COMPLETELY useless. **WINETOOLS DOES NOT DO A DAMN REDEEMING THING FOR WINE USERS THAT ARE UP TO DATE!!!!** > and therefore it is not nonsense. Yes, it is. > This code works, is useful and serves a purpose. Just because you don't > like the way it is written does not make it nonsense. Language, please! > No IT DOES NOT! > John. > > So you're saying that you don't know how to use dlloverrides on winecfg, right? that's basically the same thing winetools does except that wine now ignores the config file (makine winetools utterly useless, 100%, no questions asked). please just install all the native DLLs that winetools installs, and set a dlloverride in winecfg of * (native, builtin) for your exe file. Please stop spouting your mis-infomation.

4 6

Re: advpack: Forward ExecuteCabA to its unicode counterpart
by Robert Shearman 30 Mar '06

30 Mar '06

James Hawkins wrote: >@@ -86,6 +87,43 @@ HRESULT WINAPI DoInfInstall(const SETUPC > > /*********************************************************************** > * ExecuteCabA (ADVPACK.@) >+ * >+ * See ExecuteCabW. >+ */ >+HRESULT WINAPI ExecuteCabA(HWND hwnd, CABINFOA* pCab, LPVOID pReserved) >+{ >+ UNICODE_STRING cab, inf, section; >+ CABINFOW cabinfo; >+ HRESULT hr; >+ >+ TRACE("(%p, %p, %p)\n", hwnd, pCab, pReserved); >+ >+ if (!pCab) >+ return E_INVALIDARG; >+ >+ RtlCreateUnicodeStringFromAsciiz(&cab, pCab->pszCab); > > pCab->pszCab can be NULL, right? I don't think RtlCreateUnicodeStringFromAsciiz handles that case in the way you expect. -- Rob Shearman

1 0

Re: Improper message recursion revealed by recent desktop window changes
by Jesse Allen 30 Mar '06

30 Mar '06

On 3/29/06, Troy Rollo <wine(a)troy.rollo.name> wrote: > The recent changes to the desktop have revealed a problem with recursive > processing of X messages. The problem started to manifest with commit > 1a4f6e579b6aab685fae2e649fd5accee7ec0b4f (7th March). A symptom is a stack > that looks like this: > > <application Window procedure> > WINPROC_wrapper > ... > CallWindowProcW > ... > SendMessageW > X11DRV_SetWindowPos > SetWindowPos > X11DRV_ConfigureNotify > process_events > X11DRV_MsgWaitForMultipleObjectsEx > wait_message_reply > send_inter_thread_message > SendMessageTimeoutW > SendMessageW > send_parent_notify > DestroyWindow > > In other words, a destroy notification is being sent to the parent window with > SendMessageW, and before that message returns an unrelated X message is > processed. Under Windows the equivalent could never happen - if a thread is > in SendMessage(), the only messages that can be delivered to it are ones sent > by SendMessage() from another thread. > > The consequences of this can be unpleasant if the code that processes (in this > case a window movement notification) the message interferes with state that > is being dealt with in earlier stack frames. Yep, that's why the launching of War3 seems to only paint explorer or the launch window depending on how I hacked wine. This is the problem exhibited in bugs 4948, 4897, and 4847. > > wait_message_reply calls X11DRV_MsgWaitForMultipleObjectsEx with: > > res = USER_Driver->pMsgWaitForMultipleObjectsEx( 1, &server_queue, > INFINITE, QS_ALLINPUT, 0 ); > > The brute-force approach of changing this to the following makes the > application work, but gives rise to some pack_message FIXMEs (for WM_NCPAINT > and WM_ERASEBKGND), and since this is an extremely sensitive piece of code to > change I thought it best left to people with more familiarity with it. > > -- > Troy Rollo - wine(a)troy.rollo.name > > > Last thing I did today was looking at the message passing and signal handling. The signal handling doesn't look any different than before. I figured something could be up with the message handling as it seemed one thread was stomping on another but I don't know anything about wineserver. I'll take a better look tomorrow! Jesse

1 0

Re: OT: General behaviour of the community (from 'Why winetools is utterly useless, once and for all')
by Hiji 30 Mar '06

30 Mar '06

> How do you propose we prevent people from emailing people that post to > wine-devel? How do we choose who gets to email people directly and > who doesn't? How do we filter the contents of their email? I want to chime in and say that I'm with Tom and the ole Doc here. I don't think there's any way to filter somebody's contents, but I think it's important for the community to speak up when somebody is out of line. I know I was the first to respond to Sergin's email by asking that he be more constructive in his feedback, but past that, none of the regulars on this thread said much. Now, his thread has spawned into something that is soooo far out there that it almost has no relevancy to this list. I want to note that I don't see how Sergin's comments and behavior could have been interpreted as anything but inappropriate; however, with the majority of people not saying anything, I can only imagine that Sergin felt that what he did was perfectly okay and acceptable on this list. I'm trying to say two things here: 1) If somebody says/ does something that is not okay, say something to that person. Of course, be constructive about it. For example, when I first joined this list, people got upset that I was top-posting - I learned that it was not ok in this community because people said someting. So, I try to bottom post (when I remember.) 2) I've always said Wine is an awesome thing - probably the best thing to come out of the Linux community since ... well, Linux and its desktops. Now, more than ever, Wine need as many developers as possible to keep it improve b/c as Linux adoption continues people will look to Wine and CrossOver for application cross-compatibility. And, I'm not talking about the developer who pops in with a patch every 6 months (I see that person as a patch submitter), but instead, I'm talking about a developer who dedicated him/herself to the Wine project. And with that, the team can't afford to lose that good talent b/c the "newbie talent" was mistreated in this community. Those are my 2 cents that I think will go a long way. Thanks, Hiji

3 3

Interesting D3D testapp
by Willie Sippel 30 Mar '06

30 Mar '06

Hi there. I think I just found a very nice D3D testapp: fr-025 by Farbrausch. A nice, small (8.2MB) graphics demo, already works somewhat with Wine (starts, plays, music and everything works, good performance), but lots and lots of effects are simply missing or wrong. It does quite a bit interesting stuff wined3d doesn't seem to handle: strange viewport handling, glow, blending, reflections, blur(?). So many unimplemented features I won't even dare to file bugreports for every single one... :) It's the all-time most popular demo on pouet.net (obviously, given it's called "fr-025 - the.popular.demo" ;) ) You can get it at: http://www.pouet.net/prod.php?which=9450 -- Willie Sippel //////// | Tritium Studios // | ______________________________ //// /// | http://www.tritium-studios.com <willie(a)froq.net>

1 0

Here is an RSS feed for front page of www.winehq.com
by Daniel Schwarz 29 Mar '06

29 Mar '06

I've long wondered why winehq.com does not provide an RSS feed. I've created one using the feed43.com sitescraping tool. Works well and it should be very low impact to your webserver (it only hits the URL at most once every 6 hours and caches the result for subsequent queries) Feel free to post this RSS link on the winehq homepage. http://feed43.com/winehq.xml Best Regards, Dan Schwarz

1 0

"Unhandled exception: floating point stack check" early in program?
by Dan Kegel 29 Mar '06

29 Mar '06

See the winedbg session below. Is it normal for winedbg to complain about floating point stuff when the program, run normally, doesn't? Using either 'cont' or 'pass' at this point just repeats the same message. Hints welcome. Thanks, Dan dank@lappy:~$ ~/wine/programs/winedbg/winedbg ~/.wine/drive_c/putty/putty.exe WineDbg starting on pid 0x42 start_process () at /home/dank/wine/dlls/kernel/process.c:845 0x7fcbd259 start_process+0xb9 [/home/dank/wine/dlls/kernel/process.c:845] in ker nel32: subl $12,%esp 845 ExitProcess( entry( peb ) ); Wine-dbg>c First chance exception: floating point stack check in 32-bit code (0x7f7a0d90). Register dump: CS:0073 SS:007b DS:007b ES:007b FS:1007 GS:0033 EIP:7f7a0d90 ESP:7fafea58 EBP:7fafea90 EFLAGS:00010246( - 00 -RIZP1) EAX:7fdc2400 EBX:7f7c00b0 ECX:00000000 EDX:7fdc2400 ESI:7fafeaac EDI:00000002 Stack dump: 0x7fafea58: 7fafeb40 0000ffff 7fafea90 7f7c00b0 0x7fafea68: 0000005c 0000007c 7fafea90 7f79e0c6 0x7fafea78: 7f7c8f40 7fd868e8 0000005c 7f34e09c 0x7fafea88: 63656a62 0000007c 7fafeac0 7f31a40f 0x7fafea98: 000002e4 7fafeaac 00000002 7fafeb40 0x7fafeaa8: 7fafeb78 00000000 00000000 00000007 0200: sel=1007 base=7fec2000 limit=00001fff 32-bit rw- Backtrace: =>1 0x7f7a0d90 LPtoDP+0x50(hdc=0x2e4, points=0x7fafeaac, count=0x2) [/home/dank/wine/dlls/gdi/mapping.c:132] in gdi32 (0x7f7a0d90) 2 0x7f31a40f X11DRV_XWStoDS+0x3f(physDev=0x7fdc2558, width=0x7) [/home/dank/wine/dlls/x11drv/graphics.c:307] in winex11 (0x7f31a40f) 3 0x7f33e89d X11DRV_XRender_SelectFont+0x5d(physDev=0x7fdc2558, hfont=0x7c) [/home/dank/wine/dlls/x11drv/xrender.c:554] in winex11 (0x7f33e89d) 4 0x7f3390e0 X11DRV_SelectFont+0xce0(physDev=0x7fdc2558, hfont=0x7c, gdiFont=0x7fdb7110) [/home/dank/wine/dlls/x11drv/xfont.c:3234] in winex11 (0x7f3390e0) 5 0x7f78c52f FONT_SelectObject+0x6f(handle=0x7c, obj=0x7fd868d8, hdc=0x2e4) [/home/dank/wine/dlls/gdi/font.c:587] in gdi32 (0x7f78c52f) 6 0x7f79fb20 SelectObject+0x70(hdc=0x2e4, hObj=0x7c) [/home/dank/wine/dlls/gdi/gdiobj.c:1168] in gdi32 (0x7f79fb20) 7 0x7f77e9f7 DC_InitDC+0x77(dc=0x7fdc2400) [/home/dank/wine/dlls/gdi/dc.c:204] in gdi32 (0x7f77e9f7) 8 0x7f7801e9 CreateDCW+0x129(driver=0x7f34146c, device=0x0, output=0x0, initData=0x0) [/home/dank/wine/dlls/gdi/dc.c:655] in gdi32 (0x7f7801e9) 9 0x7f304f27 X11DRV_GetDCEx+0x387(hwnd=0x10020, hrgnClip=0x0, flags=0x3) [/home/dank/wine/dlls/x11drv/dce.c:214] in winex11 (0x7f304f27) 10 0x7f86acaa GetDCEx+0x3a(hwnd=0x0, hrgnClip=0x0, flags=0x3) [/home/dank/wine/dlls/user/painting.c:476] in user32 (0x7f86acaa) 11 0x7f86ad6c GetDC+0x3c(hwnd=0x0) [/home/dank/wine/dlls/user/painting.c:490] in user32 (0x7f86ad6c) 12 0x7f82ed0a GetDialogBaseUnits+0x3a [/home/dank/wine/dlls/user/dialog.c:1411] in user32 (0x7f82ed0a) 13 0x7f830c8b DIALOG_CreateIndirect+0x2b(dlgTemplate=<register not in topmost frame>, dlgProc=0x4340e2, param=0x0, unicode=0x0, modal=0x0) [/home/dank/wine/dlls/user/dialog.c:474] in user32 (0x7f830c8b) 14 0x7f83254e CreateDialogIndirectParamAorW+0x2e(hInst=0x400000, dlgTemplate=0x46bcc0, owner=0x0, dlgProc=0x4340e2, param=0x0, flags=0x2) [/home/dank/wine/dlls/user/dialog.c:697] in user32 (0x7f83254e) 15 0x7f83264e CreateDialogIndirectParamA+0x2e(hInst=0x400000, dlgTemplate=0x46bcc0, owner=0x0, dlgProc=0x4340e2, param=0x0) [/home/dank/wine/dlls/user/dialog.c:706] in user32 (0x7f83264e) 16 0x7f8326c6 CreateDialogParamA+0x66(hInst=0x400000, name=0x6f, owner=0x0, dlgProc=0x4340e2, param=0x0) [/home/dank/wine/dlls/user/dialog.c:670] in user32 (0x7f8326c6) 17 0x00434801 in putty (+0x34801) (0x00434801) 18 0x442922a7 (0x442922a7) 19 0x00000000 (0x00000000) 20 0x00000000 (0x00000000) Wine-dbg> ? -- Wine for Windows ISVs: http://kegel.com/wine/isv

2 1

Re: server: Fix FPU registers in get_thread_context()
by Vitaliy Margolen 29 Mar '06

29 Mar '06

Monday, March 27, 2006, 12:51:03 AM, Petr Tesarik wrote: > Hi, > this patch fixes a bug in get_thread_context(). Currently, this > routine assumes that all registers except debug registers are saved in thread->>context if it exists. However, it does not include FPU > registers. > IMO, we should not blindly assume which registers are present in thread->>context but look at ContextFlags. > BTW I found this bug when winedbg stopped working with programs using > the FPU. > ChangeLog: > * Look at ContextFlags to see which registers are saved in > thread->context. Sorry this is not correct. Exception handler should get full context including FPU context. If we not saving it that's the problem on the other end. Vitaliy Margolen

2 2

Re: Alexandre Julliard : x11drv: Moved desktop mode handling to the explorer process.
by Tony Lambregts 29 Mar '06

29 Mar '06

Alexandre Julliard wrote: > Module: wine > Branch: refs/heads/master > Commit: db6608ac9f9bbc2ddd7f8bf201d1387d079dfd5f > URL: http://source.winehq.org/git/?p=wine.git;a=commit;h=db6608ac9f9bbc2ddd7f8bf… > > Author: Alexandre Julliard <julliard(a)winehq.org> > Date: Mon Mar 27 22:43:03 2006 +0200 > > x11drv: Moved desktop mode handling to the explorer process. > > Per-application desktop mode settings are no longer supported. Apps > can be launched in a specific desktop window by using: > > explorer /desktop=name[,widthxheight] app.exe [args] > > If the named desktop already exists the app is launched inside it. The > default desktop is cleverly named "default". > So if I understand this correctly all programs will share the same desktop. Is it also true that I cannot specify in winecfg that one program can run full screen and another in a desktop window. If this is the case we will have a fair amount of crying over this one. At the very least we need to put a note in winecfg. (preferabley befor next release). -- Tony Lambregts

12 23

Page fault xmlspy 2006 wine .9.10
by Grant Lewis 29 Mar '06

29 Mar '06

It's repeatable. I can launch the progam fine but when I click in certain parts of the gui I generate the page fault and the program dies. wine: Unhandled page fault on write access to 0x0000001f at address 0x7d62d6 (th read 0009), starting debugger... WineDbg starting on pid 0x8 First chance exception: page fault on read access to 0x00000000 in 32-bit code ( 0x7ffa7292). Register dump: CS:0073 SS:007b DS:007b ES:007b FS:003b GS:0033 EIP:7ffa7292 ESP:7fbfec74 EBP:7fbfed3c EFLAGS:00210246( - 00 -RIZP1) EAX:00000000 EBX:7ffd5280 ECX:00000000 EDX:00000000 ESI:0000001f EDI:00000002 Stack dump: 0x7fbfec74: 7fbfec90 00000001 00000000 00000c28 0x7fbfec84: 7fbff174 7ffa09d0 00000001 7ffd5280 0x7fbfec94: 0000001f 00000002 7fbfed3c 7fbfec74 0x7fbfeca4: 7ffa7283 00000001 80000000 00000000 0x7fbfecb4: 7ffa4dc9 7ffa406d 00000000 7ff9afea 0x7fbfecc4: 7ffd5280 7e1699a8 00000048 7ff9b0af Backtrace: =>1 0x7ffa7292 RtlImageNtHeader+0x72 in ntdll (0x7ffa7292) 2 0x7ffa757a RtlImageDirectoryEntryToData+0x3a in ntdll (0x7ffa757a) 3 0x7fc43dbf UnhandledExceptionFilter+0x4df in kernel32 (0x7fc43dbf) 4 0x7ffa0a65 __wine_exception_handler+0x95 in ntdll (0x7ffa0a65) 5 0x7ffbbb99 call_exception_handler+0x29 in ntdll (0x7ffbbb99) 6 0x7ffbbb6d EXC_CallHandler+0x1d in ntdll (0x7ffbbb6d) 7 0x7ffa040f in ntdll (+0x1040f) (0x7ffa040f) 8 0x7ffa059b __regs_RtlRaiseException+0x2b in ntdll (0x7ffa059b) 9 0x7ffbc2ac in ntdll (+0x2c2ac) (0x7ffbc2ac) 10 0xdeadbabe (0xdeadbabe) 11 0x00000000 (0x00000000) 0x7ffa7292 RtlImageNtHeader+0x72 in ntdll: cmpw $0x5a4d,0x0(%eax) Modules: Module Address Debug info Name (98 modules) PE 0x00400000-014eb000 Deferred xmlspy PE 0x10000000-1002e000 Deferred ssce5332 ELF 0x7bf00000-7bf03000 Deferred <wine-loader> ELF 0x7ed0b000-7ed20000 Deferred midimap<elf> \-PE 0x7ed10000-7ed20000 \ midimap ELF 0x7ee3e000-7ee5f000 Deferred msacm32<elf> \-PE 0x7ee50000-7ee5f000 \ msacm32 ELF 0x7ee5f000-7ee76000 Deferred msacm<elf> \-PE 0x7ee70000-7ee76000 \ msacm ELF 0x7ee76000-7ef4a000 Deferred libcrypto.so.0.9.7 ELF 0x7ef4a000-7ef72000 Deferred libssl.so.0.9.7 ELF 0x7ef72000-7ef8a000 Deferred libcups.so.2 ELF 0x7ef8c000-7efa0000 Deferred msimg32<elf> \-PE 0x7ef90000-7efa0000 \ msimg32 ELF 0x7f08e000-7f0bd000 Deferred uxtheme<elf> \-PE 0x7f0a0000-7f0bd000 \ uxtheme ELF 0x7f0bd000-7f0d5000 Deferred ximcp.so.2 ELF 0x7f0d5000-7f0d8000 Deferred xlcdef.so.2 ELF 0x7f0d8000-7f136000 Deferred libgl.so.1 ELF 0x7f14c000-7f1fb000 Deferred libx11.so.6 ELF 0x7f1fb000-7f26c000 Deferred winex11<elf> \-PE 0x7f210000-7f26c000 \ winex11 ELF 0x7f26c000-7f287000 Deferred libexpat.so.0 ELF 0x7f287000-7f2a9000 Deferred libfontconfig.so.1 ELF 0x7f2ab000-7f2bf000 Deferred libice.so.6 ELF 0x7f2bf000-7f321000 Deferred libfreetype.so.6 ELF 0x7f328000-7f330000 Deferred libxcursor.so.1.0.2 ELF 0x7f330000-7f337000 Deferred libxrender.so.1 ELF 0x7f337000-7f390000 Deferred msvcrt<elf> \-PE 0x7f350000-7f390000 \ msvcrt PE 0x7f390000-7f3cb000 Deferred oraclm32 ELF 0x7f3cf000-7f3da000 Deferred libxext.so.6 ELF 0x7f3da000-7f3f4000 Deferred imm32<elf> \-PE 0x7f3e0000-7f3f4000 \ imm32 ELF 0x7f3f4000-7f46d000 Deferred winmm<elf> \-PE 0x7f400000-7f46d000 \ winmm ELF 0x7f46d000-7f48d000 Deferred odbc32<elf> \-PE 0x7f480000-7f48d000 \ odbc32 ELF 0x7f48d000-7f4b2000 Deferred ws2_32<elf> \-PE 0x7f4a0000-7f4b2000 \ ws2_32 ELF 0x7f4b2000-7f4cb000 Deferred wsock32<elf> \-PE 0x7f4c0000-7f4cb000 \ wsock32 ELF 0x7f4cb000-7f4e7000 Deferred mpr<elf> \-PE 0x7f4d0000-7f4e7000 \ mpr ELF 0x7f4e7000-7f522000 Deferred wininet<elf> \-PE 0x7f4f0000-7f522000 \ wininet ELF 0x7f522000-7f541000 Deferred cabinet<elf> \-PE 0x7f530000-7f541000 \ cabinet ELF 0x7f541000-7f56d000 Deferred urlmon<elf> \-PE 0x7f550000-7f56d000 \ urlmon ELF 0x7f56d000-7f5e6000 Deferred oleaut32<elf> \-PE 0x7f580000-7f5e6000 \ oleaut32 ELF 0x7f5e6000-7f5fa000 Deferred olepro32<elf> \-PE 0x7f5f0000-7f5fa000 \ olepro32 ELF 0x7f5fa000-7f613000 Deferred oledlg<elf> \-PE 0x7f600000-7f613000 \ oledlg ELF 0x7f613000-7f639000 Deferred winspool<elf> \-PE 0x7f620000-7f639000 \ winspool ELF 0x7f639000-7f6d2000 Deferred comctl32<elf> \-PE 0x7f640000-7f6d2000 \ comctl32 ELF 0x7f6d2000-7f6ee000 Deferred iphlpapi<elf> \-PE 0x7f6e0000-7f6ee000 \ iphlpapi ELF 0x7f6ee000-7f729000 Deferred rpcrt4<elf> \-PE 0x7f700000-7f729000 \ rpcrt4 ELF 0x7f729000-7f79b000 Deferred ole32<elf> \-PE 0x7f740000-7f79b000 \ ole32 ELF 0x7f79b000-7f7e7000 Deferred shlwapi<elf> \-PE 0x7f7b0000-7f7e7000 \ shlwapi ELF 0x7f7e7000-7f896000 Deferred shell32<elf> \-PE 0x7f800000-7f896000 \ shell32 ELF 0x7f896000-7f92c000 Deferred comdlg32<elf> \-PE 0x7f8a0000-7f92c000 \ comdlg32 ELF 0x7f92c000-7f963000 Deferred advapi32<elf> \-PE 0x7f940000-7f963000 \ advapi32 ELF 0x7f963000-7f9e3000 Deferred gdi32<elf> \-PE 0x7f970000-7f9e3000 \ gdi32 ELF 0x7f9e3000-7faf0000 Deferred user32<elf> \-PE 0x7fa00000-7faf0000 \ user32 ELF 0x7fc01000-7fc05000 Deferred libxxf86vm.so.1 ELF 0x7fc05000-7fcf0000 Export kernel32<elf> \-PE 0x7fc20000-7fcf0000 \ kernel32 ELF 0x7fe01000-7fe06000 Deferred libxxf86dga.so.1 ELF 0x7fe06000-7fe10000 Deferred libnss_files.so.2 ELF 0x7fe10000-7fe1a000 Deferred libnss_nis.so.2 ELF 0x7fe1a000-7fe2f000 Deferred libnsl.so.1 ELF 0x7fe31000-7fe40000 Deferred libz.so.1 ELF 0x7fe42000-7fe45000 Deferred libxrandr.so.2 ELF 0x7fe45000-7fe68000 Deferred libm.so.6 ELF 0x7fe68000-7ff5e000 Deferred libwine_unicode.so.1 ELF 0x7ff5f000-7ff67000 Deferred libsm.so.6 ELF 0x7ff67000-7ff70000 Deferred libnss_compat.so.2 ELF 0x7ff74000-7ffe0000 Export ntdll<elf> \-PE 0x7ff90000-7ffe0000 \ ntdll ELF 0xb7dd9000-b7ddd000 Deferred libdl.so.2 ELF 0xb7ddd000-b7ef8000 Deferred libc.so.6 ELF 0xb7ef8000-b7f4a000 Deferred libpthread.so.0 ELF 0xb7f60000-b7f7a000 Deferred libwine.so.1 ELF 0xb7f7b000-b7f92000 Deferred ld-linux.so.2 Threads: process tid prio (all id:s are in hex) 00000008 (D) Z:\opt\Altova\XMLSpy2006\XMLSpy.exe 0000000f -1 0000000e 0 0000000d 0 0000000c 0 0000000a 0000000b 0 00000008 (D) Z:\opt\Altova\XMLSpy2006\XMLSpy.exe 00000009 0 <==

3 5

Re: advpack: Open the INF file if the RSC_FLAG_INF flag is specified
by Alexandre Julliard 29 Mar '06

29 Mar '06

"James Hawkins" <truiken(a)gmail.com> writes: > @@ -72,10 +72,7 @@ static void test_RunSetupCommand() > /* try to run an exe with the RSC_FLAG_INF flag */ > hexe = (HANDLE)0xdeadbeef; > hr = pRunSetupCommand(NULL, "winver.exe", "Install", "c:\\windows\\system32", "Title", &hexe, RSC_FLAG_INF, NULL); > - todo_wine > - { > - ok(hr == SPAPI_E_WRONG_INF_STYLE, "Expected SPAPI_E_WRONG_INF_STYLE, got %ld\n", hr); > - } > + ok(hr & SPAPI_E_EXPECTED_SECTION_NAME, "Expected a setupapi error, got %ld\n", hr); This test doesn't make sense. If you want to test certain bits you have to write that explicitly, not pick some random constant that happens to have the right value. And in any case a simple AND won't do what you want. -- Alexandre Julliard julliard(a)winehq.org

1 0

Debugging X errors?
by Dan Kegel 28 Mar '06

28 Mar '06

OK, I've had it. The X errors I'm running into are keeping me from getting work done. They might be due to bugs in my X server (ubuntu 05.10), but while I wait for the next release of ubuntu, maybe I could try to track them down anyway. It looks like the procedure for diagnosing X errors such as X Error of failed request: BadAtom (invalid Atom parameter) Major opcode of failed request: 17 (X_GetAtomName) Atom id in failed request: 0x0 Serial number of failed request: 468 Current serial number in output stream: 470 in Wine is to do WINEDEBUG=+synchronous export WINEDEBUG and then use winedbg to run the apps, and get a backtrace when the error occurs. I'll try that. - Dan -- Wine for Windows ISVs: http://kegel.com/wine/isv

4 4

Re: Russian translation for uninstall application
by Dmitry Timoshkov 28 Mar '06

28 Mar '06

"Anatoly A. Kazantsev" <jim-crow(a)rambler.ru> wrote: > + * Uninstaller (Russain Resources) Please fix the above typo and the translation of the word "registry" to match the commonly used russian word and resend the patch. -- Dmitry.

1 0

I have a complaint about the website
by Philip V. Neves 28 Mar '06

28 Mar '06

On the website there is an article that talks about homogenious populations being a threat to society and to the computer industry. Although I accept the fact that this is mostly true I believe that is a good argument for creating the Linux OS and other OS's not for creating wine. With the wine project you are bringing the homogenious population to the Linux community. So theoretically a virus could spread just as easily through a wine system as well as a Windows system. That virus could spread even if the security in Linux is in place. The wine installation could be affected and we have to reinstall the wine directory. I'd appreciate it if you guys would take that out of the website. I feel it hurts the credibility of your project by having it there. The fact is if a company has a wine installation they could have a large number of appications that could be affected by a virus. Wine running on a different system won't fix that. Although the security system in Linux could provide some security against accessing more vital parts of the system, the wine installation is still vulnerable due to the fact its implementing windows system calls. I have infact found viruses with Clam after installing wine. So I don't feel that this statement is true.

7 8

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

wine-devel