Some thoughts about the ominous DIB Engine
I have been following this discussion for quite some time and finally decided to look into it a little bit. While the Wiki mentions that a difficult part of this would be to get any design accepted by Alexandre it does absolutely not say in any way what kind of approach would be likely to be accepted, other than it needs to be in small incremental steps. I must admit that I haven't entirely looked through the whole Wine tree yet so I might be missing something but from the old Transgaming patch and some investigation into GDI32 I would see two principal aproaches to add such an interface to Wine. 1) Like in the Transgaming patch hook into winex11.drv where apropriate. 2) Add the dib engine as a dibdrv into GDI32 directly similar to what has been done for enhmfdrv and mfdrv already. Obviously 1) has been tried and seemed to work in some ways eventhough there would still need to be quite some more work to be done. What I don't like about this aproach is that conceptually it seems to add this functionality at the wrong end. If there is ever going to be another display driver than winex11.drv all the hooking would have to be done again and also adding new GDI methods to the driver as development goes always requires also some significant changes to winex11.drv. Not sure if someone ever attempted 2) but IMHO it would place DIB handling where it conceptually should be. The dibdrv function array could be added as extra field to the private DIB data structure and initialized on DIB creation. On non existing DIB methods (NULL pointer) the operation would be simply sent to the display driver as is done now. I believe this could be generalized enough to make it a single time change, with new dibdrv methods getting then available whenever implemented in small incremental patches. Possible problems I could see are however synchronizing with X (not sure if that is really a possible problem as I do not understand X so far) and maybe other drivers such as wine3d3.drv that seem to hook into winex11.drv too (not sure if for DIB related operations). This last one could however be gotten around by implementing the dibdrv as loadable driver too, so that other drivers needing to use operations from it could load it too. I would like to hear comments of anyone that could add something to this and maybe we can then add the result to the wiki page for further reference. As it is now Wiki mostly says it is rather desirable, sort of hard to do and the hardest part would be getting it into Wine at all. Maybe if there is a more clear picture as to how it could be done and what is likely to have a chance to pass Alexandre's critical eyes, there would be a bigger chance of someone trying to get it finally started the right way. Rolf Kalbermatter
Re: [1/9] WineD3D: BeginScene and EndScene tests and fixes
Stefan Dösinger [EMAIL PROTECTED] writes: From 4dc1b3cd7faf9c61bc6f862f416b6af07e1e85e8 Mon Sep 17 00:00:00 2001 From: Stefan Doesinger [EMAIL PROTECTED] Date: Fri, 19 Jan 2007 19:30:09 +0100 Subject: [PATCH] WineD3D: BeginScene and EndScene tests and fixes This causes 'make test' to fail to restore the correct display resolution, it's stuck at 800x600 on exit. -- Alexandre Julliard [EMAIL PROTECTED]
Re: Some thoughts about the ominous DIB Engine
Rolf Kalbermatter wrote: I have been following this discussion for quite some time and finally decided to look into it a little bit. While the Wiki mentions that a difficult part of this would be to get any design accepted by Alexandre it does absolutely not say in any way what kind of approach would be likely to be accepted, other than it needs to be in small incremental steps. I must admit that I haven't entirely looked through the whole Wine tree yet so I might be missing something but from the old Transgaming patch and some investigation into GDI32 I would see two principal aproaches to add such an interface to Wine. 1) Like in the Transgaming patch hook into winex11.drv where apropriate. 2) Add the dib engine as a dibdrv into GDI32 directly similar to what has been done for enhmfdrv and mfdrv already. Obviously 1) has been tried and seemed to work in some ways eventhough there would still need to be quite some more work to be done. What I don't like about this aproach is that conceptually it seems to add this functionality at the wrong end. If there is ever going to be another display driver than winex11.drv all the hooking would have to be done again and also adding new GDI methods to the driver as development goes always requires also some significant changes to winex11.drv. There is already an other display driver: winequartz.drv for MacOS. And Pierre is working to move code out of winex11.drv and into the GDI and User dlls to not have to duplicate it again in winequartz.drv. bye michael -- Michael Stefaniuc Tel.: +49-711-96437-199 Sr. Network EngineerFax.: +49-711-96437-111 Red Hat GmbHEmail: [EMAIL PROTECTED] Hauptstaetterstr. 58http://www.redhat.de/ D-70178 Stuttgart
Re: Some thoughts about the ominous DIB Engine
On Feb 9, 2007, at 5:18 AM, Michael Stefaniuc wrote: Rolf Kalbermatter wrote: I have been following this discussion for quite some time and finally decided to look into it a little bit. While the Wiki mentions that a difficult part of this would be to get any design accepted by Alexandre it does absolutely not say in any way what kind of approach would be likely to be accepted, other than it needs to be in small incremental steps. I must admit that I haven't entirely looked through the whole Wine tree yet so I might be missing something but from the old Transgaming patch and some investigation into GDI32 I would see two principal aproaches to add such an interface to Wine. 1) Like in the Transgaming patch hook into winex11.drv where apropriate. 2) Add the dib engine as a dibdrv into GDI32 directly similar to what has been done for enhmfdrv and mfdrv already. Obviously 1) has been tried and seemed to work in some ways eventhough there would still need to be quite some more work to be done. What I don't like about this aproach is that conceptually it seems to add this functionality at the wrong end. If there is ever going to be another display driver than winex11.drv all the hooking would have to be done again and also adding new GDI methods to the driver as development goes always requires also some significant changes to winex11.drv. There is already an other display driver: winequartz.drv for MacOS. And Pierre is working to move code out of winex11.drv and into the GDI and User dlls to not have to duplicate it again in winequartz.drv. Pierre could speak to this better than I, but my understanding is that the Quartz driver does not need the DIB engine. Quartz (the Mac's imaging and windowing API) is capable of drawing to offscreen bitmaps directly, at color depths that need not match the display's. This has implications for the design of the DIB engine, because it should be designed to allow the graphics driver to override/bypass it. -Ken
Re: Some thoughts about the ominous DIB Engine
Ken Thomases wrote: Pierre could speak to this better than I, but my understanding is that the Quartz driver does not need the DIB engine. Quartz (the Mac's imaging and windowing API) is capable of drawing to offscreen bitmaps directly, at color depths that need not match the display's. This has implications for the design of the DIB engine, because it should be designed to allow the graphics driver to override/bypass it. I suggested to do all the work server-side a while back: http://www.winehq.org/pipermail/wine-devel/2005-July/038695.html Especially see: http://www.winehq.org/pipermail/wine-devel/2005-July/038703.html Now, in my opinion we shouldn't care about those apps but it's not up to me. :) Felix
Re: Some thoughts about the ominous DIB Engine
Felix Nawothnig wrote: Pierre could speak to this better than I, but my understanding is that the Quartz driver does not need the DIB engine. Quartz (the Mac's imaging and windowing API) is capable of drawing to offscreen bitmaps directly, at color depths that need not match the display's. I suggested to do all the work server-side a while back: Uhm, dunno where I just got the idea that Quartz would feature network transparency. Just ignore me. I really need some coffee now.
Questions about gdi32:WidenPath patch sent on jan. 27
Hi, I've tried to send my first patch on jan. 27. This patch is supposed to add a partial implementation of WidenPath to gdi32.dll. After two weeks, I don't have any news about the patch. Is it still pending ? Is there something wrong with it ? I am ready to improve it if necessary, but I need some advice to now what needs to be improved in it. Thank you for your help. Laurent
Re: Some thoughts about the ominous DIB Engine
On 2/9/07, Rolf Kalbermatter [EMAIL PROTECTED] wrote: I have been following this discussion for quite some time and finally decided to look into it a little bit. While the Wiki mentions that a difficult part of this would be to get any design accepted by Alexandre it does absolutely not say in any way what kind of approach would be likely to be accepted, other than it needs to be in small incremental steps. I must admit that I haven't entirely looked through the whole Wine tree yet so I might be missing something but from the old Transgaming patch and some investigation into GDI32 I would see two principal aproaches to add such an interface to Wine. Look at bug 3902 (and 421) for some more ideas. An optimization was suggested to reduce the size of the data copied between wine and the X server, where an invalid rectangle is set/cleared by each drawing function and only the contents of that rectangle (if any) are copied, instead of the entire bitmap. It's not hard to do, but it isn't an overnight thing either - each and every drawing function has to be patched to do this for it to work, and there is a several dozen. Preliminary tests showed some improvements using this approach. And it would still help even if we had a DIB engine, because the volume of data copied would still be lower. My client-side DIB copy patch from bug 3902 was accepted into wine a few versions back, and it already makes a huge difference for some applications and games. 1) Like in the Transgaming patch hook into winex11.drv where apropriate. 2) Add the dib engine as a dibdrv into GDI32 directly similar to what has been done for enhmfdrv and mfdrv already. Obviously 1) has been tried and seemed to work in some ways eventhough there would still need to be quite some more work to be done. What I don't like about this aproach is that conceptually it seems to add this functionality at the wrong end. If there is ever going to be another display driver than winex11.drv all the hooking would have to be done again and also adding new GDI methods to the driver as development goes always requires also some significant changes to winex11.drv. Not sure if someone ever attempted 2) but IMHO it would place DIB handling where it conceptually should be. The dibdrv function array could be added as extra field to the private DIB data structure and initialized on DIB creation. On non existing DIB methods (NULL pointer) the operation would be simply sent to the display driver as is done now. I believe this could be generalized enough to make it a single time change, with new dibdrv methods getting then available whenever implemented in small incremental patches. Possible problems I could see are however synchronizing with X (not sure if that is really a possible problem as I do not understand X so far) and maybe other drivers such as wine3d3.drv that seem to hook into winex11.drv too (not sure if for DIB related operations). X synchronization is done in winex11.drv. Calling X11DRV_LockDIBSection returns where the DIB is, and if it is client-side, you just draw to it by accessing memory - otherwise you draw by using equivalent xlib functions. It would be pointless and extremely difficult making a dibdrv - just patch winex11.drv; dibdrv would need access to many internal X11DRV_ functions. This last one could however be gotten around by implementing the dibdrv as loadable driver too, so that other drivers needing to use operations from it could load it too. I would like to hear comments of anyone that could add something to this and maybe we can then add the result to the wiki page for further reference. As it is now Wiki mostly says it is rather desirable, sort of hard to do and the hardest part would be getting it into Wine at all. Maybe if there is a more clear picture as to how it could be done and what is likely to have a chance to pass Alexandre's critical eyes, there would be a bigger chance of someone trying to get it finally started the right way. The hard part is not the X11 stuff, it is writing drawing algorithms that not only draw in all of 1, 4, 8, 16, 24, and 32 bit colour-depth and are pixel-for-pixel equivalent with the way Windows does them, but the dozens of little things like patterns, brushes, raster ops, custom region clipping, and others which affect each other and almost everything else, making the implementation of a client-side DIB engine a real PITA. Rolf Kalbermatter Damjan Jovanovic
Re: ntdll: Add prototypes to winnt.h for the SList functions.
Francois Gouget [EMAIL PROTECTED] writes: Fix the implementation to match the official prototypes. --- I've had trouble with the placement of 'volatile' in 'const SLIST_HEADER* volatile'. I think putting 'volatile' last is correct because it applies to the pointer, not to the pointed-to data like 'const'. No, it applies to the data, it doesn't make sense to have the pointer itself be volatile. Though it's probably useless either way, and since the SDK prototypes apparently don't have it we shouldn't either. -- Alexandre Julliard [EMAIL PROTECTED]
Re: RasError.h? Where is this or does it not exist?
On Thu, 8 Feb 2007, John Smith wrote: Hey all, I cannot find the raserror.h file. I have tried looking around the wine directories to no avail. A find ./wine -name raserror.h -type f -print turns up nothing. Am I looking in the wrong spot or in the wrong way? I can confirm that it is missing. So feel free to add it as include/raserror.h. But no verbatim copying from the PSDK! Work from the MSDN or other documentation sources. -- Francois Gouget [EMAIL PROTECTED] http://fgouget.free.fr/ The last time religion ruled, it was called the dark ages.
Re: Bugzilla: Adding a 'patch' keyword
Francois Gouget wrote: On Tue, 30 Jan 2007, Francois Gouget wrote: [...] But it would be nice if there was an easy way to find bugs that have a patch, even, and maybe especially, if it is incorrect. This would make it easier for interested parties to survey what potential fixes are languishing in Bugzilla and push them to wine-devel or wine-patches. I see everyone agrees :-/ So could someone add the 'patch' keyword? I had added this keyword when you first asked for it... I just did not comment on it. http://bugs.winehq.org/describekeywords.cgi -- Tony Lambregts
Re: comctl32: rebar: rewrite the layouting code
Robert Shearman napisał(a): Mikołaj Zalewski wrote: I've been trying to fix the rebar layouting code. But fixes in one place caused regressions because of bugs in other places and I ended up rewriting the whole layouting code. It does roughly the same as the current code however the details are quite different and I hope more correct. It's also much shorter so it should be earier to understand/debug. My code work for me for all apps I tested (except for the sidebars of IE but I'm trying to find out why). It also passes some tests I've written and produces identical results that the native. Two things could be potentially better in the old code: - it contains some support for RBBS_FIXEDSIZE (however different from what Windows does) - it can break rows to fill the given space (but that should be only done for RBS_AUTOSIZE rebars) I have yet to test the REBAR_Maximize and REBAR_Minimize but I have two questions. Does this code cause regressions in apps that works with the current code and would such big patch be accepted? I haven't got any apps to test with (other than IE and it looks like you've already tried that), but nice work! I've tested it also with WinRAR, WinSCP3 3.30, 7-Zip and Pirch98 (the last two have Bugzilla entries and are fixed by the new code). The only thing I've found not to work are the sidebars of IE. For the next week I won't work on wine but what should I do later - would such a big patch be accepted? Mikolaj Zalewski
re: comctl32: rebar: rewrite the layouting code
Mikołaj wrote: I've tested it also with WinRAR, WinSCP3 3.30, 7-Zip and Pirch98 (the last two have Bugzilla entries and are fixed by the new code). The only thing I've found not to work are the sidebars of IE. Did they work with the old code? For the next week I won't work on wine but what should I do later - would such a big patch be accepted? As long as it doesn't cause regressions in IE, probably, though adding more conformance tests would make acceptance more likely. I think everyone would be thrilled to see progress in rebar, especially if the code ends up simpler. - Dan -- Wine for Windows ISVs: http://kegel.com/wine/isv
Re: RasError.h? Where is this or does it not exist?
Right oh! We will see perhaps today. A bit of studying to do first though. Thanks for helping me! Regards, John Klehm On 2/9/07, Francois Gouget [EMAIL PROTECTED] wrote: On Thu, 8 Feb 2007, John Smith wrote: Hey all, I cannot find the raserror.h file. I have tried looking around the wine directories to no avail. A find ./wine -name raserror.h -type f -print turns up nothing. Am I looking in the wrong spot or in the wrong way? I can confirm that it is missing. So feel free to add it as include/raserror.h. But no verbatim copying from the PSDK! Work from the MSDN or other documentation sources. -- Francois Gouget [EMAIL PROTECTED] http://fgouget.free.fr/ The last time religion ruled, it was called the dark ages.
Re: Some thoughts about the ominous DIB Engine
On Fr, 2007-02-09 at 11:41 +0100, Rolf Kalbermatter wrote: 1) Like in the Transgaming patch hook into winex11.drv where apropriate. 2) Add the dib engine as a dibdrv into GDI32 directly similar to what has been done for enhmfdrv and mfdrv already. extra field to the private DIB data structure and initialized on DIB creation. On non existing DIB methods (NULL pointer) the operation would be simply sent to the display driver as is done now. I believe this could be generalized enough to make it a single time change, with new dibdrv methods getting then available whenever implemented in small incremental patches. I suggest option 2), but without the need of a Display-Driver at all as the long-term target. The API for that Engine is exported by GDI32 (Eng* ) and when we implement that, we can reuse the API for more drivers (OpenGL, VNC, RDP, SDL, Printer-Drivers ...) The API-declaration for Eng* is in ddk/winddi.h A line from the current wine GDI-Engine as Example: (LineTo from dlls/gdi32/painting.c): cut ret = dc-funcs-pLineTo dc-funcs-pLineTo(dc-physDev,x,y); cut We simple call the Driver, and when the Driver does not support that painting-function, the API failed. On windows, gdi32.dll and the Driver can fallback at any time to Eng* (EngLineTo in the Example) and the drawing is split in more primitive API-calls whith setting a single pixel at the end. (You can think of a Driver, that implement LineTo only for horizontal and vertical lines and fallback to EngLineTo for diagonal lines) So instead of implementing a full DIB-Engine in a dibdrv, we should split the implementation in a logical part (Eng* API) and a drawing part. Possible problems I could see are however synchronizing with X (not sure if I have no Idea, what is needed here. This last one could however be gotten around by implementing the dibdrv as loadable driver too, so that other drivers needing to use operations from it could load it too. When we use Eng*, it's there for all drivers and is the same API as in windows. Thanks for looking at the dib-issue -- By by ... Detlef
Re: comctl32: rebar: rewrite the layouting code
Dan Kegel wrote: Mikołaj wrote: I've tested it also with WinRAR, WinSCP3 3.30, 7-Zip and Pirch98 (the last two have Bugzilla entries and are fixed by the new code). The only thing I've found not to work are the sidebars of IE. Did they work with the old code? WinRAR did. Other had bigger or smaller problems. For the next week I won't work on wine but what should I do later - would such a big patch be accepted? As long as it doesn't cause regressions in IE, probably, though adding more conformance tests would make acceptance more likely. IE sidebars didn't work before and the main toolbar seems to work OK. Even the sidebars seems to work slighty better as some horizontal toolbar are now visible. Next week I'll add some more tests - especially I'd need to test RB_MAXIMIZE/RB_MINIMIZE and changing the band cx. Mikolaj Zalewski
Re: shell32[2/3]: add a confirmation dialog with a Yes to All option
Mikołaj Zalewski wrote:
+SHELL_YESTOALL_MSGBOX DIALOG 200, 100, 280, 90
+STYLE DS_MODALFRAME | WS_POPUP | WS_VISIBLE | WS_CAPTION | WS_SYSMENU
+CAPTION Message
+FONT 8, MS Shell Dlg
+{
+DEFPUSHBUTTON Yes, IDYES, 34, 69, 53, 14, WS_GROUP | WS_TABSTOP
+PUSHBUTTON Yes to all, IDD_YESTOALL, 92, 69, 65, 14, WS_GROUP |
WS_TABSTOP
+PUSHBUTTON No, IDNO, 162, 69, 53, 14, WS_GROUP | WS_TABSTOP
+PUSHBUTTON Cancel, IDCANCEL, 220, 69, 53, 14, WS_GROUP | WS_TABSTOP
+ICON , IDD_ICON, 10, 10, 16, 16
+LTEXT , IDD_MESSAGE, 40, 10, 238, 52, 0
+}
+
The usual convention is that IDD_* are used for IDs of dialogs and IDC_*
are used for IDs of controls.
--
Rob Shearman
Re: shell32[2/3]: add a confirmation dialog with a Yes to All option
The usual convention is that IDD_* are used for IDs of dialogs and IDC_* are used for IDs of controls. The Browse For Folders dialog uses IDD_ for controls and I wanted to follow the convention in this file. Mikolaj Zalewski
Re: comctl32: rebar: rewrite the layouting code
Mikołaj Zalewski wrote: Dan Kegel wrote: Mikołaj wrote: I've tested it also with WinRAR, WinSCP3 3.30, 7-Zip and Pirch98 (the last two have Bugzilla entries and are fixed by the new code). The only thing I've found not to work are the sidebars of IE. Did they work with the old code? WinRAR did. Other had bigger or smaller problems. For the next week I won't work on wine but what should I do later - would such a big patch be accepted? As long as it doesn't cause regressions in IE, probably, though adding more conformance tests would make acceptance more likely. IE sidebars didn't work before and the main toolbar seems to work OK. Even the sidebars seems to work slighty better as some horizontal toolbar are now visible. Next week I'll add some more tests - especially I'd need to test RB_MAXIMIZE/RB_MINIMIZE and changing the band cx. Mikolaj Zalewski Hi, I think Process Explorer (V10.21) benefits from your patch as well. The only issue I've seen so far (with the patch) is minimizing/maximizing the window and when the whole window has to be redrawn (basically the same thing). Without the patch it's far worse. Cheers, Paul.
Wine beta ASIO-driver.
Hello, First let me introduce myself. I am Tor Einar Toennessen ( actually Tønnessen ). I am from Norway. I have followed the development of Wine a little bit on and off over some years ( maybe about 10 ). My main interrest with Wine is in the audio and midi area. I would like to comment on the asio-driver. I think its marvellous that wine has got an ASIO-capable audio-driver. The patch do however no longer apply cleanly to todays git-version. Secondly I had some trouble getting it to work, until I found out that I had to run autoheader not just autoconf in order to to get the symbol HAVE_ASIO_SDK_ASIO_H into config.h (via config.h.in). Also I would like very much that you (Robert Reif isn't it ?) develop the driver a little further. The first thing beeing a control-panel. But what is most import I think , is to make a new patch that works on todays wine, and get it into the ReadMe that one must run autoheader to. In that way more people can make it work and test it out... Tor Einar
Re: Bugzilla: Adding a 'patch' keyword
Tony Lambregts wrote: Francois Gouget wrote: On Tue, 30 Jan 2007, Francois Gouget wrote: [...] But it would be nice if there was an easy way to find bugs that have a patch, even, and maybe especially, if it is incorrect. This would make it easier for interested parties to survey what potential fixes are languishing in Bugzilla and push them to wine-devel or wine-patches. I see everyone agrees :-/ So could someone add the 'patch' keyword? I had added this keyword when you first asked for it... I just did not comment on it. http://bugs.winehq.org/describekeywords.cgi -- Tony Lambregts Thanks. I've added the 'patch' keyword to bug 6323 (numeric keypad) patch that's been submitted but waiting for Alexandre to commit it. Fixes a known issue in World of Warcraft Warcraft, but I would imagine fixes many other apps that use the numeric keypad ?
Re: shell32[3/3]: allow overwriting files in SHFileOperation(FO_COPY) (with confirmation dialogs, fixes bug #7046)
On 2/9/07, Mikołaj Zalewski [EMAIL PROTECTED] wrote: The return codes when the user cancelled the operation as in Vista, as they are more logical and easier to implement than the XP ones. If Microsoft changed them there are probably not many apps that would depend on it. With this change the program in bug #7046 works fine. From 799ff7b7cc6092fbd3e2030c7b4eb84d829b9842 Mon Sep 17 00:00:00 2001 From: =?utf-8?q?Miko=C5=82aj_Zalewski?= [EMAIL PROTECTED] Date: Fri, 9 Feb 2007 16:43:06 +0100 Subject: [PATCH] shell32: allow overwriting files in SHFileOperation(FO_COPY) (with confirmation dialogs) --- dlls/shell32/shell32_Bg.rc |6 ++- dlls/shell32/shell32_Cs.rc |8 ++- dlls/shell32/shell32_De.rc |6 ++- dlls/shell32/shell32_En.rc |8 ++- dlls/shell32/shell32_Eo.rc |6 ++- dlls/shell32/shell32_Es.rc |6 ++- dlls/shell32/shell32_Fi.rc |6 ++- dlls/shell32/shell32_Fr.rc |6 ++- dlls/shell32/shell32_It.rc |6 ++- dlls/shell32/shell32_Ko.rc |6 ++- dlls/shell32/shell32_No.rc |6 ++- dlls/shell32/shell32_Pl.rc |6 ++- dlls/shell32/shell32_Pt.rc |6 ++- dlls/shell32/shell32_Ru.rc |6 ++- dlls/shell32/shell32_Tr.rc |6 ++- dlls/shell32/shell32_Uk.rc |6 ++- dlls/shell32/shell32_main.h|3 +- dlls/shell32/shfldr_unixfs.c |2 +- dlls/shell32/shlfileop.c | 128 +++- dlls/shell32/shresdef.h|1 + dlls/shell32/tests/shlfileop.c | 55 + 21 files changed, 241 insertions(+), 48 deletions(-) diff --git a/dlls/shell32/shell32_Bg.rc b/dlls/shell32/shell32_Bg.rc index 100b9b6..4c4d16b 100644 --- a/dlls/shell32/shell32_Bg.rc +++ b/dlls/shell32/shell32_Bg.rc @@ -165,8 +165,12 @@ STRINGTABLE DISCARDABLE IDS_DELETEITEM_TEXT Наистина ли искате да изтриете '%1'? IDS_DELETEMULTIPLE_TEXT Наистина ли искате да изтриете тези %1 елемента? IDS_DELETESELECTED_TEXT Наистина ли искате да изтриете избраните елементи? - IDS_OVERWRITEFILE_TEXT Наистина ли искате да презапишете %1? + IDS_OVERWRITEFILE_TEXT This folder already contains a file called '%1'.\n\nDo you want to replace it? IDS_OVERWRITEFILE_CAPTION Потвърдете презаписа на файла + IDS_OVERWRITEFOLDER_TEXT This folder already contains a folder named '%1'.\n\n\ + If the files in the destination folder have the same names as files in the\n\ + selected folder they will be replaced. Do you still want to move or copy\n\ + the folder? /* message box strings */ IDS_RESTART_TITLE Рестартиране diff --git a/dlls/shell32/shell32_Cs.rc b/dlls/shell32/shell32_Cs.rc index 6451dbb..8790db4 100644 --- a/dlls/shell32/shell32_Cs.rc +++ b/dlls/shell32/shell32_Cs.rc @@ -163,10 +163,14 @@ STRINGTABLE DISCARDABLE IDS_CREATEFOLDER_CAPTION Chyba pшi pokusu vytvoшit novэ adresбш IDS_DELETEITEM_CAPTION Potvrdit odstranмnн souboru IDS_DELETEFOLDER_CAPTION Potvrdit odstranмnн adresбшe - IDS_OVERWRITEFILE_CAPTION Potvrdit pшepsбnн souboru IDS_DELETEITEM_TEXT Opravdu chcete odstranit '%1'? IDS_DELETEMULTIPLE_TEXT Opravdu chcete odstranit tмchto %1 poloћek? - IDS_OVERWRITEFILE_TEXT Pшejete si pшepsat soubor '%1'? + IDS_OVERWRITEFILE_TEXT This folder already contains a file called '%1'.\n\nDo you want to replace it? + IDS_OVERWRITEFILE_CAPTION Potvrdit pшepsбnн souboru + IDS_OVERWRITEFOLDER_TEXT This folder already contains a folder named '%1'.\n\n\ + If the files in the destination folder have the same names as files in the\n\ + selected folder they will be replaced. Do you still want to move or copy\n\ + the folder? } /* columns in the shellview*/ diff --git a/dlls/shell32/shell32_De.rc b/dlls/shell32/shell32_De.rc index bde62bf..d6cb815 100644 --- a/dlls/shell32/shell32_De.rc +++ b/dlls/shell32/shell32_De.rc @@ -173,8 +173,12 @@ STRINGTABLE DISCARDABLE IDS_TRASHFOLDER_TEXT Sind Sie sich sicher, dass Sie '%1' und seinen Inhalt in den Mьll verschieben mцchten? IDS_TRASHMULTIPLE_TEXT Sind Sie sich sicher, dass Sie diese %1 Dateien in den Mьll verschieben mцchten? IDS_CANTTRASH_TEXT Das Objekt '%1' kann nicht in den Mьll verschoben werden. Mцchten Sie es stattdessen lцschen? - IDS_OVERWRITEFILE_TEXT Mцchten Sie, dass die Datei '%1' ьberschrieben wird ? + IDS_OVERWRITEFILE_TEXT This folder already contains a file called '%1'.\n\nDo you want to replace it? IDS_OVERWRITEFILE_CAPTION Bestдtigung: Datei ьberschreiben + IDS_OVERWRITEFOLDER_TEXT This folder already contains a folder named '%1'.\n\n\ + If the files in the destination folder have the same names as files in the\n\ + selected folder they will be replaced. Do you still want to move or copy\n\ + the folder? /* message box strings
Re: winecfg: Add check for device access to Drives tab.
Any reasons why this patch is not applied? http://www.winehq.org/pipermail/wine-patches/2007-January/035264.html This is one of the major headaches for users trying to get programs requiring direct CD-ROM drive access to work. And it's nearly impossible to get required information from users to find if the direct access actually works or not. If there are some other ways to check this, please let me know. I'm sure everyone who tried to get something like Diablo II working will appreciate it! Vitaliy.
wineboot: Start items in StartUp folder on boot.
Hi,
As you all may have noticed, I have been making quite a few patches
within the last two weeks (or at least quite a few when compared to zero
before then) because I had figured out that the Vector NTI program that
is quite important in molecular biologThis patch makes sure that wine
will start items in the StartUp folder
(Programs) just like Windows. The reason this is necessary, well #1 this
is something Windows does that Wine doesn't do, but #2 this is required
by the Vector NTI installer (bug #7384), which installs necessary
dependencies (MDAC and about 6 other things) by installing one, then
placing a link to itself in StartUp, then rebooting. With this patch, it
will actually restart correctly, and in fact just running wine
installer.exe will actually successfully do the install from start to
finish (for the alternative to install this prior to this and a few
other patches, see my shell script
http://misha680.googlepages.com/InstallVectorNTI10.sh). There is still
the lack of JScript support which fails to install some things, but
that's about it.y (and freely available to academic researchers) can be
installed on Wine and run with quite little problem with a quite
complicated install script I made
http://misha680.googlepages.com/InstallVectorNTI10.sh). There was one
pretty significant bug, but after that I wanted to try to track down and
patch other bugs that forced the above script to be required. With the
exception of a pretty significant lack of JScript support in wine/MSI
which causes installation of quite a few files to fail (and thus still
require native jscript.dll and native MSI), this final patch I just sent
out makes the install work from start to finish, which is quite a change
from before.
I posted two patches earlier (a conformance test and a fix) that adds
path searching to shell link creation (which the conformance test shows
exists in Windows for a file like rundll32.exe that is not found in the
current directory), and if anyone has comments about those patches
please send them to me. My last patch ensures that this shelllink that
the Vector NTI installer creates every time it tries to restart (about
six or so times after every Microsoft component it installs that it
needs and comes with) will be executed, and in fact is meant to
reproduce the Windows behavior of starting items in the StartUp program
group on login that occurs in Windows. I am new to the whole
IShellFolder thing, though, and I tried to make it as proper as I could.
But I certainly feel that I would like to have someone more experience
to look at it.
Oh, and I just wanted to say a big thanks to Dan Kegel, James Hawkings,
Mike McCormack, and others who have helped me so far (not to mention
Alexandre Julliard for committing some of my patches).
Misha
From 446dbc9d3f961bff416e20b3504305763d145a78 Mon Sep 17 00:00:00 2001
From: Misha Koshelev [EMAIL PROTECTED]
Date: Fri, 9 Feb 2007 21:48:21 -0600
Subject: wineboot: Start items in StartUp folder on boot.
---
programs/wineboot/Makefile.in |3 +
programs/wineboot/wineboot.c | 92 +
2 files changed, 93 insertions(+), 2 deletions(-)
diff --git a/programs/wineboot/Makefile.in b/programs/wineboot/Makefile.in
index 08c27a5..bf1b723 100644
--- a/programs/wineboot/Makefile.in
+++ b/programs/wineboot/Makefile.in
@@ -4,7 +4,8 @@ SRCDIR= @srcdir@
VPATH = @srcdir@
MODULE= wineboot.exe
APPMODE = -mconsole
-IMPORTS = version user32 advapi32 kernel32
+IMPORTS = version user32 advapi32 kernel32 shell32 shlwapi
+EXTRALIBS = -luuid
C_SRCS = \
shutdown.c \
diff --git a/programs/wineboot/wineboot.c b/programs/wineboot/wineboot.c
index 1434003..bda10b1 100644
--- a/programs/wineboot/wineboot.c
+++ b/programs/wineboot/wineboot.c
@@ -63,6 +63,12 @@ #endif
#include windows.h
#include wine/debug.h
+#define COBJMACROS
+#include shlobj.h
+#include shobjidl.h
+#include shlwapi.h
+#include shellapi.h
+
WINE_DEFAULT_DEBUG_CHANNEL(wineboot);
#define MAX_LINE_LENGTH (2*MAX_PATH+2)
@@ -616,6 +622,88 @@ static int ProcessWindowsFileProtection(
return 1;
}
+/* Process items in the StartUp group of the user's Programs under the Start
Menu. Some installers put
+ * shell links here to restart themselves after boot. */
+static BOOL ProcessStartupItems()
+{
+BOOL ret = FALSE;
+HRESULT hr;
+int iRet;
+IMalloc *ppM = NULL;
+IShellFolder *psfDesktop = NULL, *psfStartup = NULL;
+LPITEMIDLIST pidlStartup = NULL, pidlItem;
+ULONG NumPIDLs;
+IEnumIDList *iEnumList = NULL;
+STRRET strret;
+WCHAR wszCommand[MAX_PATH];
+
+WINE_TRACE(Processing items in the StartUp folder.\n);
+
+hr = SHGetMalloc(ppM);
+if (FAILED(hr))
+{
+ WINE_ERR(Couldn't get IMalloc object.\n);
+ goto done;
+}
+
+hr = SHGetDesktopFolder(psfDesktop);
+if (FAILED(hr))
+{
+ WINE_ERR(Couldn't get desktop folder.\n);
+ goto done;
+}
+
+hr =
Re: wineboot: Start items in StartUp folder on boot.
Misha Koshelev wrote: Hi, As you all may have noticed, I have been making quite a few patches within the last two weeks (or at least quite a few when compared to zero before then) because I had figured out that the Vector NTI program that is quite important in molecular biologThis patch makes sure that wine will start items in the StartUp folder IMHO this should not be fixed. I've seen lots and lots of malicious programs using this mechanism to start themselves. And even worse if installer uses this to restart itself. That means this installer might not work most of the time on windows. Vitaliy.
Re: wineboot: Start items in StartUp folder on boot.
On Fri, 2007-02-09 at 21:20 -0700, Vitaliy Margolen wrote: Misha Koshelev wrote: Hi, As you all may have noticed, I have been making quite a few patches within the last two weeks (or at least quite a few when compared to zero before then) because I had figured out that the Vector NTI program that is quite important in molecular biologThis patch makes sure that wine will start items in the StartUp folder IMHO this should not be fixed. I've seen lots and lots of malicious programs using this mechanism to start themselves. And even worse if installer uses this to restart itself. That means this installer might not work most of the time on windows. Vitaliy. Well that is fair if that is the consensus. I did try the installer on a plain Win98 system and this restart does work for it there. Maybe have some kind of option to optionally do this or is that out of the question too? Thanks for the info. Misha
Re: wineboot: Start items in StartUp folder on boot.
I thought wine's goal was bug for bug with windows, for good or for ill. On 2/9/07, Misha Koshelev [EMAIL PROTECTED] wrote: On Fri, 2007-02-09 at 21:20 -0700, Vitaliy Margolen wrote: Misha Koshelev wrote: Hi, As you all may have noticed, I have been making quite a few patches within the last two weeks (or at least quite a few when compared to zero before then) because I had figured out that the Vector NTI program that is quite important in molecular biologThis patch makes sure that wine will start items in the StartUp folder IMHO this should not be fixed. I've seen lots and lots of malicious programs using this mechanism to start themselves. And even worse if installer uses this to restart itself. That means this installer might not work most of the time on windows. Vitaliy. Well that is fair if that is the consensus. I did try the installer on a plain Win98 system and this restart does work for it there. Maybe have some kind of option to optionally do this or is that out of the question too? Thanks for the info. Misha
