June 2006 - Wine-Devel - list.winehq.org

Re: riched20: corrected EM_GETLINE and wrong hWnd patches (combined into one)

by James Hawkins

On 6/30/06, James Hawkins <truiken(a)gmail.com> wrote: > On 6/30/06, Krzysztof Foltman <wdev(a)foltman.com> wrote: > > > > So, the current plan is to: > > - See if the "new Thomas patch" gets accepted during the nearest 2 weeks > > - If yes, rewrite the 1.0 fix and it send separately - it's totally > > incompatible with that patch > > - If not, resubmit the EM_GETLINE stuff, with proper credits this time, > > maybe as two separate patches (implementation and unit test) > > - Move EM_LINELENGTH fix and editor pointer check into separate patches > > (as soon as they're OK so I don't have to split them over and over) > > > > Does that sound reasonable? > > > > Yea that sounds good, though you should probably just wait a couple > days. If it doesn't get accepted before then, it was probably > dropped. > I meant to say, "wait a couple days instead of two weeks".

June 30, 2006

Re: riched20: corrected EM_GETLINE and wrong hWnd patches (combined into one)

by James Hawkins

On 6/30/06, Krzysztof Foltman <wdev(a)foltman.com> wrote: > > So, the current plan is to: > - See if the "new Thomas patch" gets accepted during the nearest 2 weeks > - If yes, rewrite the 1.0 fix and it send separately - it's totally > incompatible with that patch > - If not, resubmit the EM_GETLINE stuff, with proper credits this time, > maybe as two separate patches (implementation and unit test) > - Move EM_LINELENGTH fix and editor pointer check into separate patches > (as soon as they're OK so I don't have to split them over and over) > > Does that sound reasonable? > Yea that sounds good, though you should probably just wait a couple days. If it doesn't get accepted before then, it was probably dropped. -- James Hawkins

June 30, 2006

Link or rename wcmd.exe to cmd.exe?

by Thomas Kho

I'd like to restart this old thread <http://www.winehq.com/hypermail/wine-users/2005/05/index.html#165> which brings up the point that there are applications that hard-code cmd.exe and (sometimes intentionally) ignore COMSPEC. One example is Perl, which has the following comment in win32/win32.c: /* we don't use COMSPEC here for two reasons: * 1. the same reason perl on UNIX doesn't use SHELL--rampant and * uncontrolled unportability of the ensuing scripts. * 2. PERL5SHELL could be set to a shell that may not be fit for * interactive use (which is what most programs look in COMSPEC * for). */ I'm currently looking into what would be required for something like a symlink to wcmd.exe, but at the same time I'm wondering the historical reasons for choosing 'wcmd' and if it should be changed to just 'cmd'. Thomas Kho

June 30, 2006

Re: riched20: corrected EM_GETLINE and wrong hWnd patches (combined into one)

by Krzysztof Foltman

James Hawkins wrote: > this problem. The previous version you sent in did have his name, > which is perfectly legit, but this version doesn't. You can either > add his name as well as yours to the changelog, or ask him to resend > the tests separately. So, the current plan is to: - See if the "new Thomas patch" gets accepted during the nearest 2 weeks - If yes, rewrite the 1.0 fix and it send separately - it's totally incompatible with that patch - If not, resubmit the EM_GETLINE stuff, with proper credits this time, maybe as two separate patches (implementation and unit test) - Move EM_LINELENGTH fix and editor pointer check into separate patches (as soon as they're OK so I don't have to split them over and over) Does that sound reasonable? Krzysztof

June 30, 2006

Re: riched20: corrected EM_GETLINE and wrong hWnd patches (combined into one)

by James Hawkins

On 6/30/06, Krzysztof Foltman <wdev(a)foltman.com> wrote: > James Hawkins wrote: > > > I've just looked at this patch and the previous patch Thomas sent in, > > and saying that this is roughly based on his patch is putting it > > lightly. > > > > missing feature, but either way, he deserves credit for the code he > > wrote, and not just saying that your code was based off of his. > > He obviously does. The previous version of the patch (which I re-sent) > HAS his name as the sole author of the changes. > I'm not accusing you of intentionally ripping Thomas off, only that more credit is due than was given, and I gave possible solutions to this problem. The previous version you sent in did have his name, which is perfectly legit, but this version doesn't. You can either add his name as well as yours to the changelog, or ask him to resend the tests separately. -- James Hawkins

June 30, 2006

Re: riched20: corrected EM_GETLINE and wrong hWnd patches (combined into one)

by Krzysztof Foltman

James Hawkins wrote: > I've just looked at this patch and the previous patch Thomas sent in, > and saying that this is roughly based on his patch is putting it > lightly. The EM_GETLINE code is completely changed (I haven't even seen his "new" implementation - http://www.winehq.org/pipermail/wine-patches/2006-June/028096.html - before sending the patch in, and the old one was the one Alexandre wrote it needed fixing). Actually knowing about that patch would save me an hour or so of unnecessary work. The testing code is by Thomas and is completely unchanged, too. Yes, I should have emphasized that in the change log. But it wasn't meant to rip him off. > I see that you've added the 1.0 emulation change, but that > doesn't warrant you putting your name on his patch. I guess, let him decide about that. > then add your code in a new patch, or to make him aware of the > problems in his implementation, The fact is: - he sent the original patch long time ago, and he didn't fix the problems until very recently (because Alexandre only told us about the problem after I reminded him about his patch?) - the mail from Alexandre about the patch being wrong was explicitly addressed to me, so with lack of reaction from Thomas I assumed I should update the patch - "my" cleanup was created *independently* from the new (see above) patch from Thomas, and I'm not even sure which version I like more (the new version from Thomas is more compact, and multiplying nCopy by current character size may not be as patch-reject-prone as I initially thought, given Alexandre's stance about nBPC trick) - the cleanup involved removing lots of the original code and replacing it by my own (only in EM_GETLINE handler, not in the test code) - just compare the old vs "my" version; that's why I decided to add "roughly" - I think I have enough of "genuinely mine" and rather complex code in riched20 (like initial versions of style management, display, wrapper) to not be suspected of wanting to take credit for a loop doing (essentially) strcat and p=p->next, that I didn't code from scratch, at cost of Thomas :) > missing feature, but either way, he deserves credit for the code he > wrote, and not just saying that your code was based off of his. He obviously does. The previous version of the patch (which I re-sent) HAS his name as the sole author of the changes. Krzysztof

June 30, 2006

Re: [TOOLS] Re: Gecko installer

by Jacek Caban

Jeremy Newman wrote: > This is now live at: > http://source.winehq.org/winegecko.php > > On Sun, 2006-06-25 at 11:40 +0200, Jonathan Ernst wrote: > >> Le samedi 24 juin 2006 à 20:06 +0200, Jacek Caban a écrit : >> >>> Hi, >>> >>> >> [...] >> >>> - We need php script redirecting to SourceForge similar to one that >>> forwards to Mozilla ActiveX control. >>> >> Here you are. >> Thanks Jeremy and Jonathan. I'll send patches that will add the last missing part. Jacek

June 30, 2006

Re: [PATCH 10/11] server: add calls to get/set menu item info

by H. Verbeet

On 30/06/06, Thomas Kho <tkho(a)ucla.edu> wrote: > I'm not 100% clear what the problem is. My interpretation of your > first email was that there was a necessary distinction in type between > user/gdi handles as stored in the server, but now my understanding is > that you're concerned gdi objects in MENUITEM/MENUITEMINFO should not > be mutable by external processes. Is that right? The basic problem is that if you create a HBITMAP in one process, then pass the handle to another process, you can't read the contents of the bitmap in that other process. So suppose you create a menu item in one process and set a custom bitmap on the menu item. Should the menu then display correctly in another process if you pass it the menu handle? > I did some probing and was able to change the values of the four gdi > objects (MENUINFO.hbrBack, and bitmap, (un-)check bitmaps in > MENUITEMINFO) from an external process. Specifically, I changed the > brush to one returned by GetStockObject(WHITE_BRUSH), changed the > bitmap to one of the predefined handles, and set (un-)check bitmaps to > an invalid value that was correctly returned upon a GetMenuItemInfo > query. So, I think regardless of the scope of gdi objects, it's the > right behavior for the menu code to blindly set and get the gdi > handles. Stock objects are somewhat special, since they're not created / owned by the current process.

June 30, 2006

Re: riched20: corrected EM_GETLINE and wrong hWnd patches (combined into one)

by James Hawkins

On 6/30/06, Krzysztof Foltman <wdev(a)foltman.com> wrote: > ChangeLog: > * EM_GETLINE support (roughly based on code by Thomas Kho, although > there are important changes, for example, it works correctly in RichEdit > 1.0 emulation mode) (bug #4305) > * Workaround for wrong window handles (bug# 4452) > * EM_LINELENGTH handles paragraph ends properly (bug #5375) > > I'm sending it as one patch, just in case it gets rejected again - > trying to split the patch seems to give me some mysterious git problems. > I've just looked at this patch and the previous patch Thomas sent in, and saying that this is roughly based on his patch is putting it lightly. I see that you've added the 1.0 emulation change, but that doesn't warrant you putting your name on his patch. The correct way to go about this would be to wait till his patch gets accepted and then add your code in a new patch, or to make him aware of the problems in his implementation, so he can rewrite it or add the missing feature, but either way, he deserves credit for the code he wrote, and not just saying that your code was based off of his. -- James Hawkins

June 30, 2006

Re: [PATCH 10/11] server: add calls to get/set menu item info

by Thomas Kho

On 6/30/06, Robert Shearman <rob(a)codeweavers.com> wrote: > Thomas Kho wrote: > > > On 6/30/06, Robert Shearman <rob(a)codeweavers.com> wrote: > > > >> Thomas, can you regenerate this patch using "void *" for bmpitem (or > >> perhaps add a new gdi_handle_t type)? > > > > > > I'll add the gdi_handle_t type and resubmit two patches (I caught > > another use in the menu struct). > > > As others have said, GDI objects are not shared between processes. GDI > objects are DCs, regions, bitmaps, palettes, fonts, and brushes. I > assumed that they were shared, because icons are shared, but they are a > user32 object. > > You'll have to write a test to see whether Windows allows you to > retrieve and use the bitmap for a menu from another process. I'm not 100% clear what the problem is. My interpretation of your first email was that there was a necessary distinction in type between user/gdi handles as stored in the server, but now my understanding is that you're concerned gdi objects in MENUITEM/MENUITEMINFO should not be mutable by external processes. Is that right? I did some probing and was able to change the values of the four gdi objects (MENUINFO.hbrBack, and bitmap, (un-)check bitmaps in MENUITEMINFO) from an external process. Specifically, I changed the brush to one returned by GetStockObject(WHITE_BRUSH), changed the bitmap to one of the predefined handles, and set (un-)check bitmaps to an invalid value that was correctly returned upon a GetMenuItemInfo query. So, I think regardless of the scope of gdi objects, it's the right behavior for the menu code to blindly set and get the gdi handles. Tommy

June 30, 2006

Re: winspool.drv: Write-strings warnings fix

by Detlef Riekenberg

Andrew Talbot wrote: > Changelog: > winspool.drv: Write-strings warnings fix. The touched parts should call the UNICODE-Functions instead of the ANSI-Functions. That's on my ToDo-List, but after the Port-Functions are fixed. Many tests for the affected Functions also needs to come before the touched Parts will be updated again. I'm ok with this Patch. -- By By ... ... Detlef

June 30, 2006

Re: mapi32: Replace CRITICAL_SECTION by RTL_CRITICAL_SECTION.

by Robert Shearman

Hervé Poussineau wrote: >Replace CRITICAL_SECTION by RTL_CRITICAL_SECTION, according to prototype of >RtlEnterCriticalSection and others. > It would be better to fix the file to use the kernel32 critical section functions instead of the ntdll ones. -- Rob Shearman

June 30, 2006

Re: [PATCH 10/11] server: add calls to get/set menu item info

by Robert Shearman

Thomas Kho wrote: > On 6/30/06, Robert Shearman <rob(a)codeweavers.com> wrote: > >> Thomas, can you regenerate this patch using "void *" for bmpitem (or >> perhaps add a new gdi_handle_t type)? > > > I'll add the gdi_handle_t type and resubmit two patches (I caught > another use in the menu struct). As others have said, GDI objects are not shared between processes. GDI objects are DCs, regions, bitmaps, palettes, fonts, and brushes. I assumed that they were shared, because icons are shared, but they are a user32 object. You'll have to write a test to see whether Windows allows you to retrieve and use the bitmap for a menu from another process. -- Rob Shearman

June 30, 2006

Re: [PATCH 10/11] server: add calls to get/set menu item info

by Thomas Kho

On 6/30/06, Robert Shearman <rob(a)codeweavers.com> wrote: > Thomas, can you regenerate this patch using "void *" for bmpitem (or > perhaps add a new gdi_handle_t type)? I'll add the gdi_handle_t type and resubmit two patches (I caught another use in the menu struct). Tommy

June 30, 2006

Re: [AppDb] [Resend] prefix all GPC variables

by Chris Morgan

There are several issues that I've found so far in this patch. It appears that you used a search and replace. You'll need to go through EVERY line of the patch and undo the changes to things like sql queries and others where the changes don't make sense. At some point we can discuss altering tables to match our internal variable scheme but we should wait until the php part of the patch is complete. Chris On Friday 30 June 2006 3:31 am, Jonathan Ernst wrote: > Before you ask, there was no possibility to split this one up because > everything is interdependant. > > Please commit it before other patches, it's a pain to rediff it agains head > and fix the conflicts everytime. > > Changelog: > - rename all Get/Post/Cookies variables using type prefixes so that we can > later use the autofiltering function

June 30, 2006

Re: [AppDb] appsubmit fix

by Chris Morgan

Yeah, lets pass the parameters into this function so we can move it around and reuse it without needing a global. Chris On Friday 30 June 2006 7:24 am, Jonathan Ernst wrote: > Le jeudi 29 juin 2006 à 12:19 -0400, Chris Morgan a écrit : > > Can we pass the parameters we need into the function instead of using a > > global? > > I don't think it is better. If we just pass it it'll make a copy of the > array. We could also use &$aClean but I don't see why it would be better > too.

June 30, 2006

Re: Wine 0.9.16 and ddraw issues

by Christoph Frick

On Fri, Jun 30, 2006 at 05:11:24PM +0200, Alexander Nicolaysen Sørnes wrote: > ... > fixme:d3d:IWineD3DStateBlockImpl_Release Releasing primary stateblock > ... > fixme:d3d:IWineD3DStateBlockImpl_Release Releasing primary stateblock this are also the last words of Planescape Torment when starting up (black screen, then end right before the menu would appear) -- cu

June 30, 2006

Wine 0.9.16 and ddraw issues

by Alexander Nicolaysen Sørnes

Greetings, I maintain several ddraw apps in the Application Database. While most of the problems introduced by Wine 0.9.16 have been fixed, some still remain. Command & Conquer and C&C: Red Alert When exiting the game, a messagebox displays: 'Unregonized Direct Draw result code: 1' A demo of Red Alert is available here: http://appdb.winehq.org/appview.php?versionId=4026 These two games, along with 'Warlords IIII: Darklords Rising' also have a strange SMP problem. In earlier Wine versions, these games would stop redrawing at some point. This also happens in Wine 0.9.16, but sometimes an error message is displayed instead, and then Wine receives a page fault. Emperor: Battle for Dune This game requires native d3drm.dll, which does not work anymore. Problems with this file was mentioned on this list a few days ago. Heroes of Might and Magic IV This game now displays a File menu when run in full-screen, which it is only supposed to do when run in a window. If I change the game's resolution, the menu disappears, but if I change it back to the resolution it had when it was started, the File menu is displayed again. Because of this menu, the game window is moved downwards, so the bottom part of the game is not displayed. Warcraft II Battle.net Edition The title screen is no longer displayed; it shows a black screen instead. This also happens with some of the campaign intro screens. The rest of the game seems to work as before. The new ddraw code fixes redrawing problems in at least a dozen games, and makes some of them faster, so it was a very good thing! :) Regards, Alexander N. Sørnes

June 30, 2006

Re: [PATCH 10/11] server: add calls to get/set menu item info

by Dmitry Timoshkov

"Robert Shearman" <rob(a)codeweavers.com> wrote: > You can pass HBITMAPs between processes on Windows, although you are > correct in saying that they aren't user handles. Of course, passing > bitmap handles between processes on Wine won't work yet. Feng Yuan's book claims that while GDI handles are kernel objects Windows kernel doesn't allow them to work across process boundaries. My tests confirm that. -- Dmitry.

June 30, 2006

Re: Debugging string comparison problem

by Juan Lang

> I think the bug is here. Using SysAllocString instead of > SysAllocStringLen I get: > > VarBstrCmp returns 1 > CompareStringW returns 2 Using SysAllocString, I get that the length of each string is 0. So yeah, they'd be equal. So, I'm back to where I started: in Windows, these are different characters, but in Wine they're not. How do I fix it? --Juan

June 30, 2006

Re: Debugging string comparison problem

by Robert Shearman

Juan Lang wrote: >>You missed the two collation_table lookups. >> >> > >You're right, I did miss that. > > > >>Note that on Windows using CompareString on L"\0001\0002" and >>L"\0002\0001" gives a result of CSTR_EQUAL, so I don't think the bug is >>in the collation tables. >> >> > >Really? For which locale, and which version of Windows? For US English, >on WinXP, it returns CSTR_LESS_THAN for me. Here's a quick proggie: > > LCID lcid = MAKELCID(MAKELANGID(LANG_ENGLISH, SUBLANG_ENGLISH_US), > SORT_DEFAULT); > BSTR str1 = SysAllocStringLen(L"\0001\0002", 2); > BSTR str2 = SysAllocStringLen(L"\0002\0001", 2); > > I think the bug is here. Using SysAllocString instead of SysAllocStringLen I get: VarBstrCmp returns 1 CompareStringW returns 2 > printf("VarBstrCmp returns %ld\n", VarBstrCmp(str1, str2, lcid, 0)); > printf("CompareStringW returns %d\n", > CompareStringW(lcid, 0, str1, 2, str2, 2)); > >The output is: >VarBstrCmp returns 0 >CompareStringW returns 1 > -- Rob Shearman

June 30, 2006

Re: Debugging string comparison problem

by Juan Lang

> You missed the two collation_table lookups. You're right, I did miss that. > Note that on Windows using CompareString on L"\0001\0002" and > L"\0002\0001" gives a result of CSTR_EQUAL, so I don't think the bug is > in the collation tables. Really? For which locale, and which version of Windows? For US English, on WinXP, it returns CSTR_LESS_THAN for me. Here's a quick proggie: LCID lcid = MAKELCID(MAKELANGID(LANG_ENGLISH, SUBLANG_ENGLISH_US), SORT_DEFAULT); BSTR str1 = SysAllocStringLen(L"\0001\0002", 2); BSTR str2 = SysAllocStringLen(L"\0002\0001", 2); printf("VarBstrCmp returns %ld\n", VarBstrCmp(str1, str2, lcid, 0)); printf("CompareStringW returns %d\n", CompareStringW(lcid, 0, str1, 2, str2, 2)); The output is: VarBstrCmp returns 0 CompareStringW returns 1 --Juan

June 30, 2006

Re: [PATCH 10/11] server: add calls to get/set menu item info

by H. Verbeet

On 30/06/06, Robert Shearman <rob(a)codeweavers.com> wrote: > You can pass HBITMAPs between processes on Windows, Is there anything special you need to do to it for that to work? It doesn't seem to work very well for me, and any documentation I can find basically says that while GDI handles are unique between processes, only the process that created them can access them.

June 30, 2006

Using firefox with ietab extension

by Paul Vriens

Hi, anybody tried this already? I wanted to use Firefox 1.5.4 together with the ietab extension for some specific sites (Outlook Web Access). I don't want to install the Mozilla ActiveX plugin but instead us our internal stuff, but wasn't able yet to get this going. Installation of firefox and the extension is fine btw. Cheers, Paul.

June 30, 2006

Re: wine autorun utility

by William Knop

> On 6/30/06, William Knop <william.knop(a)gmail.com> wrote: > >> Parsing a windows inf hardly belongs anywhere but wine. > > Actually, Troy makes that point rather well in an earlier mail: > >> This is not true. The existing action-on-CD-insertion programs >> provided by the >> desktop environment try to detect the contents of the CD to see >> what they >> should do, so they will be looking for the autorun.inf file. >> Additionally the >> autorun.inf file format is designed to include specifications of >> different >> commands for multiple environments, so if autorun.inf files are to be >> respected at all it makes sense that they should also be able to >> start a >> native Linux executable or shell script (discovered from an >> [autorun.linux.i386] section, for example). >> >> There is nothing in this that requires or enhances the Win32 API >> facilities >> that Wine seeks to provide. Only once the native Windows >> executable has been >> identified as the only (or best) target for autorun would Wine become >> involved, when the program in the desktop environment invoked Wine >> to run the >> executable. Sorry, I missed this one (mailer digest mode). Hmm... You're saying the autorun.inf format is os-independent? If so, I was unaware, and I agree that the functionality belongs elsewhere. Will

June 30, 2006

Re: DDRAW: Releasing attached surfaces

by Christoph Frick

On Thu, Jun 29, 2006 at 04:43:04PM +0200, Krzysztof Benkowski wrote: > --- surface.c 26 Jun 2006 12:15:20 -0000 1.6 > +++ surface.c 29 Jun 2006 14:09:59 -0000 > @@ -377,7 +377,7 @@ IDirectDrawSurfaceImpl_Release(IDirectDr > while( (surf = This->next_complex) ) > { > This->next_complex = surf->next_complex; /* Unchain it > from the complex listing */ > - IDirectDrawSurfaceImpl_Destroy(surf); /* Destroy it */ > + IDirectDrawSurfaceImpl_Release(surf); /* Release it */ > } as this seems already solved just for the files. this fix let Planescape Torment crash (before it just ended silently by releasing its "primary state block") - it worked before the ddraw patches white fine. i will soon file a bugreport and provide a link to the demo. -- cu

June 30, 2006

Re: [AppDb] appsubmit fix

by Jonathan Ernst

Le jeudi 29 juin 2006 à 12:19 -0400, Chris Morgan a écrit : > Can we pass the parameters we need into the function instead of using a > global? I don't think it is better. If we just pass it it'll make a copy of the array. We could also use &$aClean but I don't see why it would be better too.

June 30, 2006

Re: advapi32: Implement RegisterServiceCtrlHandleExW.

by Robert Shearman

Andrey Turkin wrote: >Robert Shearman wrote: > > > >>@@ -603,10 +608,18 @@ static BOOL service_handle_control(HANDL >> >> TRACE("received control %ld\n", dwControl); >> >>- if (service_accepts_control(service, dwControl) && service->handler) >>+ if (service_accepts_control(service, dwControl)) >> { >>- service->handler(dwControl); >>- ret = ERROR_SUCCESS; >>+ if (service->extended && service->handler.handler) >>+ { >>+ service->handler.handler(dwControl); >>+ ret = ERROR_SUCCESS; >>+ } >>+ else if (service->handler.handler_ex) >>+ { >>+ service->handler.handler_ex(dwControl, 0, NULL, service->context); >>+ ret = ERROR_SUCCESS; >>+ } >> } >> >> >Just wondering why you use Ex handler when service->extended==FALSE and >vice versa. > That would be a bug. Thanks for catching it. -- Rob Shearman

June 30, 2006

Re: advapi32: Implement RegisterServiceCtrlHandleExW.

by Andrey Turkin

Robert Shearman wrote: > --- ... > @@ -603,10 +608,18 @@ static BOOL service_handle_control(HANDL > > TRACE("received control %ld\n", dwControl); > > - if (service_accepts_control(service, dwControl) && service->handler) > + if (service_accepts_control(service, dwControl)) > { > - service->handler(dwControl); > - ret = ERROR_SUCCESS; > + if (service->extended && service->handler.handler) > + { > + service->handler.handler(dwControl); > + ret = ERROR_SUCCESS; > + } > + else if (service->handler.handler_ex) > + { > + service->handler.handler_ex(dwControl, 0, NULL, service->context); > + ret = ERROR_SUCCESS; > + } > } Just wondering why you use Ex handler when service->extended==FALSE and vice versa.

June 30, 2006

Re: [PATCH 10/11] server: add calls to get/set menu item info

by Robert Shearman

H. Verbeet wrote: > On 29/06/06, Thomas Kho <tkho(a)ucla.edu> wrote: > >> +(a)REQ(get_menu_item_info) >> + user_handle_t handle; >> + unsigned int pos; >> +(a)REPLY >> + unsigned int required_size; >> + >> + unsigned int type; >> + unsigned int state; >> + unsigned int id; >> + user_handle_t submenu; >> + user_handle_t checkbit; >> + user_handle_t uncheckbit; >> + void* text; >> + unsigned long itemdata; >> + void* typedata; >> + user_handle_t bmpitem; >> + >> + rectangle_t rect; >> + unsigned int xTab; >> + dimension_t bmpsize; >> + >> + VARARG(text,unicode_str); >> +(a)END > > HBITMAPs aren't technically user handles, and afaik you can't pass GDI > handles between processes like that. At least, not on Windows. You can pass HBITMAPs between processes on Windows, although you are correct in saying that they aren't user handles. Of course, passing bitmap handles between processes on Wine won't work yet. Thomas, can you regenerate this patch using "void *" for bmpitem (or perhaps add a new gdi_handle_t type)? -- Rob Shearman

June 30, 2006

Re: [Tools/Wine.inf] Set Internet Explorer version

by Robert Shearman

Vitaliy Margolen wrote: >Thursday, June 29, 2006, 6:28:11 PM, Olaf Leidinger wrote: > > >>On Thu, 29 Jun 2006 10:56:12 -0700 >>"James Hawkins" <truiken(a)gmail.com> wrote: >> >> > > > >>>On 6/28/06, Maarten Lankhorst <M.B.Lankhorst(a)gmail.com> wrote: >>> >>> >>>>Should we require that people install Internet Explorer or should we put >>>>in patches that increase application compatibility with vanilla wine? >>>> >>>> >>>I don't know why we would require people to install IE, when we have a >>>replacement for it already. >>> >>> > > > >>Web designers - to see what their pages look like in IE. But they could also install IE 7. >> >> > >As been mentioned before this argument is invalid. Native IE does not and will >not behave like on real windows. Thus rendering any such tests invalid. > IE running in Wine still allows me to view sites that don't display properly in Firefox, so it definitely has a use. -- Rob Shearman

June 30, 2006

Re: DDRAW: Releasing attached surfaces

by Stefan Dösinger

Hi, > That's weird, now it works without the "fix" and even Tiberian Sun > starts where previously it hung. > I must have wrongly assumed that the bug was related to surface > implementation code... > But i'm still curious what might be the cause. Will check that out later. > Sorry for bothering then... ;) It was most likely the fix for Tiberian Sun that fixed dune. The problem with ts was that the primary surfaces(front and back) were missing some flags. Maybe dune didn't like the surfaces it got and tried to get rid of them and hit a buggy code path in its code. Stefan

June 30, 2006

Re: wine autorun utility

by Saulius Krasuckas

Forgive my lazyness and my bad english, but IMHO most of discussion resembles MS Corporation behaviour by trying to decide what is good for a user, and what is not. Hey, just let the user or his admin to decide this. IMO there should be just one checkbox in winecfg that rules autorunability. * On Fri, 30 Jun 2006, Tim Schmidt wrote: > KDE and Gnome already have similar functionality. No reason the parser > can't go there (where, perhaps, people might be a little less hostile to > the idea?) Right, but then it still should be nice to find a way for Wine to know if KDE/Gnome is set to autorun win32 apps. And a way to toggle this KDE/Gnome setting. This way could let user/admin to manage autorunability from winecfg by clicking mentioned checkbox. Otherwise user/admin would complain about Wine inability to integrate with the rest of a graphical system :-/ And of course, the autorunability should be disabled by default when graphical environment knows/says nothing about autoruns. Just likes all my neighbouring win-admins do for their customized/unattended XP setups. <g> Hm, someone should show this thread to KDE/Gnome/FreeDesktop folks, IMHO. I am off this task ;)

June 30, 2006

Re: wine autorun utility

by Tim Schmidt

On 6/30/06, William Knop <william.knop(a)gmail.com> wrote: > Parsing a windows inf hardly belongs anywhere but wine. Actually, Troy makes that point rather well in an earlier mail: > This is not true. The existing action-on-CD-insertion programs provided by the > desktop environment try to detect the contents of the CD to see what they > should do, so they will be looking for the autorun.inf file. Additionally the > autorun.inf file format is designed to include specifications of different > commands for multiple environments, so if autorun.inf files are to be > respected at all it makes sense that they should also be able to start a > native Linux executable or shell script (discovered from an > [autorun.linux.i386] section, for example). > > There is nothing in this that requires or enhances the Win32 API facilities > that Wine seeks to provide. Only once the native Windows executable has been > identified as the only (or best) target for autorun would Wine become > involved, when the program in the desktop environment invoked Wine to run the >executable. --tim

June 30, 2006

Re: wine autorun utility

by Tim Schmidt

On 6/30/06, William Knop <william.knop(a)gmail.com> wrote: > Yeah, then in that situation the user wouldn't run `wine --media- > autorun /mountpoint/autorun.inf` either. I fail to see your point. Hey... If all you want to do is write a parser for autorun.inf files and attach it to a command line switch, that sounds pretty easy. Where's the patch? That said, as others have mentioned, KDE and Gnome already have similar functionality. No reason the parser can't go there (where, perhaps, people might be a little less hostile to the idea?) --tim

June 30, 2006

Re: wine autorun utility

by Damjan Jovanovic

--- Chris <chris.kcat(a)gmail.com> wrote: > On Thursday 29 June 2006 21:13, Vitaliy Margolen > wrote: > > Chris if you think that autostart is such a great > idea - you are very > > welcome to start sending patches in. And if they > are reasonable enough they > > might get in. But if you want to rant about that > Linux doesn't have some > > absolutely required "feature" that windows has - > this not the right place. > > This sounds like you missed my point. My argument > isn't that autorun is cool > and Linux should have it (when in fact KDE *does* > have it, to some degree), > my argument is that Windows has it and it's not > inherently detramental (since > the user would be instructed to manually do what > autorun does automatically > anyway, and hence have the same effects), so Wine, > if it is trying to match > Windows feature-for-feature and bug-for-bug, should > have it too. IMO, of > course. Exactly. Windows is such a ubiquitous OS that it sets the standards for all others. Users see Windows autoruning stuff, so when Linux doesn't, "Windows is better". > If I knew how dbus and hal worked, I would probbly > try to make the necesarry > patches. But as I'm not familiar with Win32 or > Wine's internals, I'm not > really qualified to work on it, at this time. I'm > just a user voicing my > opinion. > Chances are it's probably going to work better (and raise fewer objections from developers) if you start wine from the Gnome or KDE autorun, rather than try make wine autorun stuff internally. (Autoruning stuff internally in wine is problematic: both wine and Gnome/KDE could be trying to autorun something at the same time!) I've used hal and dbus before: they're not as bad as they look. Look at wine's explorer, it uses them to both monitor hardware for changes and query hardware properties. __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com

June 30, 2006

Re: wine autorun utility

by Troy Rollo

On Friday 30 June 2006 15:47, William Knop wrote: > 2) The line you refer to I believe would put detecting media inserts > on the desktop environment side, and the parsing and execution of > windows autorun inf files on the wine side. This is not true. The existing action-on-CD-insertion programs provided by the desktop environment try to detect the contents of the CD to see what they should do, so they will be looking for the autorun.inf file. Additionally the autorun.inf file format is designed to include specifications of different commands for multiple environments, so if autorun.inf files are to be respected at all it makes sense that they should also be able to start a native Linux executable or shell script (discovered from an [autorun.linux.i386] section, for example). There is nothing in this that requires or enhances the Win32 API facilities that Wine seeks to provide. Only once the native Windows executable has been identified as the only (or best) target for autorun would Wine become involved, when the program in the desktop environment invoked Wine to run the executable. -- Troy Rollo - wine(a)troy.rollo.name

June 30, 2006

Re: wine autorun utility

by William Knop

On Jun 30, 2006, at 2:01 AM, Tim Schmidt wrote: > On 6/30/06, William Knop <william.knop(a)gmail.com> wrote: >> 1) While I agree maintaining a staunch security policy is important, >> that has nothing to do with autorun. Making the user browse to find >> an executable is not security. > > Yet again... when a user sticks an audio CD in his computer and gets > a rootkit because of autorun, that's _b_a_d_ > > That user isn't going to browse out to the rootkit and install it > him/her self. Yeah, then in that situation the user wouldn't run `wine --media- autorun /mountpoint/autorun.inf` either. I fail to see your point. Will

June 30, 2006

Re: [AppDb] update the comments in some files

by Jonathan Ernst

Le jeudi 29 juin 2006 à 12:43 -0400, Chris Morgan a écrit : > Why not replace the require_once() with requires instead of putting it on the > todo? Because we have to check that it nevers poses a problem (for example if the file is included elsewhere), so that's another patch entierly. > We don't really need the $aClean TODO item since thats high on the priority > list at the moment and we'll just end up removing it in a day or two right? i don't like to rediff it, we'll have to remove the aClean one by one to be sure that it's not posing problems too so that we can remove the todo elements one by one in the files. > > The move of show_note() into its class is on my todo list for class cleanups > today or tomorrow as well. Excellent, you'll remove the todo item at the same time then. > > Basically I think we can do without the todo notes for now since most of it is > in the process of being fixed. The rest of the comments look good though. Please don't refuse this patch because of this, I don't want to rediff it... Thanks

June 30, 2006

Re: wine autorun utility

by Tim Schmidt

On 6/30/06, William Knop <william.knop(a)gmail.com> wrote: > 1) While I agree maintaining a staunch security policy is important, > that has nothing to do with autorun. Making the user browse to find > an executable is not security. Yet again... when a user sticks an audio CD in his computer and gets a rootkit because of autorun, that's _b_a_d_ That user isn't going to browse out to the rootkit and install it him/her self. --tim

June 30, 2006

Re: wine autorun utility

by William Knop

On Jun 30, 2006, at 1:08 AM, Troy Rollo wrote: > On Friday 30 June 2006 14:52, William Knop wrote: > >> Um hold on a second. Clearly many developers have different ideas >> about what's reasonable. > > Actually I don't think that's true. As far as I can see all of the > *developers* participating in this thread agreed that autorun (1) > is a bad > idea and should not be implemented, and (2) is on the other side of > the > demarcation line between Wine and the desktop environment. > > I would be surprised if any significant number of developers > disagreed with > these two points. As for the first, it reflects the difference between > Windows' security model and the Unix/Linux security model (the > difference > being that the latter systems actually have a model deserving of the > label "security"). As for the second, an end user may well not > understand the > distinction between Wine's role and that of the desktop > environment, but a > developer should. Wine is for making Windows applications (and native > applications coded to the Windows API) run - I am not aware of any > developer > who thinks it should be a complete reimplementation of Windows. 1) While I agree maintaining a staunch security policy is important, that has nothing to do with autorun. Making the user browse to find an executable is not security. 2) The line you refer to I believe would put detecting media inserts on the desktop environment side, and the parsing and execution of windows autorun inf files on the wine side. Hell, the user would have to run `wine --media-autorun /mountpoint/autorun.inf`. That has to be as secure as the user running `cd /mountpoint/somedir; wine ./some.exe`. Will

June 30, 2006

Re: wine autorun utility

by Tim Schmidt

On 6/30/06, Chris <chris.kcat(a)gmail.com> wrote: > This sounds like you missed my point. I think you're missing our points Chris... > it's not inherently detramental (since the user would be instructed to manually do > what autorun does automatically Yeah. The Sony rootkit users would have gladly followed the instructions on their _audio CDs_ telling them to install software that prevented fair use and installed illegal software. We're not talking about preventing legitimate use of auto-running CDs. We're talking about a sound, simple, and easy way to prevent illegitimate exploitation. If you can develop a way for Wine to automatically determine whether or not an executable on removable media is something useful or a rootkit, then you may get a little more enthusiasm for this 'feature'. --tim

June 30, 2006

Re: wine autorun utility

by Troy Rollo

On Friday 30 June 2006 14:52, William Knop wrote: > Um hold on a second. Clearly many developers have different ideas > about what's reasonable. Actually I don't think that's true. As far as I can see all of the *developers* participating in this thread agreed that autorun (1) is a bad idea and should not be implemented, and (2) is on the other side of the demarcation line between Wine and the desktop environment. I would be surprised if any significant number of developers disagreed with these two points. As for the first, it reflects the difference between Windows' security model and the Unix/Linux security model (the difference being that the latter systems actually have a model deserving of the label "security"). As for the second, an end user may well not understand the distinction between Wine's role and that of the desktop environment, but a developer should. Wine is for making Windows applications (and native applications coded to the Windows API) run - I am not aware of any developer who thinks it should be a complete reimplementation of Windows. -- Troy Rollo - wine(a)troy.rollo.name

June 30, 2006

Re: wine autorun utility

by Vincent Povirk

On 6/29/06, Chris <chris.kcat(a)gmail.com> wrote: > If you notice, Sony got into a lot of trouble over that. And the problem > wasn't autorun. The problem was that the disc installed the rootkit > anyway /even if the user said no/. The same exact thing would've happened if > the user had to browse the CD and double-click setup.exe, or whatever the > file was called. Should Wine disable running .exe files because they may > install rootkits on users' machines? Of course not, because that would be > couter-productive to what Wine is trying to achieve. It's the same thing with > autorun. It may or may not cause problems, but it's the user's responsibility > to take proper care of their machine. It's just as true in Windows as it is > in Linux, or any other OS. [skip to the last paragraph to get to the point; I thought this other stuff was necessary and now I don't, but I also don't feel like deleting it having already written it] I'm not sure we should install programs in that way on Linux. I think one of the most noticeable differences between Linux and Windows for most people is how you install software. In Windows, you get an exe file from somewhere (hopefully from someone you can trust), and you run it. You then follow the instructions, possibly reboot the computer, and then when you're done you expect the program to be installed and working. If it doesn't work, you complain to the authors of the software. In Linux, most of the software you need will be provided by your distribution. If you're on, say, gentoo, you type "emerge software", and when it's done you expect the program will be installed and working (in this case, you don't have to do anything; you just wait). If it doesn't work, you don't complain to the authors, you complain to gentoo. If it turns out to be an upstream bug, it gets passed along to the authors. If it turns out to be a bug in gentoo, then hopefully they fix it. Of course, Linux users can also do something similar to what the Windows users do and handle the whole process themselves. Then they'll report problems directly to the authors. Now, here's the part where I reward you for reading this far and tell you what this has to do with Wine. Wine users get software from the authors, try to install it themselves, and expect it to work. Then when it doesn't work they complain to Wine. That's backwards. Unless they checked the appdb first, probably no one from Wine claimed it would work to begin with. Yes, most people aren't like that, and yes, people should report bugs. But they shouldn't act like someone said it would probably work if no one has. I think this is a good reason to have something like Wine Doors. For applications that are known to work, possibly with some override or hack, someone could write an installer and vouch for the workingness of at least some apps. People who don't know how to do things like overrides can use the installer. If something doesn't work (and you should expect it to work if there's an installer that's supposed to work on that wine version) then those users have somewhere to complain to. Conversely, applications without installers would be hit-and-miss. You'll have to do a bit more work for those, and you may be paving the way for others by submitting testing data, writing howtos, bug reports, an installer, maybe even fixing something in wine. So it's clear that they might not work. Now, when you make someone's environment say "This CD has a program on it, shall I run it?", you're making the claim that this will probably work. That's just not true. It probably will not work as well as it's supposed to. I'd much rather have people go to a package manager, the applications database, the documentation, ANYWHERE where they will not be promised something that isn't true, even if it makes Wine seem harder to use. -- Vincent Povirk

June 30, 2006

Re: wine autorun utility

by William Knop

> Gee sounds like a "great" idea. We all waiting too see some patches... > > It sure would be cool to have: > - Multiuser Wine > - Wine stable enough to run as service (err hmm whatever the hell > that means... > ah you mean daemon ?) > - Run something more complicated then 'printf("hello world\n");' > without X > - Talk to WMs to show icons and ask questions. > > Chris if you think that autostart is such a great idea - you are > very welcome to > start sending patches in. And if they are reasonable enough they > might get in. > But if you want to rant about that Linux doesn't have some > absolutely required > "feature" that windows has - this not the right place. > > Vitaliy Um hold on a second. Clearly many developers have different ideas about what's reasonable. It makes sense to obtain a semblance of unanimity and mutual understanding before taking action. You shouldn't go around quashing discussions like that. Will

June 30, 2006

Re: wine autorun utility

by Chris

On Thursday 29 June 2006 21:13, Vitaliy Margolen wrote: > Chris if you think that autostart is such a great idea - you are very > welcome to start sending patches in. And if they are reasonable enough they > might get in. But if you want to rant about that Linux doesn't have some > absolutely required "feature" that windows has - this not the right place. This sounds like you missed my point. My argument isn't that autorun is cool and Linux should have it (when in fact KDE *does* have it, to some degree), my argument is that Windows has it and it's not inherently detramental (since the user would be instructed to manually do what autorun does automatically anyway, and hence have the same effects), so Wine, if it is trying to match Windows feature-for-feature and bug-for-bug, should have it too. IMO, of course. If I knew how dbus and hal worked, I would probbly try to make the necesarry patches. But as I'm not familiar with Win32 or Wine's internals, I'm not really qualified to work on it, at this time. I'm just a user voicing my opinion.

June 30, 2006

Re: wine autorun utility

by Tim Schmidt

On 6/29/06, Chris <chris.kcat(a)gmail.com> wrote: > If you notice, Sony got into a lot of trouble over that. And the problem > wasn't autorun. The problem was that the disc installed the rootkit > anyway /even if the user said no/. The same exact thing would've happened if > the user had to browse the CD and double-click setup.exe, or whatever the > file was called. Should Wine disable running .exe files because they may > install rootkits on users' machines? Of course not, because that would be > couter-productive to what Wine is trying to achieve. It's the same thing with > autorun. It may or may not cause problems, but it's the user's responsibility > to take proper care of their machine. It's just as true in Windows as it is > in Linux, or any other OS. Of course. You're right. Everyone's computers _should_ run arbitrary code from any un-authorized source automatically without the user's knowledge or permission. I was wrong. The fact that Windows ran _anything_ upon inserting a CD meant to contain audio only is crap. I understand that Sony exploited a 'feature' of Windows. It's all Sony's fault. Blame Sony. Problem is, that philosophy pushes the trust all the way out to the people who want to install rootkits on your computer. Bad idea. Better to trust Wine not to do anything to endanger your computer without your explicit attention. --tim

June 30, 2006

Re: wine autorun utility

by Vitaliy Margolen

Thursday, June 29, 2006, 8:33:24 PM, Chris wrote: > On Thursday 29 June 2006 07:49, you wrote: >> what is the gain of autorun, while i dont have wine running? would not >> the common user expect, once she knows, that wine support autorun.inf, >> that she can insert a cd and away it goes? while the explorer.exe is >> not running permanently - e.g. via xinitrc - then i still would have to >> deal with starting my setup.exe by hand. i have my doubts, that wine is >> the correct place to implement this - but something like hotplugd or >> whatevernowadaysdoesthetrickwithcdroms should handle this? > One could think of Wine as a service, and start it with X if they wanted, so > they could then run Windows programs whenever they wanted with potentially > faster startup times, and with Windows "features" like autorun, and with a > persistant Windows state (eg. instead of being shut down when all Windows > programs close, it would stay around until Wine itself is explicitly > stopped). Or, like me currently, they could run a Windows desktop/taskbar > replacement in a Wine virtual desktop with managed windows off on a seperate > X desktop and pretend to have Windows running along side X. > I'd think if Wine were trying to "emulate" Windows as much as possible, it'd > be backwards to not have autorun capabilities. As I said before, autorun.inf > needs to be parsed anyway since it can define an icon to use for the drive, > so if you're going to automatically parse it to load an icon, why not also > ask (one time only) if the user wants to turn autorun on or off to run the > defined program? Gee sounds like a "great" idea. We all waiting too see some patches... It sure would be cool to have: - Multiuser Wine - Wine stable enough to run as service (err hmm whatever the hell that means... ah you mean daemon ?) - Run something more complicated then 'printf("hello world\n");' without X - Talk to WMs to show icons and ask questions. Chris if you think that autostart is such a great idea - you are very welcome to start sending patches in. And if they are reasonable enough they might get in. But if you want to rant about that Linux doesn't have some absolutely required "feature" that windows has - this not the right place. Vitaliy

June 30, 2006

Re: wine autorun utility

by Chris

On Thursday 29 June 2006 20:31, Tim Schmidt wrote: > The Sony rootkit fiasco alone should be enough to end this conversation. If you notice, Sony got into a lot of trouble over that. And the problem wasn't autorun. The problem was that the disc installed the rootkit anyway /even if the user said no/. The same exact thing would've happened if the user had to browse the CD and double-click setup.exe, or whatever the file was called. Should Wine disable running .exe files because they may install rootkits on users' machines? Of course not, because that would be couter-productive to what Wine is trying to achieve. It's the same thing with autorun. It may or may not cause problems, but it's the user's responsibility to take proper care of their machine. It's just as true in Windows as it is in Linux, or any other OS.

June 30, 2006

Re: wine autorun utility

by Tim Schmidt

The Sony rootkit fiasco alone should be enough to end this conversation. Period. Say what you want about the theoretical integrity of the media, and the user's security habits. The fact is that hundreds (possibly thousands or millions) of _real_ people were infected by rootkits because of autorun and an unscrupulous corporation. As you've so aptly demonstrated, average users are all too willing to trust people who don't deserve to be trusted. If Wine can protect some of those people sometimes, great. If Wine can protect people without any developers having to do any work, that's simply amazing. Well done Wine devs. --tim

June 30, 2006

Re: wine autorun utility

by Chris

On Thursday 29 June 2006 07:49, you wrote: > what is the gain of autorun, while i dont have wine running? would not > the common user expect, once she knows, that wine support autorun.inf, > that she can insert a cd and away it goes? while the explorer.exe is > not running permanently - e.g. via xinitrc - then i still would have to > deal with starting my setup.exe by hand. i have my doubts, that wine is > the correct place to implement this - but something like hotplugd or > whatevernowadaysdoesthetrickwithcdroms should handle this? One could think of Wine as a service, and start it with X if they wanted, so they could then run Windows programs whenever they wanted with potentially faster startup times, and with Windows "features" like autorun, and with a persistant Windows state (eg. instead of being shut down when all Windows programs close, it would stay around until Wine itself is explicitly stopped). Or, like me currently, they could run a Windows desktop/taskbar replacement in a Wine virtual desktop with managed windows off on a seperate X desktop and pretend to have Windows running along side X. I'd think if Wine were trying to "emulate" Windows as much as possible, it'd be backwards to not have autorun capabilities. As I said before, autorun.inf needs to be parsed anyway since it can define an icon to use for the drive, so if you're going to automatically parse it to load an icon, why not also ask (one time only) if the user wants to turn autorun on or off to run the defined program?

June 30, 2006

Re: wine autorun utility

by nlaw＠nildram.co.uk

William Knop wrote: > > On Jun 29, 2006, at 8:59 PM, Vitaliy Margolen wrote: >> Thursday, June 29, 2006, 12:02:38 PM, William Knop wrote: >>> Having the ability to autorun cds is most definitely not a misfeature. >> Of course it's not. It's the perfect means of distributing trojans, >> backdoors, >> rootkits and other very useful software an every CD, including DVDs >> and music >> CDs. > > If your assuming said media is compromised in such a way, requiring > the user to manually run the executable will not protect him. The fact > is, most media is not compromised. Software publishers ensure they are > not. Most windows users can trust their software publishers. For those > who cannot, they can simply click "No" when the dialog pops up. Or > they can set it to never autorun. Or they could set it to virus-scan > before autorunning. Everybody's happy. > > One thing I'm sure of: If regular guy Joe Schmo has to run executables > from CDs manually, he will either say CDs don't work in wine or say > that wine is a PITA to use. > I totally agree, autorun is a must (ok put in all the checks) but wine is being put together for the average user isn't it, that means if they put in a CD they expect it to do something, and don't care whether it's 100% secure, (that's the job of the virus/spyware detection software). Now wouldn't that be something wine with AVG/Spybot/Adaware buildin. Although I heard today Microsoft has just done that, a security suite for windows of course you have to pay a subscription otherwise they can't guarantee windows will be secure, mmm ... However, seeing as you can't even install a multi CD game in wine without the game complaining about the fact it can't find CD 2, perhaps priorities need to be sorted. What's the point of autorun when the app throws a wobbly when it gets to CD2

June 30, 2006

Re: wine autorun utility

by Vitaliy Margolen

Thursday, June 29, 2006, 7:37:16 PM, William Knop wrote: > On Jun 29, 2006, at 8:59 PM, Vitaliy Margolen wrote: >> Thursday, June 29, 2006, 12:02:38 PM, William Knop wrote: >>> Having the ability to autorun cds is most definitely not a >>> misfeature. >> Of course it's not. It's the perfect means of distributing trojans, >> backdoors, >> rootkits and other very useful software an every CD, including DVDs >> and music >> CDs. > If your assuming said media is compromised in such a way, requiring > the user to manually run the executable will not protect him. The > fact is, most media is not compromised. Software publishers ensure > they are not. Most windows users can trust their software publishers. That's what SONY been telling all along... Vitaliy

June 30, 2006

Re: wine autorun utility

by William Knop

On Jun 29, 2006, at 8:59 PM, Vitaliy Margolen wrote: > Thursday, June 29, 2006, 12:02:38 PM, William Knop wrote: >> Having the ability to autorun cds is most definitely not a >> misfeature. > Of course it's not. It's the perfect means of distributing trojans, > backdoors, > rootkits and other very useful software an every CD, including DVDs > and music > CDs. If your assuming said media is compromised in such a way, requiring the user to manually run the executable will not protect him. The fact is, most media is not compromised. Software publishers ensure they are not. Most windows users can trust their software publishers. For those who cannot, they can simply click "No" when the dialog pops up. Or they can set it to never autorun. Or they could set it to virus-scan before autorunning. Everybody's happy. One thing I'm sure of: If regular guy Joe Schmo has to run executables from CDs manually, he will either say CDs don't work in wine or say that wine is a PITA to use.

June 30, 2006

Re: wine autorun utility

by Vitaliy Margolen

Thursday, June 29, 2006, 12:02:38 PM, William Knop wrote: > On 6/29/06, Vincent Povirk <madewokherd+d41d(a)gmail.com> wrote: >> On 6/29/06, Chris <chris.kcat(a)gmail.com> wrote: >> > One could argue Windows itself is a mis-feature. :P Isn't the point of Wine to >> > duplicate Windows, feature-for-feature and bug-for-bug? IMO, autorun >> > capabilities should be included, though I personally don't care if it's on or >> > off by default, as long as there's an option in winecfg. I'll just turn it >> > off myself. Or perhaps even a popup notification upon the first detected >> > autorun-capable disc, asking if you want to turn autorun on or off. >> > autorun.inf needs to be parsed anyway, since it can set an icon for the >> > drive. >> No, I think the point of Wine is to run Windows programs on top of >> Unix. We don't need autorun to run Windows programs at all. Wine often >> leaves out features that are in Windows because they aren't needed to >> get Windows programs to run. >> >> Running whatever code happens to be on a cd without asking the user is >> a very bad idea. I don't want to see it happen, and I think most real >> Wine devs probably feel the same way. >> >> Gnome already has a feature that can ask the user what to do when a cd >> is inserted. KDE probably has a similar feature. I think they'd be the >> people to ask if you want something like Windows' autorun. > Having the ability to autorun cds is most definitely not a misfeature. Of course it's not. It's the perfect means of distributing trojans, backdoors, rootkits and other very useful software an every CD, including DVDs and music CDs. Vitaliy.

June 30, 2006

Re: [Tools/Wine.inf] Set Internet Explorer version

by Vitaliy Margolen

Thursday, June 29, 2006, 6:28:11 PM, Olaf Leidinger wrote: > On Thu, 29 Jun 2006 10:56:12 -0700 > "James Hawkins" <truiken(a)gmail.com> wrote: >> On 6/28/06, Maarten Lankhorst <M.B.Lankhorst(a)gmail.com> wrote: >>> >>> Should we require that people install Internet Explorer or should we put >>> in patches that increase application compatibility with vanilla wine? >> >> I don't know why we would require people to install IE, when we have a >> replacement for it already. > Web designers - to see what their pages look like in IE. But they could also install IE 7. As been mentioned before this argument is invalid. Native IE does not and will not behave like on real windows. Thus rendering any such tests invalid. Vitaliy.

June 30, 2006

Re: [Tools/Wine.inf] Set Internet Explorer version

by Olaf Leidinger

On Thu, 29 Jun 2006 10:56:12 -0700 "James Hawkins" <truiken(a)gmail.com> wrote: > On 6/28/06, Maarten Lankhorst <M.B.Lankhorst(a)gmail.com> wrote: > > > > Should we require that people install Internet Explorer or should we put > > in patches that increase application compatibility with vanilla wine? > > > > I don't know why we would require people to install IE, when we have a > replacement for it already. Web designers - to see what their pages look like in IE. But they could also install IE 7.

June 30, 2006

Re: [Tools/Wine.inf] Set Internet Explorer version

by James Hawkins

On 6/29/06, Olaf Leidinger <leidola(a)newcon.de> wrote: > On Thu, 29 Jun 2006 10:56:12 -0700 > "James Hawkins" <truiken(a)gmail.com> wrote: > > > On 6/28/06, Maarten Lankhorst <M.B.Lankhorst(a)gmail.com> wrote: > > > > > > Should we require that people install Internet Explorer or should we put > > > in patches that increase application compatibility with vanilla wine? > > > > > > > I don't know why we would require people to install IE, when we have a > > replacement for it already. > > Web designers - to see what their pages look like in IE. But they could also install IE 7. > He was asking if we should *require* people to install IE, and I said no, we shouldn't. If someone wants to install IE, go ahead, but apps that depend on the presence of IE should work with builtin IE. -- James Hawkins

June 29, 2006

Re: urlmon: Implement URLDownloadToCacheFile

by James Hawkins

On 6/29/06, Troy Rollo <wine(a)troy.rollo.name> wrote: > > This is not the correct behaviour - doing this will result in the cache > directories filling up with files that are not mentioned in the cache index. > You should be calling CreateUrlCacheEntryW to get the file name for the new > file. I was looking for something like that, thanks Troy. -- James Hawkins

June 29, 2006

Re: DDRAW: Releasing attached surfaces

by Stefan Dösinger

Am Donnerstag 29 Juni 2006 16:43 schrieb Krzysztof Benkowski: > Hello, > In the latest version of wine (0.9.16) there is a regression which makes > Dune 2000 crash. > After some debugging i found that the problem lays in > IDirectDrawSurfaceImpl_Release method. > The game (Dune 2000) shows that the assumption that all attached > surfaces should be destroyed > regardless of their refcount is wrong. After a long google session I found a downloadable demo, but I can't reproduce the bug. The game starts fine and I can play just fine. The game doesn't clean up properly, it doesn't release the front buffer(stays at refcount 1), and of course the back buffer is left with refcount 2. The cleanup code in dllMain releases both surfaces and the directdraw interface. I noticed that 8 bit graphics do not work. Can you make sure that you have updated to the latest git code and mail me a +ddraw trace if the problem still occurs? Stefan

June 29, 2006

Re: urlmon: Implement URLDownloadToCacheFile

by Troy Rollo

On Friday 30 June 2006 07:36, James Hawkins wrote: > + lstrcatW(cache_path, backslash); > + lstrcatW(cache_path, content); > + > + if (!GetTempFileNameW(cache_path, prefix, 0, cache_path)) > + return E_FAIL; > + > + if (lstrlenW(cache_path) > dwBufLength) > + return E_INVALIDARG; > + > + lstrcpyW(szFileName, cache_path); > + > + return URLDownloadToFileW(lpUnkCaller, szURL, szFileName, 0, pBSC); This is not the correct behaviour - doing this will result in the cache directories filling up with files that are not mentioned in the cache index. You should be calling CreateUrlCacheEntryW to get the file name for the new file. -- Troy Rollo - wine(a)troy.rollo.name

June 29, 2006

Re: Call for volunteer: dwarf2 testing

by Paul Romanyszyn

Eric Pouech wrote: > As you may have seen, there's now some support for the dwarf2 debug > format (instead of stabs) in the Wine tree > I'd like to get some feedback on the overall feedback on how it behaves. > To do so, you need to reconfigure Wine with something like > CFLAGS="$CFLAGS -gdwarf-2" ./configure > and then make clean; make (so that all modules are recompiled with > proper format) > > Normal debugging should be available with winedbg. > If something goes wrong, please indicate: > - console messages > - error items > - steps that led to it > - version of gcc used > > TIA > > running a 16 bit application from bug Bug 5493 now gives an a continuous list of fixme:dbghelp_dwarf:dwarf2_compute_location Unhandled attr op: 75 instead of continuous page faulting between on the lookup. What traces do you need and I will add them to that bug. That bugs url links to the zip of the exe's with instructions on how to reproduce. gcc (GCC) 4.0.1 (4.0.1-5mdk for Mandriva Linux release 2006.0) Paul R.

June 29, 2006

Re: DDRAW: Releasing attached surfaces

by H. Verbeet

On 29/06/06, Stefan Dösinger <stefandoesinger(a)gmx.at> wrote: > If someone can think of a way to prove that a COM object is actually destroyed > then a test case might clear up this issue. > > Stefan Do an AddRef() and hope the memory wasn't overwritten yet? :-)

June 29, 2006

Re: [PATCH 10/11] server: add calls to get/set menu item info

by H. Verbeet

On 29/06/06, Thomas Kho <tkho(a)ucla.edu> wrote: > +(a)REQ(get_menu_item_info) > + user_handle_t handle; > + unsigned int pos; > +(a)REPLY > + unsigned int required_size; > + > + unsigned int type; > + unsigned int state; > + unsigned int id; > + user_handle_t submenu; > + user_handle_t checkbit; > + user_handle_t uncheckbit; > + void* text; > + unsigned long itemdata; > + void* typedata; > + user_handle_t bmpitem; > + > + rectangle_t rect; > + unsigned int xTab; > + dimension_t bmpsize; > + > + VARARG(text,unicode_str); > +(a)END HBITMAPs aren't technically user handles, and afaik you can't pass GDI handles between processes like that. At least, not on Windows.

June 29, 2006

Re: DDRAW: Releasing attached surfaces

by Stefan Dösinger

Am Donnerstag 29 Juni 2006 16:43 schrieb Krzysztof Benkowski: > Hello, > In the latest version of wine (0.9.16) there is a regression which makes > Dune 2000 crash. > After some debugging i found that the problem lays in > IDirectDrawSurfaceImpl_Release method. > The game (Dune 2000) shows that the assumption that all attached > surfaces should be destroyed > regardless of their refcount is wrong. According to the msdn this should happen, and it sounds logical to me. All complex surfaces are created with one call, so they should be destroyed with one call too. I haven't seen a single app explicitly releasing the back buffer, even the sdk demos don't do that. Ideally a test case could be of help, but I don't know how to test if a surface is actually destroyed. > What causes the crash in few words: > - first Dune 2000 creates a surface with a backbuffer > - then it gets the backbuffer interface by GetAttachedSurface method > (refcount for the backbuffer is incremented) > - it releases the frontbuffer (the backbuffer is destroyed even though > its refcount is higher than frontbuffer's) Are you sure that the front buffer is meant to be destroyed? Maybe the front buffer's refcount is meant to be increased somewhere, so it isn't destroyed? > - creates new frontbuffer and an offscreen plain Does it attach the front buffer to the back buffer, or vice versa? > So my fix is rather quick and thus i'm not quite sure if it's correct. > That's because the game works with it > but when it quits it leaves the backbuffer not released. I don't know if > it's the game's fault or the fix has to be > done some other way. I've done it this way: > > --- surface.c 26 Jun 2006 12:15:20 -0000 1.6 > +++ surface.c 29 Jun 2006 14:09:59 -0000 > @@ -377,7 +377,7 @@ IDirectDrawSurfaceImpl_Release(IDirectDr > while( (surf = This->next_complex) ) > { > This->next_complex = surf->next_complex; /* Unchain it > from the complex listing */ > - IDirectDrawSurfaceImpl_Destroy(surf); /* Destroy it */ > + IDirectDrawSurfaceImpl_Release(surf); /* Release it */ > } This was my original way of handling this, and it lead to huge memory leaks in 3D games which create mipmap textures. Usually they call getAttachedSurface for the sublevels and didn't care to release the surfaces. If someone can think of a way to prove that a COM object is actually destroyed then a test case might clear up this issue. Stefan

June 29, 2006

Call for volunteer: dwarf2 testing

by Eric Pouech

As you may have seen, there's now some support for the dwarf2 debug format (instead of stabs) in the Wine tree I'd like to get some feedback on the overall feedback on how it behaves. To do so, you need to reconfigure Wine with something like CFLAGS="$CFLAGS -gdwarf-2" ./configure and then make clean; make (so that all modules are recompiled with proper format) Normal debugging should be available with winedbg. If something goes wrong, please indicate: - console messages - error items - steps that led to it - version of gcc used TIA

June 29, 2006

Re: [AppDB] Viewing application famlies screen shots is broken.

by Chris Morgan

Should be fixed now. Chris On Thursday 29 June 2006 2:53 pm, Tony Lambregts wrote: > Viewing application famlies screen shots is broken. I don't think is from > todays patches. You can see the problem in the following link. > > http://appdb.winehq.org/screenshots.php?appId=631 > > The random screenshot shows up fine on the application page though. > > http://appdb.winehq.org/appview.php?appId=631 > > -- > > Tony Lambregts

June 29, 2006

[AppDB] Viewing application famlies screen shots is broken.

by Tony Lambregts

Viewing application famlies screen shots is broken. I don't think is from todays patches. You can see the problem in the following link. http://appdb.winehq.org/screenshots.php?appId=631 The random screenshot shows up fine on the application page though. http://appdb.winehq.org/appview.php?appId=631 -- Tony Lambregts

June 29, 2006

Re: appdb/ ./appbrowse.php ./appsubmit.php ./appvi ...

by Chris Morgan

Oh ok. If you wanted you could put that on the TODO page so we didn't forget about it. Chris On Thursday 29 June 2006 2:18 pm, Tony Lambregts wrote: > > Are they supposed to be able to monitor application familes? I'm > > confused as to whether that is a bug or just how things are working. > > > > Chris > > Not a bug just a missing feature. They never could. > > -- > > Tony Lambregts

June 29, 2006

Re: appdb/ ./appbrowse.php ./appsubmit.php ./appvi ...

by Tony Lambregts

> Are they supposed to be able to monitor application familes? I'm confused as > to whether that is a bug or just how things are working. > > Chris > Not a bug just a missing feature. They never could. -- Tony Lambregts

June 29, 2006

Re: Re: wine autorun utility

by William Knop

On 6/29/06, Vincent Povirk <madewokherd+d41d(a)gmail.com> wrote: > On 6/29/06, Chris <chris.kcat(a)gmail.com> wrote: > > One could argue Windows itself is a mis-feature. :P Isn't the point of Wine to > > duplicate Windows, feature-for-feature and bug-for-bug? IMO, autorun > > capabilities should be included, though I personally don't care if it's on or > > off by default, as long as there's an option in winecfg. I'll just turn it > > off myself. Or perhaps even a popup notification upon the first detected > > autorun-capable disc, asking if you want to turn autorun on or off. > > autorun.inf needs to be parsed anyway, since it can set an icon for the > > drive. > No, I think the point of Wine is to run Windows programs on top of > Unix. We don't need autorun to run Windows programs at all. Wine often > leaves out features that are in Windows because they aren't needed to > get Windows programs to run. > > Running whatever code happens to be on a cd without asking the user is > a very bad idea. I don't want to see it happen, and I think most real > Wine devs probably feel the same way. > > Gnome already has a feature that can ask the user what to do when a cd > is inserted. KDE probably has a similar feature. I think they'd be the > people to ask if you want something like Windows' autorun. Having the ability to autorun cds is most definitely not a misfeature. Most people who use windows do not want to or are incapable of hunting around a cd for the correct executable to run the installer for their game or whatever. Sure wine is not catering to those people right now, however it will in the future if all goes well. I agree that autorunning all cds without ever asking the user is not good, however the feature itself is not bad. Asking the user is clearly the solution. Windows is simply not designed to have the average user perusing software directories. Will's $0.02

June 29, 2006

Re: appdb/ ./appbrowse.php ./appsubmit.php ./appvi ...

by Chris Morgan

On Thursday 29 June 2006 1:51 pm, Tony Lambregts wrote: > > This patch breaks the monitor notification emails. > > more specificly... > > > diff -u -p appdb/include/monitor.php:1.5 appdb/include/monitor.php:1.6 > > --- appdb/include/monitor.php:1.5 Thu Jun 29 17:43:08 2006 > > +++ appdb/include/monitor.php Thu Jun 29 17:43:08 2006 > > @@ -93,19 +93,25 @@ class Monitor { > > > > function SendNotificationMail($sAction="add",$sMsg=null) > > { > > + /* set $aAppName appropriately */ > > + if(isset($this->iVersionId)) > > + $sAppName = Application::lookup_name($oVersion->iAppId)." > > ".Version::lookup_name($this->iVersionId); + else > > + $sAppName = Application::lookup_name($oVersion->iAppId); > > + > > It looks like Application::lookup_name($oVersion->iAppId)returns "". Also > people can only monitor application versions they cannot monitor > application familys at this time. > Ahh yes. Using the version before the object exists. Fixing that. Are they supposed to be able to monitor application familes? I'm confused as to whether that is a bug or just how things are working. Chris

June 29, 2006

Re: [Tools/Wine.inf] Set Internet Explorer version

by James Hawkins

On 6/28/06, Maarten Lankhorst <M.B.Lankhorst(a)gmail.com> wrote: > > Should we require that people install Internet Explorer or should we put > in patches that increase application compatibility with vanilla wine? > I don't know why we would require people to install IE, when we have a replacement for it already. -- James Hawkins

June 29, 2006

Re: appdb/ ./appbrowse.php ./appsubmit.php ./appvi ...

by Tony Lambregts

> > This patch breaks the monitor notification emails. more specificly... > diff -u -p appdb/include/monitor.php:1.5 appdb/include/monitor.php:1.6 > --- appdb/include/monitor.php:1.5 Thu Jun 29 17:43:08 2006 > +++ appdb/include/monitor.php Thu Jun 29 17:43:08 2006 > @@ -93,19 +93,25 @@ class Monitor { > > function SendNotificationMail($sAction="add",$sMsg=null) > { > + /* set $aAppName appropriately */ > + if(isset($this->iVersionId)) > + $sAppName = Application::lookup_name($oVersion->iAppId)." ".Version::lookup_name($this->iVersionId); > + else > + $sAppName = Application::lookup_name($oVersion->iAppId); > + It looks like Application::lookup_name($oVersion->iAppId)returns "". Also people can only monitor application versions they cannot monitor application familys at this time. -- Tony Lambregts

June 29, 2006

Re: appdb/ ./appbrowse.php ./appsubmit.php ./appvi ...

by Tony Lambregts

WineHQ wrote: > ChangeSet ID: 26125 > CVSROOT: /opt/cvs-commit > Module name: appdb > Changes by: wineowner(a)winehq.org 2006/06/29 11:07:20 > > Modified files: > . : appbrowse.php appsubmit.php appview.php > admin : adminAppDataQueue.php adminAppQueue.php > adminMaintainers.php > include : application.php bugs.php comment.php > monitor.php note.php screenshot.php > sidebar_login.php url.php util.php version.php > vote.php > > Log message: > Chris Morgan <cmorgan(a)alum.wpi.edu> > Clean up application and version classes. Move class related functions into the class as static member functions > > Patch: http://cvs.winehq.org/patch.py?id=26125 > > Old revision New revision Changes Path > 1.13 1.14 +1 -1 appdb/appbrowse.php > 1.43 1.44 +2 -2 appdb/appsubmit.php > 1.82 1.83 +1 -1 appdb/appview.php > 1.22 1.23 +6 -6 appdb/admin/adminAppDataQueue.php > 1.57 1.58 +4 -4 appdb/admin/adminAppQueue.php > 1.19 1.20 +3 -3 appdb/admin/adminMaintainers.php > 1.50 1.51 +15 -53 appdb/include/application.php > 1.10 1.11 +7 -5 appdb/include/bugs.php > 1.21 1.22 +2 -2 appdb/include/comment.php > 1.5 1.6 +10 -4 appdb/include/monitor.php > 1.10 1.11 +4 -3 appdb/include/note.php > 1.39 1.40 +7 -5 appdb/include/screenshot.php > 1.13 1.14 +2 -2 appdb/include/sidebar_login.php > 1.6 1.7 +7 -5 appdb/include/url.php > 1.61 1.62 +18 -2 appdb/include/util.php > 1.58 1.59 +47 -38 appdb/include/version.php > 1.17 1.18 +2 -2 appdb/include/vote.php > This patch breaks the monitor notification emails. -- Tony Lambregs

June 29, 2006

Re: [AppDb] prefix all GPC variables

by Chris Morgan

Patch looks good and although it is large like you said it isn't something we can do much about at this point. It unfortunately doesn't apply cleanly against cvs head. If you could submit all of the smaller cleanup patches ahead of big patches like this that would be the best. Its more likely that larger patches like this will require changes than simple renames or refactoring and getting those out of the way means neither of us have to track which patches have gone in vs. need to be rediffed against cvs head. I'll usually make a single change in a single checked out appdb directory. That way I'm always diffing against cvs head and I can avoid having patches that depend on each other. I'm concerned now if you've made further changes to the directory where this patch was generated that some fixes will be missed or unwanted changes will sneak in. Lets get all of the rest of the isolated cleanups that you've submitted into the appdb and then lets give this patch another shot. Chris On Thursday 29 June 2006 4:59 am, Jonathan Ernst wrote: > Before you ask, there was no possibility to split this one up because > everything is interdependant. > > Changelog: > - rename all Get/Post/Cookies variables using type prefixes so that we can > later use the autofiltering function

June 29, 2006

Re: [AppDb] factor exit calls after redirect

by Chris Morgan

Patch doesn't apply against CVS head. Chris On Thursday 29 June 2006 7:05 am, Jonathan Ernst wrote: > You might need to apply the previous patches first. > > Changelog: > - factor exit calls after redirect

June 29, 2006

Re: [AppDb] update the comments in some files

by Chris Morgan

Why not replace the require_once() with requires instead of putting it on the todo? We don't really need the $aClean TODO item since thats high on the priority list at the moment and we'll just end up removing it in a day or two right? The move of show_note() into its class is on my todo list for class cleanups today or tomorrow as well. Basically I think we can do without the todo notes for now since most of it is in the process of being fixed. The rest of the comments look good though. Chris On Thursday 29 June 2006 9:43 am, Jonathan Ernst wrote: > You might need to apply the previous patches first. > > Changelog: > - update the comments in some files

June 29, 2006

Re: [AppDb] appsubmit fix

by Chris Morgan

Can we pass the parameters we need into the function instead of using a global? Chris On Thursday 29 June 2006 2:29 am, Jonathan Ernst wrote: > Changelog: > - $aClean was not visible in function

June 29, 2006

Re: wine autorun utility

by Vijay Kiran Kamuju

Thats what I meant. On 6/29/06, Vincent Povirk <madewokherd+d41d(a)gmail.com> wrote: > On 6/29/06, Chris <chris.kcat(a)gmail.com> wrote: > > One could argue Windows itself is a mis-feature. :P Isn't the point of Wine to > > duplicate Windows, feature-for-feature and bug-for-bug? IMO, autorun > > capabilities should be included, though I personally don't care if it's on or > > off by default, as long as there's an option in winecfg. I'll just turn it > > off myself. Or perhaps even a popup notification upon the first detected > > autorun-capable disc, asking if you want to turn autorun on or off. > > autorun.inf needs to be parsed anyway, since it can set an icon for the > > drive. > No, I think the point of Wine is to run Windows programs on top of > Unix. We don't need autorun to run Windows programs at all. Wine often > leaves out features that are in Windows because they aren't needed to > get Windows programs to run. > > Running whatever code happens to be on a cd without asking the user is > a very bad idea. I don't want to see it happen, and I think most real > Wine devs probably feel the same way. > > Gnome already has a feature that can ask the user what to do when a cd > is inserted. KDE probably has a similar feature. I think they'd be the > people to ask if you want something like Windows' autorun. > > -- > Vincent Povirk > > >

June 29, 2006

Re: wine autorun utility

by Vincent Povirk

On 6/29/06, Chris <chris.kcat(a)gmail.com> wrote: > One could argue Windows itself is a mis-feature. :P Isn't the point of Wine to > duplicate Windows, feature-for-feature and bug-for-bug? IMO, autorun > capabilities should be included, though I personally don't care if it's on or > off by default, as long as there's an option in winecfg. I'll just turn it > off myself. Or perhaps even a popup notification upon the first detected > autorun-capable disc, asking if you want to turn autorun on or off. > autorun.inf needs to be parsed anyway, since it can set an icon for the > drive. No, I think the point of Wine is to run Windows programs on top of Unix. We don't need autorun to run Windows programs at all. Wine often leaves out features that are in Windows because they aren't needed to get Windows programs to run. Running whatever code happens to be on a cd without asking the user is a very bad idea. I don't want to see it happen, and I think most real Wine devs probably feel the same way. Gnome already has a feature that can ask the user what to do when a cd is inserted. KDE probably has a similar feature. I think they'd be the people to ask if you want something like Windows' autorun. -- Vincent Povirk

June 29, 2006

Re: [Tools/Wine.inf] Set Internet Explorer version

by Jaap Stolk

Does this also update the version of the (fake) shdocvw.dll in wine ? At least AutoCad 2004 checks the version info of the file.

June 29, 2006

DDRAW: Releasing attached surfaces

by Krzysztof Benkowski

Hello, In the latest version of wine (0.9.16) there is a regression which makes Dune 2000 crash. After some debugging i found that the problem lays in IDirectDrawSurfaceImpl_Release method. The game (Dune 2000) shows that the assumption that all attached surfaces should be destroyed regardless of their refcount is wrong. What causes the crash in few words: - first Dune 2000 creates a surface with a backbuffer - then it gets the backbuffer interface by GetAttachedSurface method (refcount for the backbuffer is incremented) - it releases the frontbuffer (the backbuffer is destroyed even though its refcount is higher than frontbuffer's) - creates new frontbuffer and an offscreen plain - when one starts a mission the game tries to use the old backbuffer (which is then destroyed) and causes a page fault So my fix is rather quick and thus i'm not quite sure if it's correct. That's because the game works with it but when it quits it leaves the backbuffer not released. I don't know if it's the game's fault or the fix has to be done some other way. I've done it this way: --- surface.c 26 Jun 2006 12:15:20 -0000 1.6 +++ surface.c 29 Jun 2006 14:09:59 -0000 @@ -377,7 +377,7 @@ IDirectDrawSurfaceImpl_Release(IDirectDr while( (surf = This->next_complex) ) { This->next_complex = surf->next_complex; /* Unchain it from the complex listing */ - IDirectDrawSurfaceImpl_Destroy(surf); /* Destroy it */ + IDirectDrawSurfaceImpl_Release(surf); /* Release it */ } If you (Stefan probably) need more info about the bug i can provide some logs Krzysiek

June 29, 2006

Re: wine autorun utility

by Chris

On Thursday 29 June 2006 06:48, David D. Hagood wrote: > I strongly DISAGREE - as others have pointed out, the auto-running of > CDs is a severe mis-feature of Windows, one which we should NOT duplicate. One could argue Windows itself is a mis-feature. :P Isn't the point of Wine to duplicate Windows, feature-for-feature and bug-for-bug? IMO, autorun capabilities should be included, though I personally don't care if it's on or off by default, as long as there's an option in winecfg. I'll just turn it off myself. Or perhaps even a popup notification upon the first detected autorun-capable disc, asking if you want to turn autorun on or off. autorun.inf needs to be parsed anyway, since it can set an icon for the drive.

June 29, 2006

Re: wine autorun utility

by Marcus Meissner

On Thu, Jun 29, 2006 at 08:48:31AM -0500, David D. Hagood wrote: > Vijay Kiran Kamuju wrote: > >hi, > > > >I think HAL for linux should handle the automatic mounting and > >autorunning it take care. > >So it should be a part of HAL. > > > >my 2 cents. > > > > I strongly DISAGREE - as others have pointed out, the auto-running of > CDs is a severe mis-feature of Windows, one which we should NOT duplicate. > > Now, I could agree with the idea of a program that, upon receiving a > DBUS notification of a CD insertion, looked to see if there was an > autorun.inf file, and then *asked the user what to do*. IF the user then > said "Yes, please run this disk" then the program would parse the > autorun.inf file. > > Ideally, such a program would also maintain a database of CDs already > seen, and would allow the user to define an action for the CD that would > happen automatically - an action that may have NOTHING to do with the CD > itself. But the default action, for CDs never before seen should be "ask > the user". cd programs/explorer/ vi hal.c Ciao, Marcus

June 29, 2006

Re: wine autorun utility

by David D. Hagood

Vijay Kiran Kamuju wrote: > hi, > > I think HAL for linux should handle the automatic mounting and > autorunning it take care. > So it should be a part of HAL. > > my 2 cents. > I strongly DISAGREE - as others have pointed out, the auto-running of CDs is a severe mis-feature of Windows, one which we should NOT duplicate. Now, I could agree with the idea of a program that, upon receiving a DBUS notification of a CD insertion, looked to see if there was an autorun.inf file, and then *asked the user what to do*. IF the user then said "Yes, please run this disk" then the program would parse the autorun.inf file. Ideally, such a program would also maintain a database of CDs already seen, and would allow the user to define an action for the CD that would happen automatically - an action that may have NOTHING to do with the CD itself. But the default action, for CDs never before seen should be "ask the user". Equally ideally, there should be a standard for *nix autorun files, that would allow for a bit more than "infect^Wrun this" - something like an XML file describing the disk, a set of possible actions (run a script, run an existing program, perform some "standard action" like "play as DVD", "run music program"), and the "autorun" program would be part of the operating environment, and would present a meaningful menu to the user.

June 29, 2006

Re: [AppDb] util_show_error_page

by Tony Lambregts

Chris Morgan wrote: > This is a rename of one function to another, and a move from one file to > another. > > Lets not make this into a project when it can be performed by a simple search > and replace and verified with a grep of the source code after the change. > > Too often I've seen these things combine changes, The "while I am at it" patch. I see that Jonathan did break this up the proper way. [AppDb] [try2] util_show_error_page [AppDb] factor exit calls after util_show_error_page On an different note. None of Jonathan's patches show up in the archive. It only shows his PGP signature. http://www.winehq.org/pipermail/wine-patches/2006-June/028079.html -- Tony Lambregts.

June 29, 2006

Re: msiexec: msiexec also supports options using a hyphen

by Alexandre Julliard

"James Hawkins" <truiken(a)gmail.com> writes: > Changelog: > * msiexec also supports options using a hyphen. Surely there's a better way to do this than duplicating all the string compares... -- Alexandre Julliard julliard(a)winehq.org

June 29, 2006

Re: DDraw: Return DDERR_NOPALETTEATTCHED if there is no palette

by Stefan Dösinger

Am Donnerstag 29 Juni 2006 11:40 schrieb Stefan Dösinger: > According to the msdn this should happen, and native d3drm.dll depends on > this > > ChangeLog: > Stefan Dösinger: Return DDERR_NOPALETTEATTCHED if there is no palette Do not apply this patch, it is not completely correct. It breaks palettized textures in the dx7 sdk. I'll write a test case for this

June 29, 2006

Re: Debugging string comparison problem

by Robert Shearman

Juan Lang wrote: >I'm trying to figure out why CompareStringA returns CSTR_EQUAL for the strings "\1" and "\2". (See bug 5469, and the todo_wine test case in dlls/kernel/tests/locale.c) > >CompareStringA does the usual thing, calls MultiByteToWideChar and calls CompareStringW. So CompareStringW is comparing L"\0001" to L"\0002". > >CompareStringW calls wine_compare_string, in libs/unicode/sortkey.c That calls compare_unicode_weights. That has this little bit of code: > ce1 = collation_table[collation_table[*str1 >> 8] + (*str1 & 0xff)]; > ce2 = collation_table[collation_table[*str2 >> 8] + (*str2 & 0xff)]; > >With the strings L"\0001" and L"\0002", *str1 is 0x0001, and *str2 is 0x0002. So *str1 >> 8 is 0, and *str2 >> 8 is 0. *str1 & 0xff is 0x01, *str2 & 0xff is 0x02. So, ce1 == collation_table[1], which is 0x00000300 (in collation.c), and ce2 == collation_table[2], which is 0x00000400. > > You missed the two collation_table lookups. The first lookup is to find an index (the table is stored with some trivial compression). This will be 0x200 for both *str1 and *str2. Then the second lookup is done for collation_table[0x201] and collation_table[0x202] and these are both 0 (see the data beginning with line /* 0x0000 .. 0x00ff */ in collation.c). Note that on Windows using CompareString on L"\0001\0002" and L"\0002\0001" gives a result of CSTR_EQUAL, so I don't think the bug is in the collation tables. -- Rob Shearman

June 29, 2006

winegcc atof() bug?

by Benjamin Fabricius

Hi, Im experiencing weird things when using atof() in certain places of my software and compiling with winegcc (wine20050725). It works fine when calling it out of the main function but as soon as i migrated some routines to another c file things became really strange. atoi works fine but as soon as i use atof with any "x.x" string i keep on getting some negative constant value as it seems. thought this might be HUGE_VAL of strtod but atof doesnt return any errors.. Anybody experience similar problems. unfortunately i am dependent on this wine version.. so changing wine versions won't help since current builds interfere with other parts of the software running in wine. Heres a really simple example code of what im trying to do: --- snip --- void print_set_parameters(char **setparams, int startofparams, int endofparams) { int param_num; double param_value; /* this works fine setparams has got the right * string values */ printf("test %d\n", startofparams); printf("test %s\n", setparams[3]); printf("test %s\n", setparams[4]); for(i = startofparams; i < endofparams; i++) { // works fine! param_num = atoi(setparams[i]); printf("string is %s, param number %d\n", setparams[i],param_num); i++; // heres where the trouble starts param_value = atof(setparams[i]); // tried this as an alternative same problem // param_value = strtod(".1", 0); // no errors reported // perror(__FUNCTION__); printf("param value %f\n", param_value); } } --- snip --- Any help would be great!! Cheers, ..Ben -- ------------------- Benjamin Fabricius German Student Lawo AG

June 29, 2006

Re: [Tools/Wine.inf] Set Internet Explorer version

by H. Verbeet

On 29/06/06, Steven Edwards <winehacker(a)gmail.com> wrote: > Well the default windows version we report is Win2k and if I recall it > shipped with IE5.5 so to be constant we should at least match its > value. Actually, we report Win2k SP4. I think that came with IE6, but I'm not too sure.

June 29, 2006

Re: [TOOLS] Re: Gecko installer

by Boaz Harrosh

Jeremy Newman wrote: > This is now live at: > http://source.winehq.org/winegecko.php > > This is grate! It is Based on SeaMonkey version 1.8.0.1. We might want to do some kind of version system, this thing gets updated pretty fast, security updates and stuff... By the way, How do you make a CAB file is there a free tool to make it? or is it Just a renamed ZIP file? Free Life Boaz

June 29, 2006

Re: [Tools/Wine.inf] Set Internet Explorer version

by Steven Edwards

On 6/29/06, Saulius Krasuckas <saulius2(a)ar.fi.lt> wrote: > If community decides it needs different IE versions, then I guess this > needs to be done somewhere in winecfg, no? Well the default windows version we report is Win2k and if I recall it shipped with IE5.5 so to be constant we should at least match its value. -- Steven Edwards "There is one thing stronger than all the armies in the world, and that is an idea whose time has come." - Victor Hugo

June 29, 2006

Re: [Tools/Wine.inf] Set Internet Explorer version

by Saulius Krasuckas

* On Wed, 28 Jun 2006, Steven Edwards wrote: > * On 6/28/06, Maarten Lankhorst <M.B.Lankhorst(a)gmail.com> wrote: > > > > --- tools/wine.inf.ori 2006-06-28 18:32:28.000000000 +0200 > > +++ tools/wine.inf 2006-06-28 18:35:22.000000000 +0200 > > @@ -2467,3 +2467,6 @@ > > HKLM,%Control%\ProductOptions,"ProductType",2,"WinNT" > > HKLM,%Control%\Windows,"CSDVersion",0x10003,0x400 > > HKLM,%Control%\Session Manager\Environment,"OS",2,"Windows_NT" > > +HKLM,"Software\Microsoft\Internet Explorer","Version",,"6.0.2900.2180" > > +HKLM,"Software\Microsoft\Internet Explorer","W2kVersion",,"6.0.2900.2180" > > +HKLM,"Software\Microsoft\Internet Exlporer","Build",,"62900" > > Does installing IE6 in win98 mode still work after this? I think its > going to have problems. We really should report IE 5 so the IE 5.5 and > 6 installers dont get confused. If community decides it needs different IE versions, then I guess this needs to be done somewhere in winecfg, no?

June 29, 2006

Re: wine autorun utility

by Vijay Kiran Kamuju

hi, I think HAL for linux should handle the automatic mounting and autorunning it take care. So it should be a part of HAL. my 2 cents. bye, VJ On 6/29/06, Ivan Leo Puoti <ivanleo(a)gmail.com> wrote: > Segin Noname wrote: > > So I wrote this little program. > > To be totally honest I don't see the point, in 99.999% of CDs I've ever seen autorun starts some > file in the root folder of the CD (start.exe, setup.exe, install.exe, runme.exe, in any case > something obvious) and the CD usually comes with instructions telling you which one to run, so I > don't see why one would look in the autorun.inf file in the first place, or run the cd with your > program, when they could run the right exe directly. So your program would only be useful if it > worked like the real autorun, pulled the CD drive every second or so, and automatically read the > CD's autorun.inf and started the appropriate exe. Many people (including me) would find that > annoying, but I guess it's a windows feature some people may like. > > Ivan. > > > >

June 29, 2006

Re: msdn calling everything .net now?

by Ivan Leo Puoti

Dan Kegel wrote: > Lately, when I search for win32 API functions like CoGetObject, > the top few hits I get at microsoft.com are the .net ones. > I guess it's not a problem, but it feels weird. Calling everything with a new name is an easy way to get people to think you've got something new, when you haven't. They could call them "the .net win32 API" and some people may actually think it's new stuff. Ivan.

June 29, 2006

Re: wine autorun utility

by Ivan Leo Puoti

Segin Noname wrote: > So I wrote this little program. To be totally honest I don't see the point, in 99.999% of CDs I've ever seen autorun starts some file in the root folder of the CD (start.exe, setup.exe, install.exe, runme.exe, in any case something obvious) and the CD usually comes with instructions telling you which one to run, so I don't see why one would look in the autorun.inf file in the first place, or run the cd with your program, when they could run the right exe directly. So your program would only be useful if it worked like the real autorun, pulled the CD drive every second or so, and automatically read the CD's autorun.inf and started the appropriate exe. Many people (including me) would find that annoying, but I guess it's a windows feature some people may like. Ivan.

June 29, 2006

Re: wine autorun utility

by Ivan Leo Puoti

Segin Noname wrote: > (FYI: I have no internet connection at the moment, so I say 'hi' to > all Wine developers!) > > Wine is nortorious for NOT supporting Autorun. Many people would say that is a fearute. Ivan.

June 29, 2006

Re: automatic winetest builds stopped

by Ivan Leo Puoti

Andrew Ziem wrote: > Maybe a month ago there was a discussion on this list. IIRC, here's the > gist: The build system is broken. Then, someone sent in a patch, but > the maintainer is not at home. Any idea when he'll be able to fix this? Ivan.

June 29, 2006