February 2007 - Wine-Devel - list.winehq.org

Re: [Janitorial] snmpapi: Remove the last-but-one %ll printf format

by Eric Pouech

Pedro Araujo Chaves Jr. a écrit : > case ASN_COUNTER64: > { > - TRACE("Counter64 %llu\n", any->asnValue.counter64.QuadPart); > + TRACE("Counter64 %su\n", wine_dbgstr_longlong(any->asnValue.counter64.QuadPart)); > it should read %s\n"... A+

Feb. 14, 2007

Re: [1/10] - [10/10] WineD3D

by Mirek

Wow, great work!!!!! 3DMark 2006 with fbo looks realy coool!! And some Nvidia SDK demos are completly fixed! Mirek Stefan Dösinger napsal(a): > > ------------------------------------------------------------------------ > > From c59f7c4eea148cfb9a1321bbbbc587ef52194bc9 Mon Sep 17 00:00:00 2001 > From: Stefan Doesinger <stefan(a)codeweavers.com> > Date: Fri, 2 Feb 2007 15:30:34 +0100 > Subject: [PATCH] WineD3D: Properly release the converted vertex declaration > > --- > dlls/d3d9/d3d9_private.h | 5 +++++ > dlls/d3d9/device.c | 3 +++ > dlls/d3d9/vertexdeclaration.c | 5 +++++ > 3 files changed, 13 insertions(+), 0 deletions(-) > > diff --git a/dlls/d3d9/d3d9_private.h b/dlls/d3d9/d3d9_private.h > index 435a37e..972945d 100644 > --- a/dlls/d3d9/d3d9_private.h > +++ b/dlls/d3d9/d3d9_private.h > @@ -179,6 +179,11 @@ typedef struct IDirect3DDevice9Impl > /* Avoids recursion with nested ReleaseRef to 0 */ > BOOL inDestruction; > > + /* A vertex declaration was converted from setFVF. > + * Keep track of it, so it can be properly freed > + */ > + IDirect3DVertexDeclaration9 *convertedDecl; > + > } IDirect3DDevice9Impl; > > > diff --git a/dlls/d3d9/device.c b/dlls/d3d9/device.c > index 4eff550..e6ecd96 100644 > --- a/dlls/d3d9/device.c > +++ b/dlls/d3d9/device.c > @@ -62,6 +62,8 @@ static ULONG WINAPI IDirect3DDevice9Impl_Release(LPDIRECT3DDEVICE9 iface) { > > if (ref == 0) { > This->inDestruction = TRUE; > + if (This->convertedDecl != NULL) > + IUnknown_Release(This->convertedDecl); > IWineD3DDevice_Uninit3D(This->WineD3DDevice, D3D9CB_DestroyDepthStencilSurface, D3D9CB_DestroySwapChain); > IWineD3DDevice_Release(This->WineD3DDevice); > HeapFree(GetProcessHeap(), 0, This); > @@ -766,6 +768,7 @@ HRESULT WINAPI IDirect3DDevice9Impl_SetFVF(LPDIRECT3DDEVICE9 iface, DWORD FVF) > > hr = IDirect3DDevice9Impl_SetVertexDeclaration(iface, pDecl); > if (hr != S_OK) goto exit; > + This->convertedDecl = pDecl; > pDecl = NULL; > > exit: > diff --git a/dlls/d3d9/vertexdeclaration.c b/dlls/d3d9/vertexdeclaration.c > index a7f5486..c3f462e 100644 > --- a/dlls/d3d9/vertexdeclaration.c > +++ b/dlls/d3d9/vertexdeclaration.c > @@ -360,6 +360,11 @@ HRESULT WINAPI IDirect3DDevice9Impl_SetVertexDeclaration(LPDIRECT3DDEVICE9 ifa > > TRACE("(%p) : Relay\n", iface); > > + if (This->convertedDecl && This->convertedDecl != pDecl) { > + IUnknown_Release(This->convertedDecl); > + This->convertedDecl = NULL; > + } > + > hr = IWineD3DDevice_SetVertexDeclaration(This->WineD3DDevice, pDeclImpl == NULL ? NULL : pDeclImpl->wineD3DVertexDeclaration); > > return hr; > > > ------------------------------------------------------------------------ > >

Feb. 14, 2007

WINSPOOL: search for a printer driver

by Vitaly Lipatov

When wine is loading, CUPS_LoadPrinters function get printer list from CUPS and add printer and their printer drivers to registry. If printer is already exist, we do not override nor printer driver, nor printer entry. It all works fine. Note, we place printer driver in "Windows 4.0" registry entry if Wine version is win9x and use "Windows NT x86" registry entry if Wine version is win2000 and above. If we will change wine version after printer loaded, Wine printing is got failed. Wine search in empty registry entry. For example, I get such configuration after run wine in win98 mode: [System\\CurrentControlSet\\Control\\Print\\Environments\\Windows 4.0\\Drivers\\hp] 1171461136 "Configuration File"="wineps16" "Data File"="<datafile?>" "Datatype"="RAW" "Dependent Files"=str(7):"<dependent files?>\0" "Driver"="wineps16" "Help File"="<helpfile?>" "Monitor"="<monitor name?>" "Version"=dword:00000000 [System\\CurrentControlSet\\Control\\Print\\Environments\\Windows NT x86\\Drivers\\Version-3] 1171461821 [System\\CurrentControlSet\\Control\\Print\\Printers\\hp] 1171461818 "Attributes"=dword:00000000 "Datatype"="RAW" "Default DevMode"=hex:68,70,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,\ ... "Description"="WINEPS Printer using CUPS" "Location"="<physical location of printer>" "Name"="hp" "Parameters"="<parameters?>" "Port"="LPR:hp" "Print Processor"="WinPrint" "Printer Driver"="hp" ... I try to find a better way to resolve this problem. Some ideas: 1. Check if Wine version is changed and reset printer drivers. 2. Search in both registry entry in any way. 3. ... -- Vitaly Lipatov, ALT Linux Team Russia, Saint-Petersburg, www.etersoft.ru

Feb. 14, 2007

Re: GPU performance counters, agp usage

by Stefan Dösinger

Am Mittwoch 14 Februar 2007 10:16 schrieb Francois Gouget: > On Wed, 14 Feb 2007, Stefan Dösinger wrote: > [...] > > > Regarding the 75% idle, I think that is comparably ok. Native ut2004 > > shows the same behavior. So either the games are broken, or I have a way > > to overpowered gpu(geforce 7600) for my cpu(athlon 64 X2 dual core > > 3800+). > > You really need to compare that to what you get on Windows (but maybe > this is what you mean by 'native ut2004' having the same problem?). > Otherwise it could also mean that our some part of Wine is > taking way too much CPU compared to Windows. Maybe Direct3D or too much > ping pong between Wine and the Wine server, or something else. Yes, I thought about that. Though atm I am more interested about the reported agp usage, which behaves differently in linux apps. Actually, wined3d usually takes only 5% cpu time in nice games, the rest is split up on the game and 3d driver(usually 60% driver, 35% game). I think that windows uses some marshalling to move the driver to another thread, which will help on dual core machines. I think its time to get a windows license for my other machine :-/

Feb. 14, 2007

Re: wined3d: The sims regression

by Stefan Dösinger

Am Mittwoch 14 Februar 2007 03:36 schrieb Alessandro Pignotti: > Hi, > I've noticed that commit 12252d058914a66f40e976484cc7d8aa52ffca47 on the > git tree causes a regression in the sims, making characters flipped upside > down. It's seems to me that the y axis is flipped. > I hope this helps Oops :-( Is there a demo for this game I could use to debug this?

Feb. 14, 2007

Re: test.winehq.com status

by Hans Leidekker

On Wednesday 14 February 2007, Paul Vriens wrote: > Maybe we should start thinking (again) of having several sources for the > winetest executable. The only issue I'm seeing there is that the builds could be > different (if build by different people at an unknown time of the day/state of > GIT) hence test.winehq.org should make a distinction as well (to not compare > apples with pears). Many if not most failures are due to missing imports on MinGW. Using Wine's import libraries should make the service more robust, at the cost of somewhat reduced testing exposure. -Hans

Feb. 14, 2007

Re: GPU performance counters, agp usage

by Francois Gouget

On Wed, 14 Feb 2007, Stefan Dösinger wrote: [...] > Regarding the 75% idle, I think that is comparably ok. Native ut2004 shows the > same behavior. So either the games are broken, or I have a way to overpowered > gpu(geforce 7600) for my cpu(athlon 64 X2 dual core 3800+). You really need to compare that to what you get on Windows (but maybe this is what you mean by 'native ut2004' having the same problem?). Otherwise it could also mean that our some part of Wine is taking way too much CPU compared to Windows. Maybe Direct3D or too much ping pong between Wine and the Wine server, or something else. -- Francois Gouget <fgouget(a)free.fr> http://fgouget.free.fr/ If it stinks, it's chemistry. If it moves, it's biology. If it does not work, It's computer science.

Feb. 14, 2007

Re: test.winehq.com status

by Paul Vriens

Lei Zhang wrote: > On 1/31/07, Paul Vriens <paul.vriens.wine(a)gmail.com> wrote: >> Felix Nawothnig wrote: >> > Hi. Anyone knows what happened to test.winehq.com/data? There has been >> > no new crossbuilds for quite some time now... >> > >> > Felix >> > >> > >> > >> Hi, >> >> I did sent an email to Paul Millar, but no reply yet. You can see what >> goes >> wrong with the build btw.: >> >> http://quisquiliae.ph.gla.ac.uk/crossbuild-logs/ >> >> Cheers, >> >> Paul. >> >> >> >> > > Any news? It's been a couple weeks... > > > Hi, Maybe we should start thinking (again) of having several sources for the winetest executable. The only issue I'm seeing there is that the builds could be different (if build by different people at an unknown time of the day/state of GIT) hence test.winehq.org should make a distinction as well (to not compare apples with pears). Cheers, Paul.

Feb. 14, 2007

Re: Declare some WinXP related structures

by Dmitry Timoshkov

"Kovács András" <andras(a)csevego.net> wrote: > --- a/include/winuser.h > +++ b/include/winuser.h > @@ -1055,6 +1055,51 @@ BOOL WINAPI SetSysColors(INT,const INT*,const COLORREF*); > #define WM_GETICON 0x007f > #define WM_SETICON 0x0080 > > + /* Windows XP messages */ > +#define WM_INPUT 0x00FF Please don't add this kind of a comment, even if it's true for this particular message, it may not belong to all messages below this one. > + /* Windows XP related raw input structures */ > +typedef struct tagRAWINPUTDEVICE { You have added a bunch of structures in the middle of the message definitions, please find a better place. -- Dmitry.

Feb. 14, 2007

wined3d: The sims regression

by Alessandro Pignotti

Hi, I've noticed that commit 12252d058914a66f40e976484cc7d8aa52ffca47 on the git tree causes a regression in the sims, making characters flipped upside down. It's seems to me that the y axis is flipped. I hope this helps Bye Alessandro Pignotti -- Vi Veri Veniversum Vivus Vici -Dr. Faustus - Marlowe Public GPG Key ID 0x650B3ED9 on subkeys.gpg.net Key Fingerprint 6243 AAD3 E3EC 52D8 DFAA 2A2F 9FCD 0457 650B 3ED9 Encrypted mails are welcome

Feb. 14, 2007

Re: test.winehq.com status

by Lei Zhang

On 1/31/07, Paul Vriens <paul.vriens.wine(a)gmail.com> wrote: > Felix Nawothnig wrote: > > Hi. Anyone knows what happened to test.winehq.com/data? There has been > > no new crossbuilds for quite some time now... > > > > Felix > > > > > > > Hi, > > I did sent an email to Paul Millar, but no reply yet. You can see what goes > wrong with the build btw.: > > http://quisquiliae.ph.gla.ac.uk/crossbuild-logs/ > > Cheers, > > Paul. > > > > Any news? It's been a couple weeks...

Feb. 14, 2007

Re: opengl

by Tom Wickline

On 2/13/07, gaosheng <gs(a)crosslight.com.cn> wrote: > Hi: > I want to use opengl with wine. > > //----Here is my glxinfo. > > server glx vendor string:SGI > server glx version string:1.2 > > client glx vendor string:SGI > client glx version string:1.2 > > OpengGL vendor string:Mesa project:www.mesa3d.org > OpengGL renderer string:Mesa GLX Indirect > OpengGL version string:1.3 Mesa 4.0.4 > //------ > > I can't init opengl. when ChoosePixel(), it failed. > Can you tell me the reason. You will need to have direct rendering, and to see if its currently activated (status) you can grep glxinfo : $ glxinfo | grep direct You will want to make sure it says Yes tom(a)prostar ~ $ glxinfo | grep direct direct rendering: Yes tom(a)prostar ~ $ You may also need to update your module section in your X.org conf file You will want to turn off dri and turn glx on. # Load "dri" Load "glx" You may also want to grep the vendor tom(a)prostar ~ $ glxinfo | grep vendor server glx vendor string: NVIDIA Corporation client glx vendor string: NVIDIA Corporation OpenGL vendor string: NVIDIA Corporation tom(a)prostar ~ $ You can run 'glxgears' before and after also, here it makes a huge difference. tom(a)prostar ~ $ glxgears 54378 frames in 5.0 seconds = 10875.471 FPS 54802 frames in 5.0 seconds = 10960.384 FPS 54775 frames in 5.0 seconds = 10954.939 FPS tom(a)prostar ~ $ Cheers, Tom > > Best regards > gao sheng >

Feb. 14, 2007

Re: [4/9] d3d8: Add an IDirect3DVertexDeclaration8 class to hold the wined3d vertex declaration

by Ivan Gyurdiev

> > The idea of this patch and the next few is to create an internal d3d8 > object to hold the wined3d declaration and give the d3d8 vertex shader > a field to hold the d3d8 vertex declaration object. Setting the d3d8 > vertex shader will then set both the wined3d shader and the wined3d > vertex declaration. Excellent. I don't know if the implementation works, but the idea is certainly on the right track. This was done incorrectly to begin with, and also made it difficult to remove the dependency on d3d8/d3d9 includes (which I see you're on track to complete). Ivan

Feb. 14, 2007

GPU performance counters, agp usage

by Stefan Dösinger

Hi, I've had a look at various performance counters of my nvidia card with nvperfkit and nvperfgraph while running half-life 2. The first thing I noticed was that the gpu was approximately 75% to 90% idle, while one cpu core was 100% busy and the other completely idle. More to that later. The other interesting thing was that "OGL driver waiting" was at 100% and agp usage was beyond what nvperfgraph could show. This seems to happen with any application that uses opengl in wine, including very simple d3d apps(Moto racer 2, Direct3D1) and opengl apps(Jedi academy). when the application quits the counters fall back to 0 immediately. On the other hand, a native Linux application(ut2004, 64 bit) does not cause any change in the driver waiting and the agp usage stays at zero. (makes me wonder a bit how useful those counters are). For wine it is enough to successfully create a d3d device or opengl context. Just a IDirect3D9::CreateDevice does it. Regarding the 75% idle, I think that is comparably ok. Native ut2004 shows the same behavior. So either the games are broken, or I have a way to overpowered gpu(geforce 7600) for my cpu(athlon 64 X2 dual core 3800+). Any ideas regarding the agp usage? Could a badly chosen pixel format cause the trouble? Cheers, Stefan

Feb. 14, 2007

Re: compiling out debugging messages?

by Michael Stefaniuc

Lei Zhang wrote: > On 2/12/07, Michael Stefaniuc <mstefani(a)redhat.com> wrote: >> Lei Zhang wrote: >> > Also, the patch from 2007/04/17 only removed -DWINE_NO_DEBUG_MSGS / >> > -DWINE_NO_TRACE_MSGS from configure, but not from >> > include/wine/debug.h. >> Right, it was a problem with a lot of people turning debug messages off >> and sending in useless problem reports. So that option got removed from >> configure. There is one valid reason to turn debugging off and that is >> to cross check that there are no side effects hidden in some debug >> message. >> >> > On 2/12/07, Lei Zhang <thestig(a)google.com> wrote: >> >> Hi, >> >> >> >> Is it still possible to compile out debugging messages? According to >> >> http://winehq.org/site/docs/winedev-guide/dbg-compiling, I can pass >> >> --disable-debug, but the Changelog says that option was removed about >> >> 10 month ago. >> > > Well, we should update the documentation either by removing section > 2.6 or mention passing -DWINE_NO_{DEBUG/TRACE}_MSGS instead. Removing that part of the documentation is probably best. Somebody really wanting to disable that will figure it out for himself. bye michael -- Michael Stefaniuc Tel.: +49-711-96437-199 Sr. Network Engineer Fax.: +49-711-96437-111 Red Hat GmbH Email: mstefani(a)redhat.com Hauptstaetterstr. 58 http://www.redhat.de/ D-70178 Stuttgart

Feb. 13, 2007

Re: Add RegisterRawInputDevices stub implementation

by Felix Nawothnig

Kovács András wrote: > +BOOL WINAPI RegisterRawInputDevices(PRAWINPUTDEVICE pRawInputDevices, UINT uiNumDevices, UINT cbSize) > +{ > +int i; Please keep the indentation style of the original file.

Feb. 13, 2007

Re: Starting work on wine (Direct X Help)

by Nathan Williams

Oh, my apologies, i thought i had the terminology down pat, but i guess not! I added a comment correcting myself on the appdb. On the actual code, i think the bug lies somewhere in: IWineD3DPaletteImpl_SetEntries During the menus this is called repeatedly. Which looking at the source (wined3d/palette.c) there is a comment about problems with depth conversion (which Carmageddon runs in 8 bit) so I'm working on the assumption thats where the problem lies. Tonight I plan to do some testing on that to see what i can find. On 2/13/07, Stefan Dösinger <stefandoesinger(a)gmx.at> wrote: > > wine explorer /desktop=foo,640x480 CARM95.EXE > Yes, you're mangling the terminology here. What you do here is a virtual > desktop. Managed mode means that the windows are managed by the X11 window > manager(so they have the window decorations like Linux apps and can be > minimized as normal), while unmanaged mode means that wine manages them, > they > have windows 95-style decos and stay on top of all Linux apps. Managed > mode > is the default, I think you can enable unmanaged mode with a registry > switch. > > -- Nathan

Feb. 13, 2007

Re: opengl

by Stefan Dösinger

Am Dienstag 13 Februar 2007 19:39 schrieb Vitaly Lipatov: > В сообщении от 13 февраля 2007 20:53 Stefan Dösinger написал(a): > > Am Dienstag 13 Februar 2007 10:13 schrieb gaosheng: > > > OpengGL renderer string:Mesa GLX Indirect > > > > is your reason. You do not have a 3D driver installed or properly set up > > Why we can't use software rendering? Actually it does work, but the other thing with this glxinfo is that its way too short(like he has no glx at all). And mesa indirect won't give satisfying results, even though it should work good enought to give some output.

Feb. 13, 2007

Re: version: Constify a formal parameter of VerQueryValue{A|W}()

by Felix Nawothnig

Andrew Talbot wrote: > I've seen this function represented with the first two parameters > constified. Is anyone aware of a more const-correct version in the field > than the one Felix mentions? Sorry about that, seems they changed the declaration in the new headers - I misinterpreted your comment about the first parameter. What's the problem with it anyway? Just keep adding "const" to internal functions until the warnings disappear. :) Felix

Feb. 13, 2007

Re: Bug 50

by Pedro Araujo Chaves Jr.

Hi all, I'm writing just to ask why my patch and test case for Bug 50 (the text justification issue) weren't committed yet, so that I can take the proper measures in order that they can be. Regards, Pedro.

Feb. 13, 2007

Re: comctl32: move up-down msg seq tests into new 'msg' test

by Felix Nawothnig

James Hawkins wrote: > This is not what needs to happen. The generic message sequence > testing code needs to be factored into msg.c, but the specific tests > need to stay in each control's test file. Guessed so... How about putting it into include/wine/test.h to share the code with user32/msg? Wouldn't help object size but I don't think a shared lib would be worth it... Felix

Feb. 13, 2007

Re: comctl32: move up-down msg seq tests into new 'msg' test

by James Hawkins

On 2/13/07, Felix Nawothnig <flexo(a)holycrap.org> wrote: > James Hawkins wrote: > > This is not what needs to happen. The generic message sequence > > testing code needs to be factored into msg.c, but the specific tests > > need to stay in each control's test file. > > Guessed so... How about putting it into include/wine/test.h to share the > code with user32/msg? Wouldn't help object size but I don't think a > shared lib would be worth it... > No, comctl32's message sequence testing code is different than user32's, and will be even more different when I add in WM_NOTIFY testing support. -- James Hawkins

Feb. 13, 2007

Re: comctl32: move up-down msg seq tests into new 'msg' test

by James Hawkins

On 2/13/07, Felix Nawothnig <flexo(a)holycrap.org> wrote: > Figured you might want a test for my listview patch - so first this. > > Didn't really change anything, still passed on XP SP2. > --- > dlls/comctl32/tests/Makefile.in | 1 + > dlls/comctl32/tests/msg.c | 523 > +++++++++++++++++++++++++++++++++++++++ > dlls/comctl32/tests/updown.c | 435 +-------------------------------- > 3 files changed, 532 insertions(+), 427 deletions(-) > This is not what needs to happen. The generic message sequence testing code needs to be factored into msg.c, but the specific tests need to stay in each control's test file. -- James Hawkins

Feb. 13, 2007

Re: opengl

by Vitaly Lipatov

В сообщении от 13 февраля 2007 20:53 Stefan Dösinger написал(a): > Am Dienstag 13 Februar 2007 10:13 schrieb gaosheng: > > OpengGL renderer string:Mesa GLX Indirect > > is your reason. You do not have a 3D driver installed or properly set up Why we can't use software rendering? -- Vitaly Lipatov, ALT Linux Team Russia, Saint-Petersburg, www.etersoft.ru

Feb. 13, 2007

Re: compiling out debugging messages?

by Lei Zhang

On 2/12/07, Michael Stefaniuc <mstefani(a)redhat.com> wrote: > Lei Zhang wrote: > > Also, the patch from 2007/04/17 only removed -DWINE_NO_DEBUG_MSGS / > > -DWINE_NO_TRACE_MSGS from configure, but not from > > include/wine/debug.h. > Right, it was a problem with a lot of people turning debug messages off > and sending in useless problem reports. So that option got removed from > configure. There is one valid reason to turn debugging off and that is > to cross check that there are no side effects hidden in some debug message. > > > On 2/12/07, Lei Zhang <thestig(a)google.com> wrote: > >> Hi, > >> > >> Is it still possible to compile out debugging messages? According to > >> http://winehq.org/site/docs/winedev-guide/dbg-compiling, I can pass > >> --disable-debug, but the Changelog says that option was removed about > >> 10 month ago. > > bye > michael > -- > Michael Stefaniuc Tel.: +49-711-96437-199 > Sr. Network Engineer Fax.: +49-711-96437-111 > Red Hat GmbH Email: mstefani(a)redhat.com > Hauptstaetterstr. 58 http://www.redhat.de/ > D-70178 Stuttgart > Well, we should update the documentation either by removing section 2.6 or mention passing -DWINE_NO_{DEBUG/TRACE}_MSGS instead.

Feb. 13, 2007

Re: version: Constify a formal parameter of VerQueryValue{A|W}()

by Andrew Talbot

Felix Nawothnig wrote: > Andrew Talbot wrote: >> -BOOL WINAPI VerQueryValueA( LPVOID pBlock, LPSTR lpSubBlock, >> +BOOL WINAPI VerQueryValueA( LPVOID pBlock, LPCSTR lpSubBlock, > > This is wrong - in the PSDK headers it's LPSTR (the first parameter > should be const though). > > Felix I've seen this function represented with the first two parameters constified. Is anyone aware of a more const-correct version in the field than the one Felix mentions? -- Andy.

Feb. 13, 2007

Re: opengl

by Stefan Dösinger

Am Dienstag 13 Februar 2007 10:13 schrieb gaosheng: > OpengGL renderer string:Mesa GLX Indirect is your reason. You do not have a 3D driver installed or properly set up

Feb. 13, 2007

Re: AppDB performance issue

by Bryan Haskins

I was just replying, and reading now, no slow down at all. It loads a little slow running through all that text, but no where near the minutes everyone says it takes them, even on dialup. On 2/13/07, Nick Law <nlaw(a)nildram.co.uk> wrote: > > Bryan Haskins wrote: > > Weird I'm on dial-up even and goto the same pages, and all around the > > wine sites, all the time, and they load surprisingly fast. > > > > On 2/12/07, *Nick Law* <nlaw(a)nildram.co.uk > > <mailto:nlaw(a)nildram.co.uk>> wrote: > >> Nick Law wrote: > >> > Tony Lambregts wrote: > >> >> Chris Morgan wrote: > >> >> > >> >>> On 2/11/07, Tony Lambregts <tony.lambregts(a)gmail.com > >> <mailto:tony.lambregts(a)gmail.com>> wrote: > >> >>> > >> >>>> Nick Law wrote: > >> >>>> > >> >>>>> Hi Tony, > >> >>>>> Just lately, I've noticed that AppDB seems to be very slow, i.eit > >> >>>>> can > >> >>>>> take15 seconds or more for a page to come up or simply to > >> login. Is > >> >>>>> there a bandwidth problem or is the server getting overwhelmed > >> or is > >> >>>>> it a problem at my end (UK). 30 seconds later it's back to > >> being very > >> >>>>> responsive as if the server was a bit overloaded for 30 seconds > or > >> >>>>> so. > >> >>>>> Other websites I try at the time work fine including winehq. Is > >> >>>>> winehq > >> >>>>> on a different server ? > >> >>>>> > >> >>>>> > >> >>>> I have noticed this too and it is very annoying. Yes > >> www.winehq.org <http://www.winehq.org> > >> >>>> qpdb.winehq.or and bugs.winehq.org <http://bugs.winehq.org> are > >> all on the same server. > >> >>>> > >> >>>> Winehq and bugzilla are quite snappy but the AppDB is a pig now. > >> >>>> > >> >>>> I have know idea what is wrong > >> >>>> > >> >>>> -- > >> >>>> > >> >>>> Tony Lambregst > >> >>>> > >> >>>> > >> >>>> > >> >>>> > >> >>> Are particular pages slow? I'm not seeing slow page loads to the > >> main > >> >>> page or to an application version page from here, a few seconds for > >> >>> each. > >> >>> > >> >>> Chris > >> >>> > >> >>> > >> >>> > >> >> > >> >> I see it when doing administration ie accepting or rejectiong > >> >> applications and > >> >> versions (maybe its the way we send emails). > >> >> > >> >> > >> >> -- > >> >> > >> >> Tony Lambregts > >> >> . > >> > > >> > Yes, ditto. Logging in to do admin tasks, but not only that, if I > >> > click on the link in an email from somebody that has posted to the > >> > WoW 2.0.x page it will take 30 seconds for the page to appear. > >> > > >> > I just posted some replies to the wow page and then clicked on the > >> > link in the email and it took 84 seconds for the page to appear. It > >> > find it seems to be more frequent now, maybe every other page or 1 in > >> > three pages are very slow. > >> > > >> > Nick > >> > > >> > > >> Correction it seems to be bad at the moment, the last 4 pages are slow, > >> 60-90 secs before they display, and now it's back to < 2seconds to > >> display a page again, it's like some process on the server hogs the CPU > >> for 60 secs intermittently. > >> > >> Nick > >> > >> > >> > >> -- > >> Cheers, > >> Bryan > >> > ------------------------------------------------------------------------ > >> > >> > >> > Do you click on the links in the emails received from appdb(a)winehq.org > to take you to the posts on the WoW AppDB page ? That's where I often > see the problem. For instance this is a link to your recent post > > http://appdb.winehq.org/appview.php?iVersionId=6482&mode=nested#Comment-181… > which takes over a minute to load, then 5 minutes later I try again and > it loads in < 2secs. > > Nick > -- Cheers, Bryan

Feb. 13, 2007

Re: version: Constify a formal parameter of VerQueryValue{A|W}()

by Felix Nawothnig

Andrew Talbot wrote: > -BOOL WINAPI VerQueryValueA( LPVOID pBlock, LPSTR lpSubBlock, > +BOOL WINAPI VerQueryValueA( LPVOID pBlock, LPCSTR lpSubBlock, This is wrong - in the PSDK headers it's LPSTR (the first parameter should be const though). Felix

Feb. 13, 2007

Re: opengl

by Bryan Haskins

Well you don't have Direct rendering... if you dont have support from the ATI OSS drivers ( if you use ATi) then you should download the ATI or nvidia proprietary drivers. Should be in your Distros Repos, or you can set them up yourself from their sties. On 2/13/07, gaosheng <gs(a)crosslight.com.cn> wrote: > > Hi: > I want to use opengl with wine. > > //----Here is my glxinfo. > > server glx vendor string:SGI > server glx version string:1.2 > > client glx vendor string:SGI > client glx version string:1.2 > > OpengGL vendor string:Mesa project:www.mesa3d.org > OpengGL renderer string:Mesa GLX Indirect > OpengGL version string:1.3 Mesa 4.0.4 > //------ > > I can't init opengl. when ChoosePixel(), it failed. > Can you tell me the reason. > > Best regards > gao sheng > > > > > -- Cheers, Bryan

Feb. 13, 2007

Re: winecfg: Add check for device access to Drives tab.

by Alexandre Julliard

Vitaliy Margolen <wine-devel(a)kievinfo.com> writes: > 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. I think you should distinguish the case of no device at all from the case of a SCSI ioctl failing, for instance loop mounts wouldn't support the ioctl but would still work fine for many things. Also the no device case needs to be less scary, there's nothing wrong with it for most devices. And the strings need to be in resources. -- Alexandre Julliard julliard(a)winehq.org

Feb. 13, 2007

Re: Linuxtag 2007

by Detlef Riekenberg

On Mo, 2007-02-12 at 17:58 +0100, Detlef Riekenberg wrote: > On Mo, 2007-02-12 at 16:37 +0100, Marcus Meissner wrote: > > Whith your help, what can be done, I found 54 contributors for > 2007 in the changelog . > > $ grep "^2007.*>" ChangeLog | sort -t "<" +1 -u | wc -l > 56 > (Stefan and Francois are twice in the list) "+1" works with "sort (GNU coreutils) 5.93" here, but is not documented in "man sort" and did not work on newer versions: "sort (GNU coreutils) 6.4" as example: file "+1" not found. "-k 2" works on 5.93 and is documented: $ grep "^2007.*>" ChangeLog | sort -t "<" -k 2 -u | wc -l 56 -- By by ... Detlef

Feb. 13, 2007

Re: Starting work on wine (Direct X Help)

by Stefan Dösinger

Am Dienstag 13 Februar 2007 03:39 schrieb Nathan Williams: > Yeah, I'm not too interested in the sound right now, but I aim to work on > that eventually. > > As for managed mode, unless I'm mangling the wine terminology, what i mean > is that it will only show up if I use a command such as: > > wine explorer /desktop=foo,640x480 CARM95.EXE Yes, you're mangling the terminology here. What you do here is a virtual desktop. Managed mode means that the windows are managed by the X11 window manager(so they have the window decorations like Linux apps and can be minimized as normal), while unmanaged mode means that wine manages them, they have windows 95-style decos and stay on top of all Linux apps. Managed mode is the default, I think you can enable unmanaged mode with a registry switch.

Feb. 13, 2007

Re: [PATCH] switch stat and fopen

by Marcus Meissner

On Tue, Feb 13, 2007 at 05:28:52PM +0900, Mike McCormack wrote: > > Marcus Meissner wrote: > > >- if (!(fin = fopen(input_file_name, "r"))) return 0; > > if (stat(input_file_name, &st) < 0) return 0; > >+ if (!(fin = fopen(input_file_name, "r"))) return 0; > > Wouldn't it be better to use fstat here to avoid a race condition? Done. Ciao, Marcus

Feb. 13, 2007

Re: mshtml #10: Added SchemeIs implementation.

by Alexandre Julliard

Jacek Caban <jacek(a)codeweavers.com> writes: > --- > dlls/mshtml/nsio.c | 12 +++++++++++- > 1 files changed, 11 insertions(+), 1 deletions(-) This one causes make test to hang in the htmldoc.c test, somewhere in test_download(). -- Alexandre Julliard julliard(a)winehq.org

Feb. 13, 2007

Re: avifil32: sign-compare fixes

by Alexandre Julliard

Joris Huizer <joris_huizer(a)yahoo.com> writes: > diff --git a/dlls/avifil32/avifile.c b/dlls/avifil32/avifile.c > index f989c79..e7b22b1 100644 > --- a/dlls/avifil32/avifile.c > +++ b/dlls/avifil32/avifile.c > @@ -835,7 +835,7 @@ static LONG WINAPI IAVIStream_fnFindSamp > ULONG n; > > for (n = 0; n < This->sInfo.dwFormatChangeCount; n++) > - if (This->idxFmtChanges[n].ckid >= pos) { > + if (This->idxFmtChanges[n].ckid >= (ULONG)pos) { Please don't add typecasts all over the place. If things can be fixed by changing variable types then that's fine, but otherwise we can just as well live with the warnings. -- Alexandre Julliard julliard(a)winehq.org

Feb. 13, 2007

Re: AppDB performance issue

by Nick Law

Bryan Haskins wrote: > Weird I'm on dial-up even and goto the same pages, and all around the > wine sites, all the time, and they load surprisingly fast. > > On 2/12/07, *Nick Law* <nlaw(a)nildram.co.uk > <mailto:nlaw(a)nildram.co.uk>> wrote: >> Nick Law wrote: >> > Tony Lambregts wrote: >> >> Chris Morgan wrote: >> >> >> >>> On 2/11/07, Tony Lambregts <tony.lambregts(a)gmail.com >> <mailto:tony.lambregts(a)gmail.com>> wrote: >> >>> >> >>>> Nick Law wrote: >> >>>> >> >>>>> Hi Tony, >> >>>>> Just lately, I've noticed that AppDB seems to be very slow, i.e it >> >>>>> can >> >>>>> take15 seconds or more for a page to come up or simply to >> login. Is >> >>>>> there a bandwidth problem or is the server getting overwhelmed >> or is >> >>>>> it a problem at my end (UK). 30 seconds later it's back to >> being very >> >>>>> responsive as if the server was a bit overloaded for 30 seconds or >> >>>>> so. >> >>>>> Other websites I try at the time work fine including winehq. Is >> >>>>> winehq >> >>>>> on a different server ? >> >>>>> >> >>>>> >> >>>> I have noticed this too and it is very annoying. Yes >> www.winehq.org <http://www.winehq.org> >> >>>> qpdb.winehq.or and bugs.winehq.org <http://bugs.winehq.org> are >> all on the same server. >> >>>> >> >>>> Winehq and bugzilla are quite snappy but the AppDB is a pig now. >> >>>> >> >>>> I have know idea what is wrong >> >>>> >> >>>> -- >> >>>> >> >>>> Tony Lambregst >> >>>> >> >>>> >> >>>> >> >>>> >> >>> Are particular pages slow? I'm not seeing slow page loads to the >> main >> >>> page or to an application version page from here, a few seconds for >> >>> each. >> >>> >> >>> Chris >> >>> >> >>> >> >>> >> >> >> >> I see it when doing administration ie accepting or rejectiong >> >> applications and >> >> versions (maybe its the way we send emails). >> >> >> >> >> >> -- >> >> >> >> Tony Lambregts >> >> . >> > >> > Yes, ditto. Logging in to do admin tasks, but not only that, if I >> > click on the link in an email from somebody that has posted to the >> > WoW 2.0.x page it will take 30 seconds for the page to appear. >> > >> > I just posted some replies to the wow page and then clicked on the >> > link in the email and it took 84 seconds for the page to appear. It >> > find it seems to be more frequent now, maybe every other page or 1 in >> > three pages are very slow. >> > >> > Nick >> > >> > >> Correction it seems to be bad at the moment, the last 4 pages are slow, >> 60-90 secs before they display, and now it's back to < 2seconds to >> display a page again, it's like some process on the server hogs the CPU >> for 60 secs intermittently. >> >> Nick >> >> >> >> -- >> Cheers, >> Bryan >> ------------------------------------------------------------------------ >> >> >> Do you click on the links in the emails received from appdb(a)winehq.org to take you to the posts on the WoW AppDB page ? That's where I often see the problem. For instance this is a link to your recent post http://appdb.winehq.org/appview.php?iVersionId=6482&mode=nested#Comment-181… which takes over a minute to load, then 5 minutes later I try again and it loads in < 2secs. Nick

Feb. 13, 2007

opengl

by gaosheng

Hi: I want to use opengl with wine. //----Here is my glxinfo. server glx vendor string:SGI server glx version string:1.2 client glx vendor string:SGI client glx version string:1.2 OpengGL vendor string:Mesa project:www.mesa3d.org OpengGL renderer string:Mesa GLX Indirect OpengGL version string:1.3 Mesa 4.0.4 //------ I can't init opengl. when ChoosePixel(), it failed. Can you tell me the reason. Best regards gao sheng

Feb. 13, 2007

Re: [PATCH] switch stat and fopen

by Mike McCormack

Marcus Meissner wrote: > - if (!(fin = fopen(input_file_name, "r"))) return 0; > if (stat(input_file_name, &st) < 0) return 0; > + if (!(fin = fopen(input_file_name, "r"))) return 0; Wouldn't it be better to use fstat here to avoid a race condition? Mike

Feb. 13, 2007

Re: DIB Engine, some summarization

by Rolf Kalbermatter

Damjan Jovanovic [mailto:damjan.jov(a)gmail.com] well: >What about the case where you draw with GDI, then render with OpenGL on >top of that, then draw on top of that with GDI, then swap buffers? >If you draw only client-side, you have to copy to the server, then copy >back, then copy to the server *again*. You have to upload or download >the image *every time* you go between OpenGL and GDI drawing, whereas >when you draw with X11, there is no uploads/downloads unless you use >DIB sections and draw directly. Well, I have to admit I don't understand the whole complexity with DirectX, OpenGL and GDI. But the DIB engine is mostly for DIB sections I would think. It could be used for most device dependant bitmap surfaces too as long as the driver puts them in the surface structure of course, since that are just bitmaps too, but if that would be wise is another question. I would think that to start with the handling of DIBs would be most important. Or is it the idea to use the DIB engine for device dependant bitmaps attached to the device context too? Because that would make at least this case probably indeed more complicated. As far as X11 is concerend device dependant bitmaps should not pose a problem other than possibly performance if an application also wants to draw directly in the bitmap. But this works now and could be left in. And the bit depth will be alright since the ddb should be in the same bit depth as what the X11 server uses. DIBs however have the additional problem of using any possible bit depth with X11 only really supporting the currently used bit depth. So here you want to get X11 out of the loop if possible. >X11 drawing has some more advantages, like being able to use forms of >hardware acceleration (XAA/EXA) that client-side drawing can't. That might be but arbitrary bit depth support for hardware related acceleration is probably not very common among chip sets. >A pure client-side drawing strategy is IMO inferior to a strategy where >you can draw client-side or server-side, as the need arises. I think DIB drawing should be if possible kept on the client side. That solves the problems with X11 not supporting arbitrary bit depths and also synchronisation of the bitmaps if the application uses direct bitmap access too. And it wouldn't be pure client side at all. A driver can hook functions even for DIBs if he wants. If he does he would of course have to make sure all bit depths are supported and synchronisation is taken care off. Support of all bit depts would be quite easy as it could decide to do whatever modes it can do and otherwise pass it on to the GDI engine anyhow. If the driver doesn't hook or fails that function somehow then the GDI engine is used to do the operation for the DIB. And at least for drivers having their device bitmap in the device context too (under Windows a driver doesn't need to do that, for instance always drawing directly to the shared video memory), it might be possible to use the DIB engine too, but that would be the drivers decision and as said I'm not yet sure that is how it's done under Windows nor if it should be done this way. Rolf Kalbermatter

Feb. 13, 2007

Re: wineboot: Start items in StartUp folder on boot, includes security measures.

by James Hawkins

On 2/12/07, richardvoigt(a)gmail.com <richardvoigt(a)gmail.com> wrote: > > You advocated that wine aim for working exactly like Windows, no less > and no more, rather than deviating in user-configurable ways to > enhance the user's control over his own system. > Right. That's the purpose of Wine. You'd know that if you were a developer on this project. > Maybe while we're at > it, wine should have the bug which allows certain software to prevent > screen grabs. > I don't know of any apps that depend on this behavior, so that's not likely to happen. > No, I think defeating DRM to enable fair use is > perfectly reasonable, and there are some bugs which should be fixed. > Should wine try to patch remote exploits at the exact same rate as > windowsupdate.com? > Since we have completely different code bases, I don't see how we can fix their code in our tree. > That would be also be required for true > bug-for-bug compatibility. After all, someone properly authorized > might be using that backdoor to reboot their webfarm remotely -- not! > > There are things that are wrong in a theoretical sense (i.e. the > Pentium floating-point bug), or misclassification of Unicode > characters, which some programs might reasonably depend on. And then > there are things that are wrong from a practical engineering > perspective, like software taking away the user's choice to not run > it, which the mere fact that a program depends on it makes it malware. > Are you a software engineer? From a practical engineering perspective, adding this option adds unnecessary complication to the code base and increases the chances for bugs. This is exactly what UAC does, and no competent engineer thinks UAC is a good thing, or that it adds any amount of security. This "malware" that you're so afraid of can just write over that registry entry. > > Asking if you want to run every file set for startup in wineboot > > every single time is crippling behavior, not to mention annoying. UAC > > anyone? If you're so worried about this "malware", create a reduced > > privileges account just for Wine. > > That's the point of a "remember my choice" or "Yes/No/Always/Never" > option on the prompt which appears when the winecfg option is ask... > If this entry defaults to "Always" or "Never", then the users won't even know that the option exists, and that's one more piece of information that we'll have to broadcast and answer questions about. > Reduced privileges do little or nothing to prevent network abuse (open > spam relay and the like). > If you're running executables that are going to add themselves to AutoStart, the fact that they might run again is the least of your concerns. -- James Hawkins

Feb. 13, 2007

Re: Starting work on wine (Direct X Help)

by Nathan Williams

Yeah, I'm not too interested in the sound right now, but I aim to work on that eventually. As for managed mode, unless I'm mangling the wine terminology, what i mean is that it will only show up if I use a command such as: wine explorer /desktop=foo,640x480 CARM95.EXE I'll do some looking into the GetDC calls now. Thank you! On 2/13/07, Stefan Dösinger <stefandoesinger(a)gmx.at> wrote: > > Am Dienstag 13 Februar 2007 02:43 schrieb Nathan Williams: > > I want to get my hands dirty in the wine source code but I need a > > little guidance, hopefully from someone working on the DirectX > > sections of wine. > > > > I've decided I want to get Carmageddon working properly. > > I have already added it to the appdb > > (http://appdb.winehq.org/appview.php?iVersionId=6993) > > for the windows version. > > My main question is, how can I go about linking the visual bugs that I > > see with the area of code that needs work? > > I have worked with DirectX before and I am capable of coding tests and > > hooking directx on windows if needed. > I am working on Direct3D and DirectDraw, and I wrote the new DirectDraw > over > WineD3D implementation. > > From looking at the (tiny) description in the appdb it seems that there > are 3 > different issues. The "lenght not multiple" messages are sound related - I > hardly know about that. The "managed" issue, do you mean it only runs in a > > virtual desktop, or when you allow the window to be controlled by the > linux > window manager? Last, the flawky menus and cutscenes could be because of > the > lack of a proper GDI engine. You can test that by enabling the ddraw debug > > channel and searching for GetDC calls. > > -- Nathan

Feb. 13, 2007

Re: wineboot: Start items in StartUp folder on boot, includes security measures.

by Bryan Haskins

If you've read the recent mailing list posts dating up to a few weeks back I think, there have been some cases. But like everyone said, the fact the malware would even run in itself is almost bittersweet. It is bug-for-bug though so you can't just do that. Possibly an 'msconfig' like thing would be more realistic you know where you control (in a poor poor pooooooor way,) what runs at startup. yo ucould even go as far as to show the programs in the gnome-sessions program or the kde equivilent, thought that would be a pain (though cool.) On 2/12/07, John Smith <xixsimplicityxix(a)gmail.com> wrote: > > Part of my confusion what usage pattern is contracting malware on wine in > the first place > > On 2/12/07, richardvoigt(a)gmail.com <richardvoigt(a)gmail.com> wrote: > > > > On 2/12/07, James Hawkins <truiken(a)gmail.com> wrote: > > > On 2/11/07, richardvoigt(a)gmail.com < richardvoigt(a)gmail.com> wrote: > > > > On 2/11/07, Misha Koshelev <mk144210(a)bcm.tmc.edu> wrote: > > > > > Hi everybody, > > > > > > > > > > Thanks for your suggestions. I just posted a new patch on > > wine-patches > > > > > where I tried to incorporate these and now it does the following > > (in > > > > > addition to my previous patch which just started items in the > > StartUp > > > > > folder): > > > > > > > > > > - When wineboot finds a file that it wants to start in the StartUp > > > > > folder, it asks the user whether he wants to run the program. His > > > > > options are: Always, Yes, No (default), and Never. > > > > > - If he selects Yes the program is run, if he select No it is not. > > > > > - If he selects Always or Never, I create a registry key in: > > > > > HKEY_CURRENT_USER\Software\Wine\StartupItems with the full > > pathname > > > > > of the program and the value "always" or "never." When wineboot > > sees > > > > > this program in the StartUp folder it checks this key, and if it > > is > > > > > set it performs the appropriate action. > > > > > > > > > > What do you guys think? If you like the system, it would be pretty > > easy > > > > > to incorporate this into the run key running as well (which are > > > > > currently just run without any user confirmation)? > > > > > > > > This sounds almost perfect. I think the counterpoint raised by > > James > > > > Hawkins would be adequately addressed by adding a winecfg option as > > > > follows: > > > > > > > > Startup items behavior: > > > > (*) Silently allow <-- This is "bug-for-bug > > compatibility" > > > > ( ) Ask <-- Most computer-savvy folks > > would want this > > > > ( ) Silently block > > > > ( ) Block and notify me > > > > > > > > > > This is unnecessarily complicated, and i really doubt anything like > > > this would ever make it into the Wine tree. > > > > > > > Perhaps this should be independently set for each kind of startup > > item > > > > (startmenu\programs\startup, registry run key, profile settings, > > etc), > > > > but I think that's not really necessary. > > > > > > > > Also, I would suggest that the list of approved start items be > > stored > > > > outside of winespace, so that malware can't bypass the protection by > > > > setting the key. Of course, really nasty stuff could still call > > into > > > > Linux, but that would require some hybrid system that was aware of > > the > > > > ELF dynamic loader in order to not fall afoul of address space > > > > randomization. > > > > > > > > Ultimately I think wine is about more than just running > > > > Windows-compatible programs without the Microsoft tax. It's about > > > > running those programs without ceding control of your computer to an > > > > untrustworthy party. We don't want the limitations that Windows > > > > imposes... true bug-for-bug compatibility would mean only being able > > > > > > to access files on a FAT or NTFS partition, but I don't hear anyone > > > > advocating for that kind of crippling behavior. > > > > > > > > > > What? Wine has nothing to do with which file system your files reside > > > > > on. > > You advocated that wine aim for working exactly like Windows, no less > > and no more, rather than deviating in user-configurable ways to > > enhance the user's control over his own system. Maybe while we're at > > it, wine should have the bug which allows certain software to prevent > > screen grabs. No, I think defeating DRM to enable fair use is > > perfectly reasonable, and there are some bugs which should be fixed. > > Should wine try to patch remote exploits at the exact same rate as > > windowsupdate.com? That would be also be required for true > > bug-for-bug compatibility. After all, someone properly authorized > > might be using that backdoor to reboot their webfarm remotely -- not! > > > > There are things that are wrong in a theoretical sense (i.e. the > > Pentium floating-point bug), or misclassification of Unicode > > characters, which some programs might reasonably depend on. And then > > there are things that are wrong from a practical engineering > > perspective, like software taking away the user's choice to not run > > it, which the mere fact that a program depends on it makes it malware. > > > > > Asking if you want to run every file set for startup in wineboot > > > every single time is crippling behavior, not to mention annoying. UAC > > > anyone? If you're so worried about this "malware", create a reduced > > > privileges account just for Wine. > > > > That's the point of a "remember my choice" or "Yes/No/Always/Never" > > option on the prompt which appears when the winecfg option is ask... > > > > Reduced privileges do little or nothing to prevent network abuse (open > > spam relay and the like). > > > > > > > > > > > > > > > Thanks > > > > > Misha > > > > > > > > > > p.s. please please please anyone who is familiar with IShellFolder > > if > > > > > you could look over those parts and just say yes it looks good > > that > > > > > would make me feel better. I think it is correct but really an > > expert's > > > > > opinion would be great. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > > James Hawkins > > > > > > > > > > > > > -- Cheers, Bryan

Feb. 13, 2007

Re: Starting work on wine (Direct X Help)

by Stefan Dösinger

Am Dienstag 13 Februar 2007 02:43 schrieb Nathan Williams: > I want to get my hands dirty in the wine source code but I need a > little guidance, hopefully from someone working on the DirectX > sections of wine. > > I've decided I want to get Carmageddon working properly. > I have already added it to the appdb > (http://appdb.winehq.org/appview.php?iVersionId=6993) > for the windows version. > My main question is, how can I go about linking the visual bugs that I > see with the area of code that needs work? > I have worked with DirectX before and I am capable of coding tests and > hooking directx on windows if needed. I am working on Direct3D and DirectDraw, and I wrote the new DirectDraw over WineD3D implementation. >From looking at the (tiny) description in the appdb it seems that there are 3 different issues. The "lenght not multiple" messages are sound related - I hardly know about that. The "managed" issue, do you mean it only runs in a virtual desktop, or when you allow the window to be controlled by the linux window manager? Last, the flawky menus and cutscenes could be because of the lack of a proper GDI engine. You can test that by enabling the ddraw debug channel and searching for GetDC calls.

Feb. 13, 2007

Re: wineboot: Start items in StartUp folder on boot, includes security measures.

by John Smith

Part of my confusion what usage pattern is contracting malware on wine in the first place On 2/12/07, richardvoigt(a)gmail.com <richardvoigt(a)gmail.com> wrote: > > On 2/12/07, James Hawkins <truiken(a)gmail.com> wrote: > > On 2/11/07, richardvoigt(a)gmail.com <richardvoigt(a)gmail.com> wrote: > > > On 2/11/07, Misha Koshelev <mk144210(a)bcm.tmc.edu> wrote: > > > > Hi everybody, > > > > > > > > Thanks for your suggestions. I just posted a new patch on > wine-patches > > > > where I tried to incorporate these and now it does the following (in > > > > addition to my previous patch which just started items in the > StartUp > > > > folder): > > > > > > > > - When wineboot finds a file that it wants to start in the StartUp > > > > folder, it asks the user whether he wants to run the program. His > > > > options are: Always, Yes, No (default), and Never. > > > > - If he selects Yes the program is run, if he select No it is not. > > > > - If he selects Always or Never, I create a registry key in: > > > > HKEY_CURRENT_USER\Software\Wine\StartupItems with the full pathname > > > > of the program and the value "always" or "never." When wineboot sees > > > > this program in the StartUp folder it checks this key, and if it is > > > > set it performs the appropriate action. > > > > > > > > What do you guys think? If you like the system, it would be pretty > easy > > > > to incorporate this into the run key running as well (which are > > > > currently just run without any user confirmation)? > > > > > > This sounds almost perfect. I think the counterpoint raised by James > > > Hawkins would be adequately addressed by adding a winecfg option as > > > follows: > > > > > > Startup items behavior: > > > (*) Silently allow <-- This is "bug-for-bug compatibility" > > > ( ) Ask <-- Most computer-savvy folks would > want this > > > ( ) Silently block > > > ( ) Block and notify me > > > > > > > This is unnecessarily complicated, and i really doubt anything like > > this would ever make it into the Wine tree. > > > > > Perhaps this should be independently set for each kind of startup item > > > (startmenu\programs\startup, registry run key, profile settings, etc), > > > but I think that's not really necessary. > > > > > > Also, I would suggest that the list of approved start items be stored > > > outside of winespace, so that malware can't bypass the protection by > > > setting the key. Of course, really nasty stuff could still call into > > > Linux, but that would require some hybrid system that was aware of the > > > ELF dynamic loader in order to not fall afoul of address space > > > randomization. > > > > > > Ultimately I think wine is about more than just running > > > Windows-compatible programs without the Microsoft tax. It's about > > > running those programs without ceding control of your computer to an > > > untrustworthy party. We don't want the limitations that Windows > > > imposes... true bug-for-bug compatibility would mean only being able > > > to access files on a FAT or NTFS partition, but I don't hear anyone > > > advocating for that kind of crippling behavior. > > > > > > > What? Wine has nothing to do with which file system your files reside > > on. > You advocated that wine aim for working exactly like Windows, no less > and no more, rather than deviating in user-configurable ways to > enhance the user's control over his own system. Maybe while we're at > it, wine should have the bug which allows certain software to prevent > screen grabs. No, I think defeating DRM to enable fair use is > perfectly reasonable, and there are some bugs which should be fixed. > Should wine try to patch remote exploits at the exact same rate as > windowsupdate.com? That would be also be required for true > bug-for-bug compatibility. After all, someone properly authorized > might be using that backdoor to reboot their webfarm remotely -- not! > > There are things that are wrong in a theoretical sense (i.e. the > Pentium floating-point bug), or misclassification of Unicode > characters, which some programs might reasonably depend on. And then > there are things that are wrong from a practical engineering > perspective, like software taking away the user's choice to not run > it, which the mere fact that a program depends on it makes it malware. > > > Asking if you want to run every file set for startup in wineboot > > every single time is crippling behavior, not to mention annoying. UAC > > anyone? If you're so worried about this "malware", create a reduced > > privileges account just for Wine. > > That's the point of a "remember my choice" or "Yes/No/Always/Never" > option on the prompt which appears when the winecfg option is ask... > > Reduced privileges do little or nothing to prevent network abuse (open > spam relay and the like). > > > > > > > > > > > Thanks > > > > Misha > > > > > > > > p.s. please please please anyone who is familiar with IShellFolder > if > > > > you could look over those parts and just say yes it looks good that > > > > would make me feel better. I think it is correct but really an > expert's > > > > opinion would be great. > > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > James Hawkins > > > > >

Feb. 13, 2007

Re: AppDB performance issue

by Bryan Haskins

Weird I'm on dial-up even and goto the same pages, and all around the wine sites, all the time, and they load surprisingly fast. On 2/12/07, Nick Law <nlaw(a)nildram.co.uk> wrote: > > Nick Law wrote: > > Tony Lambregts wrote: > >> Chris Morgan wrote: > >> > >>> On 2/11/07, Tony Lambregts <tony.lambregts(a)gmail.com> wrote: > >>> > >>>> Nick Law wrote: > >>>> > >>>>> Hi Tony, > >>>>> Just lately, I've noticed that AppDB seems to be very slow, i.e it > >>>>> can > >>>>> take15 seconds or more for a page to come up or simply to login. Is > >>>>> there a bandwidth problem or is the server getting overwhelmed or is > >>>>> it a problem at my end (UK). 30 seconds later it's back to being > very > >>>>> responsive as if the server was a bit overloaded for 30 seconds or > >>>>> so. > >>>>> Other websites I try at the time work fine including winehq. Is > >>>>> winehq > >>>>> on a different server ? > >>>>> > >>>>> > >>>> I have noticed this too and it is very annoying. Yes www.winehq.org > >>>> qpdb.winehq.or and bugs.winehq.org are all on the same server. > >>>> > >>>> Winehq and bugzilla are quite snappy but the AppDB is a pig now. > >>>> > >>>> I have know idea what is wrong > >>>> > >>>> -- > >>>> > >>>> Tony Lambregst > >>>> > >>>> > >>>> > >>>> > >>> Are particular pages slow? I'm not seeing slow page loads to the main > >>> page or to an application version page from here, a few seconds for > >>> each. > >>> > >>> Chris > >>> > >>> > >>> > >> > >> I see it when doing administration ie accepting or rejectiong > >> applications and > >> versions (maybe its the way we send emails). > >> > >> > >> -- > >> > >> Tony Lambregts > >> . > > > > Yes, ditto. Logging in to do admin tasks, but not only that, if I > > click on the link in an email from somebody that has posted to the > > WoW 2.0.x page it will take 30 seconds for the page to appear. > > > > I just posted some replies to the wow page and then clicked on the > > link in the email and it took 84 seconds for the page to appear. It > > find it seems to be more frequent now, maybe every other page or 1 in > > three pages are very slow. > > > > Nick > > > > > Correction it seems to be bad at the moment, the last 4 pages are slow, > 60-90 secs before they display, and now it's back to < 2seconds to > display a page again, it's like some process on the server hogs the CPU > for 60 secs intermittently. > > Nick > > > -- Cheers, Bryan

Feb. 13, 2007

Re: wineboot: Start items in StartUp folder on boot, includes security measures.

by richardvoigt＠gmail.com

On 2/12/07, James Hawkins <truiken(a)gmail.com> wrote: > On 2/11/07, richardvoigt(a)gmail.com <richardvoigt(a)gmail.com> wrote: > > On 2/11/07, Misha Koshelev <mk144210(a)bcm.tmc.edu> wrote: > > > Hi everybody, > > > > > > Thanks for your suggestions. I just posted a new patch on wine-patches > > > where I tried to incorporate these and now it does the following (in > > > addition to my previous patch which just started items in the StartUp > > > folder): > > > > > > - When wineboot finds a file that it wants to start in the StartUp > > > folder, it asks the user whether he wants to run the program. His > > > options are: Always, Yes, No (default), and Never. > > > - If he selects Yes the program is run, if he select No it is not. > > > - If he selects Always or Never, I create a registry key in: > > > HKEY_CURRENT_USER\Software\Wine\StartupItems with the full pathname > > > of the program and the value "always" or "never." When wineboot sees > > > this program in the StartUp folder it checks this key, and if it is > > > set it performs the appropriate action. > > > > > > What do you guys think? If you like the system, it would be pretty easy > > > to incorporate this into the run key running as well (which are > > > currently just run without any user confirmation)? > > > > This sounds almost perfect. I think the counterpoint raised by James > > Hawkins would be adequately addressed by adding a winecfg option as > > follows: > > > > Startup items behavior: > > (*) Silently allow <-- This is "bug-for-bug compatibility" > > ( ) Ask <-- Most computer-savvy folks would want this > > ( ) Silently block > > ( ) Block and notify me > > > > This is unnecessarily complicated, and i really doubt anything like > this would ever make it into the Wine tree. > > > Perhaps this should be independently set for each kind of startup item > > (startmenu\programs\startup, registry run key, profile settings, etc), > > but I think that's not really necessary. > > > > Also, I would suggest that the list of approved start items be stored > > outside of winespace, so that malware can't bypass the protection by > > setting the key. Of course, really nasty stuff could still call into > > Linux, but that would require some hybrid system that was aware of the > > ELF dynamic loader in order to not fall afoul of address space > > randomization. > > > > Ultimately I think wine is about more than just running > > Windows-compatible programs without the Microsoft tax. It's about > > running those programs without ceding control of your computer to an > > untrustworthy party. We don't want the limitations that Windows > > imposes... true bug-for-bug compatibility would mean only being able > > to access files on a FAT or NTFS partition, but I don't hear anyone > > advocating for that kind of crippling behavior. > > > > What? Wine has nothing to do with which file system your files reside > on. You advocated that wine aim for working exactly like Windows, no less and no more, rather than deviating in user-configurable ways to enhance the user's control over his own system. Maybe while we're at it, wine should have the bug which allows certain software to prevent screen grabs. No, I think defeating DRM to enable fair use is perfectly reasonable, and there are some bugs which should be fixed. Should wine try to patch remote exploits at the exact same rate as windowsupdate.com? That would be also be required for true bug-for-bug compatibility. After all, someone properly authorized might be using that backdoor to reboot their webfarm remotely -- not! There are things that are wrong in a theoretical sense (i.e. the Pentium floating-point bug), or misclassification of Unicode characters, which some programs might reasonably depend on. And then there are things that are wrong from a practical engineering perspective, like software taking away the user's choice to not run it, which the mere fact that a program depends on it makes it malware. > Asking if you want to run every file set for startup in wineboot > every single time is crippling behavior, not to mention annoying. UAC > anyone? If you're so worried about this "malware", create a reduced > privileges account just for Wine. That's the point of a "remember my choice" or "Yes/No/Always/Never" option on the prompt which appears when the winecfg option is ask... Reduced privileges do little or nothing to prevent network abuse (open spam relay and the like). > > > > > > > Thanks > > > Misha > > > > > > p.s. please please please anyone who is familiar with IShellFolder if > > > you could look over those parts and just say yes it looks good that > > > would make me feel better. I think it is correct but really an expert's > > > opinion would be great. > > > > > > > > > > > > > > > > > > -- > James Hawkins >

Feb. 13, 2007

Starting work on wine (Direct X Help)

by Nathan Williams

I want to get my hands dirty in the wine source code but I need a little guidance, hopefully from someone working on the DirectX sections of wine. I've decided I want to get Carmageddon working properly. I have already added it to the appdb (http://appdb.winehq.org/appview.php?iVersionId=6993) for the windows version. My main question is, how can I go about linking the visual bugs that I see with the area of code that needs work? I have worked with DirectX before and I am capable of coding tests and hooking directx on windows if needed. -- Nathan

Feb. 13, 2007

Re: AppDB performance issue

by Nick Law

Nick Law wrote: > Tony Lambregts wrote: >> Chris Morgan wrote: >> >>> On 2/11/07, Tony Lambregts <tony.lambregts(a)gmail.com> wrote: >>> >>>> Nick Law wrote: >>>> >>>>> Hi Tony, >>>>> Just lately, I've noticed that AppDB seems to be very slow, i.e it >>>>> can >>>>> take15 seconds or more for a page to come up or simply to login. Is >>>>> there a bandwidth problem or is the server getting overwhelmed or is >>>>> it a problem at my end (UK). 30 seconds later it's back to being very >>>>> responsive as if the server was a bit overloaded for 30 seconds or >>>>> so. >>>>> Other websites I try at the time work fine including winehq. Is >>>>> winehq >>>>> on a different server ? >>>>> >>>>> >>>> I have noticed this too and it is very annoying. Yes www.winehq.org >>>> qpdb.winehq.or and bugs.winehq.org are all on the same server. >>>> >>>> Winehq and bugzilla are quite snappy but the AppDB is a pig now. >>>> >>>> I have know idea what is wrong >>>> >>>> -- >>>> >>>> Tony Lambregst >>>> >>>> >>>> >>>> >>> Are particular pages slow? I'm not seeing slow page loads to the main >>> page or to an application version page from here, a few seconds for >>> each. >>> >>> Chris >>> >>> >>> >> >> I see it when doing administration ie accepting or rejectiong >> applications and >> versions (maybe its the way we send emails). >> >> >> -- >> >> Tony Lambregts >> . > > Yes, ditto. Logging in to do admin tasks, but not only that, if I > click on the link in an email from somebody that has posted to the > WoW 2.0.x page it will take 30 seconds for the page to appear. > > I just posted some replies to the wow page and then clicked on the > link in the email and it took 84 seconds for the page to appear. It > find it seems to be more frequent now, maybe every other page or 1 in > three pages are very slow. > > Nick > > Correction it seems to be bad at the moment, the last 4 pages are slow, 60-90 secs before they display, and now it's back to < 2seconds to display a page again, it's like some process on the server hogs the CPU for 60 secs intermittently. Nick

Feb. 13, 2007

Re: AppDB performance issue

by Nick Law

Tony Lambregts wrote: > Chris Morgan wrote: > >> On 2/11/07, Tony Lambregts <tony.lambregts(a)gmail.com> wrote: >> >>> Nick Law wrote: >>> >>>> Hi Tony, >>>> Just lately, I've noticed that AppDB seems to be very slow, i.e it can >>>> take15 seconds or more for a page to come up or simply to login. Is >>>> there a bandwidth problem or is the server getting overwhelmed or is >>>> it a problem at my end (UK). 30 seconds later it's back to being very >>>> responsive as if the server was a bit overloaded for 30 seconds or so. >>>> Other websites I try at the time work fine including winehq. Is winehq >>>> on a different server ? >>>> >>>> >>> I have noticed this too and it is very annoying. Yes www.winehq.org >>> qpdb.winehq.or and bugs.winehq.org are all on the same server. >>> >>> Winehq and bugzilla are quite snappy but the AppDB is a pig now. >>> >>> I have know idea what is wrong >>> >>> -- >>> >>> Tony Lambregst >>> >>> >>> >>> >> Are particular pages slow? I'm not seeing slow page loads to the main >> page or to an application version page from here, a few seconds for >> each. >> >> Chris >> >> >> > > I see it when doing administration ie accepting or rejectiong applications and > versions (maybe its the way we send emails). > > > -- > > Tony Lambregts > . Yes, ditto. Logging in to do admin tasks, but not only that, if I click on the link in an email from somebody that has posted to the WoW 2.0.x page it will take 30 seconds for the page to appear. I just posted some replies to the wow page and then clicked on the link in the email and it took 84 seconds for the page to appear. It find it seems to be more frequent now, maybe every other page or 1 in three pages are very slow. Nick

Feb. 13, 2007

Re: compiling out debugging messages?

by Michael Stefaniuc

Lei Zhang wrote: > Also, the patch from 2007/04/17 only removed -DWINE_NO_DEBUG_MSGS / > -DWINE_NO_TRACE_MSGS from configure, but not from > include/wine/debug.h. Right, it was a problem with a lot of people turning debug messages off and sending in useless problem reports. So that option got removed from configure. There is one valid reason to turn debugging off and that is to cross check that there are no side effects hidden in some debug message. > On 2/12/07, Lei Zhang <thestig(a)google.com> wrote: >> Hi, >> >> Is it still possible to compile out debugging messages? According to >> http://winehq.org/site/docs/winedev-guide/dbg-compiling, I can pass >> --disable-debug, but the Changelog says that option was removed about >> 10 month ago. bye michael -- Michael Stefaniuc Tel.: +49-711-96437-199 Sr. Network Engineer Fax.: +49-711-96437-111 Red Hat GmbH Email: mstefani(a)redhat.com Hauptstaetterstr. 58 http://www.redhat.de/ D-70178 Stuttgart

Feb. 12, 2007

Re: compiling out debugging messages?

by Lei Zhang

Also, the patch from 2007/04/17 only removed -DWINE_NO_DEBUG_MSGS / -DWINE_NO_TRACE_MSGS from configure, but not from include/wine/debug.h. On 2/12/07, Lei Zhang <thestig(a)google.com> wrote: > Hi, > > Is it still possible to compile out debugging messages? According to > http://winehq.org/site/docs/winedev-guide/dbg-compiling, I can pass > --disable-debug, but the Changelog says that option was removed about > 10 month ago. > > - Lei >

Feb. 12, 2007

compiling out debugging messages?

by Lei Zhang

Hi, Is it still possible to compile out debugging messages? According to http://winehq.org/site/docs/winedev-guide/dbg-compiling, I can pass --disable-debug, but the Changelog says that option was removed about 10 month ago. - Lei

Feb. 12, 2007

Re: Unsubscribe?

by Kevin Krammer

On Monday 12 February 2007 21:34, Mike wrote: > How does one unsubscribe from this list? http://www.winehq.org/mailman/options/wine-devel Cheers, Kevin

Feb. 12, 2007

Unsubscribe?

by Mike

How does one unsubscribe from this list? -m ============ Marcus Meissner wrote: > On Mon, Feb 12, 2007 at 04:18:00PM +0100, Stefan Munz wrote: > >> Hi, >> >> mentioned a few days ago I try to register "Wine" for participating at the >> Linuxtag 2007. >> They want some information that I can only guess. Maybe someone can provide me >> a better estimation for: >> >> Developers in >> 1. Germany >> > > I briefly reviewed the Changelog for the last 9 months > and found around 10 active developers. > > >> 2. Europe (incl. Germany) >> > > More difficult to find out, but lets just say 20 active developers. > > >> 3. Worldwide (incl. Europe) >> > > I guess around 35-40 active developers. > > >> How many developers work for Codeweavers (as they are for sure the biggest >> contributor)? >> > > $ grep codeweavers.com ChangeLog |sort -t"<" +1 -u|wc -l > 15 > > Ciao, Marcus > > > > >

Feb. 12, 2007

Re: DIB Engine, some summarization

by Daniel Remenak

On 2/12/07, Stefan Dösinger <stefandoesinger(a)gmx.at> wrote: > Am Montag 12 Februar 2007 19:54 schrieb Daniel Remenak: > > On 2/11/07, Damjan Jovanovic <damjan.jov(a)gmail.com> wrote: > > > What about the case where you draw with GDI, then render with OpenGL > > > on top of that, then draw on top of that with GDI, then swap buffers? > > > If you draw only client-side, you have to copy to the server, then > > > copy back, then copy to the server *again*. You have to upload or > > > download the image *every time* you go between OpenGL and GDI drawing, > > > whereas when you draw with X11, there is no uploads/downloads unless > > > you use DIB sections and draw directly. > > > > Not that it's relevant to this conversation (since wine needs to > > support legacy apps), but just so you know, even Microsoft no longer > > supports this sample scenario. Drawing with GDI over OpenGL (or DX), > > and reading from the GDI buffer on a hardware-accelerated window, are > > both undefined (officially "not supported") operations on Windows > > Vista. Caused a ton of problems for my company's product > > So IDirect3DSurface9::GetDC does not work any longer? (Or > IDirectDrawSurface7::GetDC) > > /me parties! > > Unfortunately, no; it looks like you can still render GDI onto a DX surface, just not directly onto a window which is also being rendered to by DX. >From the linked blog article: "Note that there is an alternative that can often work for an application -- DirectX is capable of handing back a DC to a DirectX surface, and applications can perform GDI rendering to that DC. From the DWM's perspective, that DirectX surface remains purely rendered by DirectX, and all is well." --Daniel Remenak

Feb. 12, 2007

ntdll: test that shows RtlRaiseException with EXCEPTION_BREAKPOINT mangles Eip of context

by Peter Oberndorfer

This test is supposed to show that the Eip field in the context is fixed up somewhere inside RtlRaiseException or NtRaiseException (test for NtRaiseException not included) for (only) EXCEPTION_BREAKPOINT exception For others context.Eip is not changed. Since real exceptions on wine also take that path i guess it is best to implement context modifing in there. The next patches will show what is the value of context.Eip in a Vectored exception handler (I still have some problems with this patch) After that i plan to wrap a debugger around the test to show that the debugger gets a unmodified context The ultimate goal is to fix the "Handling of EXCEPTION_BREAKPOINT" problem Vitaliy Margolen reported ( http://bugs.winehq.org/show_bug.cgi?id=7063 ) Patch tested on XP/2k Comments, suggestions? Greetings Peter --- dlls/ntdll/tests/exception.c | 85 ++++++++++++++++++++++++++++++++++++++++++ 1 files changed, 85 insertions(+), 0 deletions(-)

Feb. 12, 2007

Re: DIB Engine, some summarization

by Stefan Dösinger

Am Montag 12 Februar 2007 19:54 schrieb Daniel Remenak: > On 2/11/07, Damjan Jovanovic <damjan.jov(a)gmail.com> wrote: > > What about the case where you draw with GDI, then render with OpenGL > > on top of that, then draw on top of that with GDI, then swap buffers? > > If you draw only client-side, you have to copy to the server, then > > copy back, then copy to the server *again*. You have to upload or > > download the image *every time* you go between OpenGL and GDI drawing, > > whereas when you draw with X11, there is no uploads/downloads unless > > you use DIB sections and draw directly. > > Not that it's relevant to this conversation (since wine needs to > support legacy apps), but just so you know, even Microsoft no longer > supports this sample scenario. Drawing with GDI over OpenGL (or DX), > and reading from the GDI buffer on a hardware-accelerated window, are > both undefined (officially "not supported") operations on Windows > Vista. Caused a ton of problems for my company's product. So IDirect3DSurface9::GetDC does not work any longer? (Or IDirectDrawSurface7::GetDC) /me parties!

Feb. 12, 2007

Re: extract DLL calls from exe file (i.e. from portable executable)

by Stefan Dösinger

Am Montag 12 Februar 2007 18:56 schrieb Luis C. Busquets Pérez: > Dear all, > > I send this e-mail to you as I have not found a particular section to > put it. I have developped a little program that enables to know the > functions an exe or dll calls. I understand that it may be really > helpful to know if a program will run perfectly on wine or if there is > still a function missing. I think wine-devel is the better list for that. For inclusion in wine please send diffs against the wine code rather than some zipped sources. And I am not sure if pascal is allowed in wine. C or bash scripts are better. > The idea behind this program is the following: > A program compiled to run on MS Windows calls a number of system/program > libraries. > This tool enables to know which functions a program compiled for MS > Windows needs. I think winedump does that, but I could be mistaken > A tool such as WINE provides an implementation of the Windows API. This > implementation has to provide at least the calls that the program calls > in order to run correctly under WINE. Well, not really. That a function is implemented in wine does not necessarily mean that it is free of bugs. In most cases applications do not run because of bugs in the implementation rather than missing functions. > TODO: At this point, you are able to know the calls. In a future time, > extrdll or a script will be able to read the functions that WINE has > implemented and tell a user which dlls or functions on dlls the program > is missing to run correctly. There are some other issues too: I don't speak pascall, but can your program deal with lazy linking, i.e. functions loaded after startup with LoadDLL? And I think you will not be able to read COM interfaces. For example for Direct3D9 you will see only one call, CreateDirect3D9, although d3d9 has numerous interfaces with a few hundred methods.

Feb. 12, 2007

Re: extract DLL calls from exe file (i.e. from portable executable)

by Paul Vriens

Luis C. Busquets Pérez wrote: > Dear all, > > I send this e-mail to you as I have not found a particular section to > put it. I have developped a little program that enables to know the > functions an exe or dll calls. I understand that it may be really > helpful to know if a program will run perfectly on wine or if there is > still a function missing. > > The idea behind this program is the following: > A program compiled to run on MS Windows calls a number of system/program > libraries. > This tool enables to know which functions a program compiled for MS > Windows needs. > > A tool such as WINE provides an implementation of the Windows API. This > implementation has to provide at least the calls that the program calls > in order to run correctly under WINE. > > TODO: At this point, you are able to know the calls. In a future time, > extrdll or a script will be able to read the functions that WINE has > implemented and tell a user which dlls or functions on dlls the program > is missing to run correctly. > > Please let me know if you put it in the winehq. I look forward to have > the opportunity to contribute to the wine project. > > Luis C. Busquets Pérez > T. +32 473 353 128 > > > > ------------------------------------------------------------------------ > > Hi, excuse me if got it wrong, but what's the difference with winedump? Cheers, Paul.

Feb. 12, 2007

Re: DIB Engine, some summarization

by Daniel Remenak

On 2/11/07, Damjan Jovanovic <damjan.jov(a)gmail.com> wrote: > What about the case where you draw with GDI, then render with OpenGL > on top of that, then draw on top of that with GDI, then swap buffers? > If you draw only client-side, you have to copy to the server, then > copy back, then copy to the server *again*. You have to upload or > download the image *every time* you go between OpenGL and GDI drawing, > whereas when you draw with X11, there is no uploads/downloads unless > you use DIB sections and draw directly. Not that it's relevant to this conversation (since wine needs to support legacy apps), but just so you know, even Microsoft no longer supports this sample scenario. Drawing with GDI over OpenGL (or DX), and reading from the GDI buffer on a hardware-accelerated window, are both undefined (officially "not supported") operations on Windows Vista. Caused a ton of problems for my company's product. I can't directly quote what our nVidia rep sent to us (for legal reasons), but this link might be helpful: http://blogs.msdn.com/greg_schechter/archive/2006/05/02/588934.aspx --Daniel Remenak

Feb. 12, 2007

[7/10] WineD3D: Make the context array dynamic

by Stefan Dösinger

Feb. 12, 2007

Re: DirectX related question

by H. Verbeet

On 11/02/07, Tim Schmidt <timschmidt(a)gmail.com> wrote: > I'll purchase crossover, but it looks like SupComm wants pixel shader > 2.0, so I was thinking more along the lines of someone who wants to > hack on DirectX 10, but has no DirectX 10 capable hardware. Or no > DirectX 10 games to test against, etc. Anyone? > PS 2.0 is DX9. As mentioned in bug 6570, using GLSL for the shader backend should help a bit for shader support. The current plan is to make GLSL the default relatively soon. I see a demo was released not too long ago, so I might give a try one of these days.

Feb. 12, 2007

Re: Linuxtag 2007

by Detlef Riekenberg

On Mo, 2007-02-12 at 16:37 +0100, Marcus Meissner wrote: Whith your help, what can be done, I found 54 contributors for 2007 in the changelog . $ grep "^2007.*>" ChangeLog | sort -t "<" +1 -u | wc -l 56 (Stefan and Francois are twice in the list) > > How many developers work for Codeweavers (as they are for sure the biggest > > contributor)? > > $ grep codeweavers.com ChangeLog |sort -t"<" +1 -u|wc -l > 15 Alexandre is missing here, as he use @winehq.org -- By by ... Detlef

Feb. 12, 2007

Re: wineboot: Start items in StartUp folder on boot, includes security measures.

by James Hawkins

On 2/11/07, richardvoigt(a)gmail.com <richardvoigt(a)gmail.com> wrote: > On 2/11/07, Misha Koshelev <mk144210(a)bcm.tmc.edu> wrote: > > Hi everybody, > > > > Thanks for your suggestions. I just posted a new patch on wine-patches > > where I tried to incorporate these and now it does the following (in > > addition to my previous patch which just started items in the StartUp > > folder): > > > > - When wineboot finds a file that it wants to start in the StartUp > > folder, it asks the user whether he wants to run the program. His > > options are: Always, Yes, No (default), and Never. > > - If he selects Yes the program is run, if he select No it is not. > > - If he selects Always or Never, I create a registry key in: > > HKEY_CURRENT_USER\Software\Wine\StartupItems with the full pathname > > of the program and the value "always" or "never." When wineboot sees > > this program in the StartUp folder it checks this key, and if it is > > set it performs the appropriate action. > > > > What do you guys think? If you like the system, it would be pretty easy > > to incorporate this into the run key running as well (which are > > currently just run without any user confirmation)? > > This sounds almost perfect. I think the counterpoint raised by James > Hawkins would be adequately addressed by adding a winecfg option as > follows: > > Startup items behavior: > (*) Silently allow <-- This is "bug-for-bug compatibility" > ( ) Ask <-- Most computer-savvy folks would want this > ( ) Silently block > ( ) Block and notify me > This is unnecessarily complicated, and i really doubt anything like this would ever make it into the Wine tree. > Perhaps this should be independently set for each kind of startup item > (startmenu\programs\startup, registry run key, profile settings, etc), > but I think that's not really necessary. > > Also, I would suggest that the list of approved start items be stored > outside of winespace, so that malware can't bypass the protection by > setting the key. Of course, really nasty stuff could still call into > Linux, but that would require some hybrid system that was aware of the > ELF dynamic loader in order to not fall afoul of address space > randomization. > > Ultimately I think wine is about more than just running > Windows-compatible programs without the Microsoft tax. It's about > running those programs without ceding control of your computer to an > untrustworthy party. We don't want the limitations that Windows > imposes... true bug-for-bug compatibility would mean only being able > to access files on a FAT or NTFS partition, but I don't hear anyone > advocating for that kind of crippling behavior. > What? Wine has nothing to do with which file system your files reside on. Asking if you want to run every file set for startup in wineboot every single time is crippling behavior, not to mention annoying. UAC anyone? If you're so worried about this "malware", create a reduced privileges account just for Wine. > > > > Thanks > > Misha > > > > p.s. please please please anyone who is familiar with IShellFolder if > > you could look over those parts and just say yes it looks good that > > would make me feel better. I think it is correct but really an expert's > > opinion would be great. > > > > > > > > > -- James Hawkins

Feb. 12, 2007

Re: Linuxtag 2007

by Stefan Munz

Am Montag, 12. Februar 2007 16:32 schrieb Christoph Frick: > On Mon, Feb 12, 2007 at 04:18:00PM +0100, Stefan Munz wrote: > > Developers in > > 1. Germany > > 2. Europe (incl. Germany) > > 3. Worldwide (incl. Europe) > > How many developers work for Codeweavers (as they are for sure the > > biggest contributor)? > > isn't finding this number hard for OSS? what makes contributor a > devloper? this isn't specified, though I think a rough estimate is ok. > > for worldwide then the 873 lines from the AUTHORS file would be start. I think they mean active developers in, so the authors file seems a bit too much. Markus approach using the changelog file is ok, I think. thanks && cu, Stefan -- Dipl.-Inform. Stefan Munz. . . . . . . . . . stefan.munz(a)itomig.de ITOMIG GbR . . . . . . . . . . . . . . . . . www.itomig.de Sand 14 . . . . . . . . . . . . . . . . . . mobil: +49 178 729 72 72 D-72076 Tübingen . . . . . . . . . . . . . .

Feb. 12, 2007

Re: Linuxtag 2007

by Stefan Munz

Hi Markus, thanks for the detailed answer :-) cu, Stefan Am Montag, 12. Februar 2007 16:37 schrieben Sie: > On Mon, Feb 12, 2007 at 04:18:00PM +0100, Stefan Munz wrote: > > Hi, > > > > mentioned a few days ago I try to register "Wine" for participating at > > the Linuxtag 2007. > > They want some information that I can only guess. Maybe someone can > > provide me a better estimation for: > > > > Developers in > > 1. Germany > > I briefly reviewed the Changelog for the last 9 months > and found around 10 active developers. > > > 2. Europe (incl. Germany) > > More difficult to find out, but lets just say 20 active developers. > > > 3. Worldwide (incl. Europe) > > I guess around 35-40 active developers. > > > How many developers work for Codeweavers (as they are for sure the > > biggest contributor)? > > $ grep codeweavers.com ChangeLog |sort -t"<" +1 -u|wc -l > 15 > > Ciao, Marcus -- Dipl.-Inform. Stefan Munz. . . . . . . . . . stefan.munz(a)itomig.de ITOMIG GbR . . . . . . . . . . . . . . . . . www.itomig.de Sand 14 . . . . . . . . . . . . . . . . . . mobil: +49 178 729 72 72 D-72076 Tübingen . . . . . . . . . . . . . .

Feb. 12, 2007

Re: Linuxtag 2007

by Marcus Meissner

On Mon, Feb 12, 2007 at 04:18:00PM +0100, Stefan Munz wrote: > Hi, > > mentioned a few days ago I try to register "Wine" for participating at the > Linuxtag 2007. > They want some information that I can only guess. Maybe someone can provide me > a better estimation for: > > Developers in > 1. Germany I briefly reviewed the Changelog for the last 9 months and found around 10 active developers. > 2. Europe (incl. Germany) More difficult to find out, but lets just say 20 active developers. > 3. Worldwide (incl. Europe) I guess around 35-40 active developers. > How many developers work for Codeweavers (as they are for sure the biggest > contributor)? $ grep codeweavers.com ChangeLog |sort -t"<" +1 -u|wc -l 15 Ciao, Marcus

Feb. 12, 2007

Re: wineboot: Start items in StartUp folder on boot, includes security measures.

by Misha Koshelev

On Sun, 2007-02-11 at 23:49 -0600, John Smith wrote: > What prevents malicious programs from writing this registry key on > their own? > > On 2/11/07, Chris Robinson <chris.kcat(a)gmail.com> wrote: > On Sunday 11 February 2007 06:49:58 pm richardvoigt(a)gmail.com > wrote: > > This sounds almost perfect. > > What would stop the program from adding the registry key > itself when placing > the item in the startup folder, or wherever else? > > > I think the counterpoint raised by James > > Hawkins would be adequately addressed by adding a winecfg > option as > > follows: > > Sounds like it's just asking if it should ask. > > I'm not really sure what you could do as a user that a program > couldn't just > override and do itself. Besides, users might not know whether > what's being > installed into an auto-start key/folder is necessary, deny it > for "safety > concerns", and have a broken installation. > I think the bigger security issue to be made is that until wine default behavior is not to set up the user's home directory in a writeable way as the Z: drive there is really no way to store any settings in any user-writable file without having malware being able to change if it wanted to and was written specifically for wine (please correct me if I am wrong). So I believe that, given this state, securing Wine from malware written for Windows (which most is) and not specifically for Wine is the best we can do. Misha >

Feb. 12, 2007

Re: Linuxtag 2007

by Christoph Frick

On Mon, Feb 12, 2007 at 04:18:00PM +0100, Stefan Munz wrote: > Developers in > 1. Germany > 2. Europe (incl. Germany) > 3. Worldwide (incl. Europe) > How many developers work for Codeweavers (as they are for sure the > biggest contributor)? isn't finding this number hard for OSS? what makes contributor a devloper? for worldwide then the 873 lines from the AUTHORS file would be start. -- cu

Feb. 12, 2007

Linuxtag 2007

by Stefan Munz

Hi, mentioned a few days ago I try to register "Wine" for participating at the Linuxtag 2007. They want some information that I can only guess. Maybe someone can provide me a better estimation for: Developers in 1. Germany 2. Europe (incl. Germany) 3. Worldwide (incl. Europe) How many developers work for Codeweavers (as they are for sure the biggest contributor)? -- Dipl.-Inform. Stefan Munz. . . . . . . . . . stefan.munz(a)itomig.de ITOMIG GbR . . . . . . . . . . . . . . . . . www.itomig.de Sand 14 . . . . . . . . . . . . . . . . . . mobil: +49 178 729 72 72 D-72076 Tübingen . . . . . . . . . . . . . .

Feb. 12, 2007

Re: wineboot: Start items in StartUp folder on boot, includes security measures.

by Misha Koshelev

On Sun, 2007-02-11 at 23:49 -0600, John Smith wrote: > What prevents malicious programs from writing this registry key on > their own? > > On 2/11/07, Chris Robinson <chris.kcat(a)gmail.com> wrote: > On Sunday 11 February 2007 06:49:58 pm richardvoigt(a)gmail.com > wrote: > > This sounds almost perfect. > > What would stop the program from adding the registry key > itself when placing > the item in the startup folder, or wherever else? > > > I think the counterpoint raised by James > > Hawkins would be adequately addressed by adding a winecfg > option as > > follows: > > Sounds like it's just asking if it should ask. > > I'm not really sure what you could do as a user that a program > couldn't just > override and do itself. Besides, users might not know whether > what's being > installed into an auto-start key/folder is necessary, deny it > for "safety > concerns", and have a broken installation. > > Yes, I will admit a program can just write this registry key and have itself run. My assumption is that most malware is currently written for Windows and not specifically for Wine, and thus such programs generally would not have any reason to write such a key. I think if malware really wanted to run _specifically_ on Wine it would be pretty easy to do with or without my patch, for example, overwrite a key system DLL and then just set the appropriate registry key so Wine uses the "native DLL" that the malware program has put. I think the "security" of my patch is based on the fact that most malware programs are written for Windows and I think if we start seeing Wine-specific malware we are going to have to develop a lot more security in a lot of places. Misha

Feb. 12, 2007

Re: user32: WM_NCACTIVATE sent by set_active_window() should never deactivate

by Alexandre Julliard

Felix Nawothnig <flexo(a)holycrap.org> writes: > This fixes #7198. Problem is that GetForegroundWindow() sometimes > returns NULL (MSDN says: "in certain circumstances, such as when a > window is losing activation"). I didn't bother to check why this > happens for some apps (winemine works fine for me, winecfg doesn't - I > suspect timing issues) here as I saw no point in this check anyway: The point is that the window should not be painted active if it's not the foreground window too. There is one active window per queue, but only one foreground window. -- Alexandre Julliard julliard(a)winehq.org

Feb. 12, 2007

Re: [3/9] WineD3D: Add a per context structure for context management

by Alexandre Julliard

Stefan Dösinger <stefan(a)codeweavers.com> writes: > This patch adds a new context management structure which will keep a dirty > state list, state optimization members, a glx context and drawable, ... [2. application/x-zip; 0003-WineD3D-Add-a-per-context-structure-for-context-management.txt.zip]... Please don't send patches in zip format, that's a pain to extract. If you really have to compress please use gzip or bzip2. -- Alexandre Julliard julliard(a)winehq.org

Feb. 12, 2007

Re: ntdll: Fix compilation on systems that don't support nameless structs.

by Alexandre Julliard

Francois Gouget <fgouget(a)free.fr> writes: > diff --git a/dlls/ntdll/rtl.c b/dlls/ntdll/rtl.c > index 34a05b7..4d5c41d 100644 > --- a/dlls/ntdll/rtl.c > +++ b/dlls/ntdll/rtl.c > @@ -40,6 +40,12 @@ > > WINE_DEFAULT_DEBUG_CHANNEL(ntdll); > > +#ifdef NONAMELESSSTRUCT > +# define S(x) (x).s > +#else > +# define S(x) (x) > +#endif > + You shouldn't need that sort of macro in the Wine code. Simply define NONAMELESSSTRUCT unconditionally. -- Alexandre Julliard julliard(a)winehq.org

Feb. 12, 2007

Re: comtctl32 : updown : Getter and Setter Tests for Updown control

by Leslie Choong

Thanks for the input, I've added the expect() macro, corrected some spelling mistakes. Let me know what else I can do. -Leslie On 2/11/07, Dan Kegel <dank06(a)kegel.com> wrote: > I haven't looked at what James was talking about, but I noticed three things: > > You have a typo 'sohuld'. > > You should use the same filename as before, but increment the number > in the filename. > > You might consider using the expect() macro I've been encouraging > the other cs130 students to use, it makes the repeated ok() calls a bit > more readable (IMHO, we'll see if others agree). > - Dan > > On 2/11/07, Leslie Choong <septikus(a)gmail.com> wrote: > > Hey there, I've made the changes so that the return value is not > > stored unnecessarily. I've also added comments explaining why. Let me > > know what you think. > > -Leslie > > > > On 2/11/07, Leslie Choong <septikus(a)gmail.com> wrote: > > > Thanks for the input. UDM_SETRANGE has no return value according to > > > MSDN so I'll remove those assignments. > > > > > > On 2/11/07, James Hawkins <truiken(a)gmail.com> wrote: > > > > On 2/10/07, Leslie Choong <septikus(a)gmail.com> wrote: > > > > > Hi there, My name is Leslie Choong and I am currently finishing up my > > > > > under graduate work at UCLA. This patch is being sent as part of the > > > > > coursework for CS 130 : Software Engineering. Please take a look and > > > > > let me know if you have any suggestions or comments for change. > > > > > Thanks! > > > > > -Leslie Choong > > > > > > > > > > > > > + /* Set Range from 0 to 100 */ > > > > + r = SendMessage(updown, UDM_SETRANGE, 0 , MAKELONG(100,0) ); > > > > + r= SendMessage(updown, UDM_GETRANGE, 0,0); > > > > > > > > If you're not going to check the first return value, then take out the > > > > 'r =', else it seems like you're missing a test. On the other hand, > > > > why don't you test the return value? > > > > > > > > -- > > > > James Hawkins > > > > > > > > > > > > > > -- > Wine for Windows ISVs: http://kegel.com/wine/isv >

Feb. 12, 2007

Re: DIB Engine, some summarization

by Damjan Jovanovic

On 2/12/07, Rolf Kalbermatter <r.kalbermatter(a)hccnet.nl> wrote: > The issue about network transparency for the display driver would not be an > issue IMO. > Once complete the DIB engine would handle all DIB operations locally and so > no need for > translating direct memory access into remote calls to some display server > would be > necessary. And the blitting of DIBs to the display when necessary would > still be done > through the driver of course so everything would be transparent as far as > the capabilities > of the used display device itself allow for that. What about the case where you draw with GDI, then render with OpenGL on top of that, then draw on top of that with GDI, then swap buffers? If you draw only client-side, you have to copy to the server, then copy back, then copy to the server *again*. You have to upload or download the image *every time* you go between OpenGL and GDI drawing, whereas when you draw with X11, there is no uploads/downloads unless you use DIB sections and draw directly. X11 drawing has some more advantages, like being able to use forms of hardware acceleration (XAA/EXA) that client-side drawing can't. A pure client-side drawing strategy is IMO inferior to a strategy where you can draw client-side or server-side, as the need arises. > Rolf Kalbermatter Damjan Jovanovic

Feb. 12, 2007

Re: comtctl32 : updown : Getter and Setter Tests for Updown control

by Dan Kegel

I haven't looked at what James was talking about, but I noticed three things: You have a typo 'sohuld'. You should use the same filename as before, but increment the number in the filename. You might consider using the expect() macro I've been encouraging the other cs130 students to use, it makes the repeated ok() calls a bit more readable (IMHO, we'll see if others agree). - Dan On 2/11/07, Leslie Choong <septikus(a)gmail.com> wrote: > Hey there, I've made the changes so that the return value is not > stored unnecessarily. I've also added comments explaining why. Let me > know what you think. > -Leslie > > On 2/11/07, Leslie Choong <septikus(a)gmail.com> wrote: > > Thanks for the input. UDM_SETRANGE has no return value according to > > MSDN so I'll remove those assignments. > > > > On 2/11/07, James Hawkins <truiken(a)gmail.com> wrote: > > > On 2/10/07, Leslie Choong <septikus(a)gmail.com> wrote: > > > > Hi there, My name is Leslie Choong and I am currently finishing up my > > > > under graduate work at UCLA. This patch is being sent as part of the > > > > coursework for CS 130 : Software Engineering. Please take a look and > > > > let me know if you have any suggestions or comments for change. > > > > Thanks! > > > > -Leslie Choong > > > > > > > > > > + /* Set Range from 0 to 100 */ > > > + r = SendMessage(updown, UDM_SETRANGE, 0 , MAKELONG(100,0) ); > > > + r= SendMessage(updown, UDM_GETRANGE, 0,0); > > > > > > If you're not going to check the first return value, then take out the > > > 'r =', else it seems like you're missing a test. On the other hand, > > > why don't you test the return value? > > > > > > -- > > > James Hawkins > > > > > > > -- Wine for Windows ISVs: http://kegel.com/wine/isv

Feb. 12, 2007

Re: user32: add test cases for update rects affected by ShowWindow

by Dmitry Timoshkov

"Clinton Stimpson" <cjstimpson(a)utwire.net> wrote: > This patch adds a test to check the results of GetUpdateRect when a > child window is hidden. > See bug #7360. Wine incorrectly makes an update rect for the > grandparent window which has a todo_wine around it. > > Thanks, > Clinton Stimpson > > ChangeLog: > Add test for GetUpdateRect and ShowWindow interaction. After looking at this test once more, I think we need another test with windows without CS_PARENTDC style set in order to understand better what the proper behaviour is. -- Dmitry.

Feb. 12, 2007

Re: wineboot: Start items in StartUp folder on boot, includes security measures.

by John Smith

What prevents malicious programs from writing this registry key on their own? On 2/11/07, Chris Robinson <chris.kcat(a)gmail.com> wrote: > > On Sunday 11 February 2007 06:49:58 pm richardvoigt(a)gmail.com wrote: > > This sounds almost perfect. > > What would stop the program from adding the registry key itself when > placing > the item in the startup folder, or wherever else? > > > I think the counterpoint raised by James > > Hawkins would be adequately addressed by adding a winecfg option as > > follows: > > Sounds like it's just asking if it should ask. > > I'm not really sure what you could do as a user that a program couldn't > just > override and do itself. Besides, users might not know whether what's being > installed into an auto-start key/folder is necessary, deny it for "safety > concerns", and have a broken installation. > > >

Feb. 12, 2007

Re: wineboot: Start items in StartUp folder on boot, includes security measures.

by Chris Robinson

On Sunday 11 February 2007 06:49:58 pm richardvoigt(a)gmail.com wrote: > This sounds almost perfect. What would stop the program from adding the registry key itself when placing the item in the startup folder, or wherever else? > I think the counterpoint raised by James > Hawkins would be adequately addressed by adding a winecfg option as > follows: Sounds like it's just asking if it should ask. I'm not really sure what you could do as a user that a program couldn't just override and do itself. Besides, users might not know whether what's being installed into an auto-start key/folder is necessary, deny it for "safety concerns", and have a broken installation.

Feb. 12, 2007

Re: comtctl32 : updown : Getter and Setter Tests for Updown control

by Leslie Choong

Hey there, I've made the changes so that the return value is not stored unnecessarily. I've also added comments explaining why. Let me know what you think. -Leslie On 2/11/07, Leslie Choong <septikus(a)gmail.com> wrote: > Thanks for the input. UDM_SETRANGE has no return value according to > MSDN so I'll remove those assignments. > > On 2/11/07, James Hawkins <truiken(a)gmail.com> wrote: > > On 2/10/07, Leslie Choong <septikus(a)gmail.com> wrote: > > > Hi there, My name is Leslie Choong and I am currently finishing up my > > > under graduate work at UCLA. This patch is being sent as part of the > > > coursework for CS 130 : Software Engineering. Please take a look and > > > let me know if you have any suggestions or comments for change. > > > Thanks! > > > -Leslie Choong > > > > > > > + /* Set Range from 0 to 100 */ > > + r = SendMessage(updown, UDM_SETRANGE, 0 , MAKELONG(100,0) ); > > + r= SendMessage(updown, UDM_GETRANGE, 0,0); > > > > If you're not going to check the first return value, then take out the > > 'r =', else it seems like you're missing a test. On the other hand, > > why don't you test the return value? > > > > -- > > James Hawkins > > >

Feb. 12, 2007

Re: 1/4 NtCreateMailslotFile tests

by Dmitry Timoshkov

"Jeff Latimer" <lats(a)yless4u.com.au> wrote: > + rc = pNtCreateMailslotFile(&hslot, DesiredAccess, > + &attr, &IoStatusBlock, CreateOptions, MailslotQuota, MaxMessageSize, > + &TimeOut); > + ok( rc == S_OK, "Create MailslotFile failed rc = %x %u\n", rc, GetLastError()); NT APIs return STATUS_xxx error codes, S_OK is an OLE error value. > + ok( hslot != INVALID_HANDLE_VALUE, "Handle is invalid\n"); INVALID_HANDLE_VALUE is a kernel32 thing, NT APIs don't use it. Most likely you need to test returned value against 0. > + ok( CloseHandle(hslot), "CloseHandle failed\n"); To close the handle returned by an NT API you have you use an NT API as well. -- Dmitry.

Feb. 12, 2007

Re: wineboot: Start items in StartUp folder on boot, includes security measures.

by Vitaliy Margolen

James Hawkins wrote: > On 2/11/07, Misha Koshelev <mk144210(a)bcm.tmc.edu> wrote: >> Ok, thanks to everybody's responses on the wine-devel list. Here is my >> new version of this patch. It starts the items in the StartUp folder >> like Windows does (again, if anybody who knows about IShellFolder will >> look over my code that would be great :) I tested it and it works for >> the Vector NTI installer, but I would really like to have an expert's >> opinion on whether it is missing osmething). There were a lot of >> comments on wine-devel about malware using this system to start itself >> so here is what I added: >> >> To me it seems like this would be enough to prevent malware from using >> this system because the user could just click no or never. Also, someone >> pointed out that wineboot already runs quite a lot of other RUN registry >> keys that can be used for malware, and currently there is no system for >> these keys like the one I made for startup. Any comments will be >> appreciated. Thanks. >> > > These anti-malware changes are unnecessary. We implement Wine to be > bug-for-bug compatible with Windows. Windows doesn't ask this Then you will have to implement all the required functionality to allow anti-malware programs to function properly. Until then, Wine have to have some solutions to prevent nasty things to run on Wine. The excuse "bug-for-bug" will not cut it here! If you want that - you should not have ever switched to Linux in the first place. Vitaliy.

Feb. 12, 2007

Re: wineboot: Start items in StartUp folder on boot, includes security measures.

by Vitaliy Margolen

Felix Nawothnig wrote: > richardvoigt(a)gmail.com wrote: >> This sounds almost perfect. I think the counterpoint raised by James >> Hawkins would be adequately addressed by adding a winecfg option as >> follows: > > Since we want winecfg to be gone in the long-term a registry key alone Who said that? Or you planning on implementing a winecfg replacement yet again? Vitaliy.

Feb. 12, 2007

Re: wineboot: Start items in StartUp folder on boot, includes security measures.

by Misha Koshelev

Ok, I sent out a patch with this fix to wine-patches. Now the HKEY_CURRENT_USER\Software\Wine\StartupItems key can be set to "always" which will make all items always run. Otherwise, previous behavior with asking/keys for each individual items will occur. Misha On Mon, 2007-02-12 at 04:14 +0100, Felix Nawothnig wrote: > richardvoigt(a)gmail.com wrote: > > This sounds almost perfect. I think the counterpoint raised by James > > Hawkins would be adequately addressed by adding a winecfg option as > > follows: > > Since we want winecfg to be gone in the long-term a registry key alone > would probably do fine. > > Felix

Feb. 12, 2007

Re: AppDB performance issue

by Tony Lambregts

Chris Morgan wrote: > On 2/11/07, Tony Lambregts <tony.lambregts(a)gmail.com> wrote: >> Nick Law wrote: >> > Hi Tony, >> > Just lately, I've noticed that AppDB seems to be very slow, i.e it can >> > take15 seconds or more for a page to come up or simply to login. Is >> > there a bandwidth problem or is the server getting overwhelmed or is >> > it a problem at my end (UK). 30 seconds later it's back to being very >> > responsive as if the server was a bit overloaded for 30 seconds or so. >> > Other websites I try at the time work fine including winehq. Is winehq >> > on a different server ? >> > >> I have noticed this too and it is very annoying. Yes www.winehq.org >> qpdb.winehq.or and bugs.winehq.org are all on the same server. >> >> Winehq and bugzilla are quite snappy but the AppDB is a pig now. >> >> I have know idea what is wrong >> >> -- >> >> Tony Lambregst >> >> >> > > Are particular pages slow? I'm not seeing slow page loads to the main > page or to an application version page from here, a few seconds for > each. > > Chris > > I see it when doing administration ie accepting or rejectiong applications and versions (maybe its the way we send emails). -- Tony Lambregts

Feb. 12, 2007

Re: AppDB performance issue

by Chris Morgan

Are particular pages slow? I'm not seeing slow page loads to the main page or to an application version page from here, a few seconds for each. Chris On 2/11/07, Tony Lambregts <tony.lambregts(a)gmail.com> wrote: > Nick Law wrote: > > Hi Tony, > > Just lately, I've noticed that AppDB seems to be very slow, i.e it can > > take15 seconds or more for a page to come up or simply to login. Is > > there a bandwidth problem or is the server getting overwhelmed or is > > it a problem at my end (UK). 30 seconds later it's back to being very > > responsive as if the server was a bit overloaded for 30 seconds or so. > > Other websites I try at the time work fine including winehq. Is winehq > > on a different server ? > > > I have noticed this too and it is very annoying. Yes www.winehq.org > qpdb.winehq.or and bugs.winehq.org are all on the same server. > > Winehq and bugzilla are quite snappy but the AppDB is a pig now. > > I have know idea what is wrong > > -- > > Tony Lambregst > > >

Feb. 12, 2007

Re: AppDB performance issue

by Tony Lambregts

Nick Law wrote: > Hi Tony, > Just lately, I've noticed that AppDB seems to be very slow, i.e it can > take15 seconds or more for a page to come up or simply to login. Is > there a bandwidth problem or is the server getting overwhelmed or is > it a problem at my end (UK). 30 seconds later it's back to being very > responsive as if the server was a bit overloaded for 30 seconds or so. > Other websites I try at the time work fine including winehq. Is winehq > on a different server ? > I have noticed this too and it is very annoying. Yes www.winehq.org qpdb.winehq.or and bugs.winehq.org are all on the same server. Winehq and bugzilla are quite snappy but the AppDB is a pig now. I have know idea what is wrong -- Tony Lambregst

Feb. 12, 2007

Re: wineboot: Start items in StartUp folder on boot, includes security measures.

by Felix Nawothnig

richardvoigt(a)gmail.com wrote: > This sounds almost perfect. I think the counterpoint raised by James > Hawkins would be adequately addressed by adding a winecfg option as > follows: Since we want winecfg to be gone in the long-term a registry key alone would probably do fine. Felix

Feb. 12, 2007

Re: wineboot: Start items in StartUp folder on boot, includes security measures.

by richardvoigt＠gmail.com

On 2/11/07, Misha Koshelev <mk144210(a)bcm.tmc.edu> wrote: > Hi everybody, > > Thanks for your suggestions. I just posted a new patch on wine-patches > where I tried to incorporate these and now it does the following (in > addition to my previous patch which just started items in the StartUp > folder): > > - When wineboot finds a file that it wants to start in the StartUp > folder, it asks the user whether he wants to run the program. His > options are: Always, Yes, No (default), and Never. > - If he selects Yes the program is run, if he select No it is not. > - If he selects Always or Never, I create a registry key in: > HKEY_CURRENT_USER\Software\Wine\StartupItems with the full pathname > of the program and the value "always" or "never." When wineboot sees > this program in the StartUp folder it checks this key, and if it is > set it performs the appropriate action. > > What do you guys think? If you like the system, it would be pretty easy > to incorporate this into the run key running as well (which are > currently just run without any user confirmation)? This sounds almost perfect. I think the counterpoint raised by James Hawkins would be adequately addressed by adding a winecfg option as follows: Startup items behavior: (*) Silently allow <-- This is "bug-for-bug compatibility" ( ) Ask <-- Most computer-savvy folks would want this ( ) Silently block ( ) Block and notify me Perhaps this should be independently set for each kind of startup item (startmenu\programs\startup, registry run key, profile settings, etc), but I think that's not really necessary. Also, I would suggest that the list of approved start items be stored outside of winespace, so that malware can't bypass the protection by setting the key. Of course, really nasty stuff could still call into Linux, but that would require some hybrid system that was aware of the ELF dynamic loader in order to not fall afoul of address space randomization. Ultimately I think wine is about more than just running Windows-compatible programs without the Microsoft tax. It's about running those programs without ceding control of your computer to an untrustworthy party. We don't want the limitations that Windows imposes... true bug-for-bug compatibility would mean only being able to access files on a FAT or NTFS partition, but I don't hear anyone advocating for that kind of crippling behavior. > > Thanks > Misha > > p.s. please please please anyone who is familiar with IShellFolder if > you could look over those parts and just say yes it looks good that > would make me feel better. I think it is correct but really an expert's > opinion would be great. > > >

Feb. 12, 2007

wineboot: Start items in StartUp folder on boot, includes security measures. [with the patch]

by Misha Koshelev

I forgot to include the patch, so here it is. Misha --- Hi everybody, Thanks for your suggestions. I just posted a new patch on wine-patches where I tried to incorporate these and now it does the following (in addition to my previous patch which just started items in the StartUp folder): - When wineboot finds a file that it wants to start in the StartUp folder, it asks the user whether he wants to run the program. His options are: Always, Yes, No (default), and Never. - If he selects Yes the program is run, if he select No it is not. - If he selects Always or Never, I create a registry key in: HKEY_CURRENT_USER\Software\Wine\StartupItems with the full pathname of the program and the value "always" or "never." When wineboot sees this program in the StartUp folder it checks this key, and if it is set it performs the appropriate action. What do you guys think? If you like the system, it would be pretty easy to incorporate this into the run key running as well (which are currently just run without any user confirmation)? Thanks Misha

Feb. 11, 2007

RE: wineboot: Start items in StartUp folder on boot, includes security measures.

by Koshelev, Misha Vladislavo

Well, that is what I thought too, I sent out another patch that does not have these anti-security measures, but there were a lot of responses about them being necessary and someone marked the bug report as WILLNOTFIX. Anyhow, both patches have been sent to wine-patches and also are available in the bug report #7384, so I think Alexandre can choose one or the other. Anyone have any comments about the IShellFolder code or jus want to check it over and give me a yay or nay? It works for me, but I just wanted to check with an expert. Misha -----Original Message----- From: James Hawkins [mailto:truiken(a)gmail.com] Sent: Sun 2/11/2007 4:09 PM To: wine-devel(a)winehq.org Cc: Koshelev, Misha Vladislavo Subject: Re: wineboot: Start items in StartUp folder on boot, includes security measures. On 2/11/07, Misha Koshelev <mk144210(a)bcm.tmc.edu> wrote: > Ok, thanks to everybody's responses on the wine-devel list. Here is my > new version of this patch. It starts the items in the StartUp folder > like Windows does (again, if anybody who knows about IShellFolder will > look over my code that would be great :) I tested it and it works for > the Vector NTI installer, but I would really like to have an expert's > opinion on whether it is missing osmething). There were a lot of > comments on wine-devel about malware using this system to start itself > so here is what I added: > > - When wineboot finds a file that it wants to start in the StartUp > folder, it asks the user whether he wants to run the program. His > options are: Always, Yes, No (default), and Never. > - If he selects Yes the program is run, if he select No it is not. > - If he selects Always or Never, I create a registry key in: > HKEY_CURRENT_USER\Software\Wine\StartupItems with the full pathname > of the program and the value "always" or "never." When wineboot sees > this program in the StartUp folder it checks this key, and if it is > set it performs the appropriate action. > > To me it seems like this would be enough to prevent malware from using > this system because the user could just click no or never. Also, someone > pointed out that wineboot already runs quite a lot of other RUN registry > keys that can be used for malware, and currently there is no system for > these keys like the one I made for startup. Any comments will be > appreciated. Thanks. > These anti-malware changes are unnecessary. We implement Wine to be bug-for-bug compatible with Windows. Windows doesn't ask this question, and Wine shouldn't either. It's not our policy to not implement portions of Windows that make it easier for malware to run. -- James Hawkins

Feb. 11, 2007

DIB Engine, some summarization

by Rolf Kalbermatter

This is getting a bit long so if you do not have time, then skip this. I've looked a little more at the issue of a DIB Engine and tried to use the feedback so far to get an idea what the possible architecture could be. First I took a look at how Windows seems to do it currently (excluding Vista). There GDI32 is mostly a wrapper around win32k.sys and the different GDI APIs call mostly into corresponding NtGdi... functions in win32k.sys. Those functions do the actual handling and call the according driver that is attached to the DC. The interface to the driver is similar to what is done now in Wine although not identical. The modern Windows display driver interface uses sometimes more or less different functions than the old one as used in Wine. A driver can either not implement certain functions, only implement them for its device specific surfaces, or hook certain calls by returning flags inside the driver initialization structure on initialization. Those hook flags tell the GDI engine that the driver wants to be called for DIB surfaces too for particular functions and bit depths. The driver will then be called for according DIB surfaces too and it can decide to do whatever it can do best and for those cases it doesn't know well how to do it, call back into the GDI engine using an according Eng... function. This calling back into the GDI engine for hooked functions is called punting by MS. If the driver didn't provide the actual function it will possibly be simulated by the GDI engine by calling other driver functions and if the driver didn't hook the function or didn't succeed and it is for a DIB surface then the GDI engine itself will call the according Eng... function. GDI32 exports most of those Eng... functions too but that are simply user space wrappers around the win32k.sys entry points for those functions. >From a design view it might be interesting to separate the actual GDI engine into a subpart that corresponds with the NtGdi... functions in win32k.sys eventhough they might stay inside GDI32 for the time being. The actual Eng... functions would be also placed inside that GDI engine and are in fact mostly the long awaited DIB engine. Such an architecture would make reuse of such a GDI32/win32k combo in other projects fairly easy. However this NtGdi API is not documented although it is presumably mostly a mirror of the GDI API. There are lists of what APIs win32k.sys does export and how many parameters each of these functions takes, extracted from the actual win32k.sys file. Eventhough Windows keeps them in the win32k.sys kernel I think it would be a good idea to keep them all in GDI32 for the time being. If that API is at some time mostly complete and separation into its own DLL or something would be desired, this could be done quite easily. But it is certainly quite a bit tedious to do and would require at least partly some sort of clean room reverse engineering and it's not really necessary for a DIB engine at all at this point. There is a little problem with those Eng.. functions however. They are modeled after the new NT display driver interface that is in so far different that it does use partly different functions and parameters to the old (I assume Win 3.1 display driver) interface used in Wine and this is even more or less all documented in the DDK, although the basic principle between the Windows driver interface and what Wine does is of course mostly the same. I can't really see however how it would be possible to change that interface to match the modern NT display driver interface in a seemless manner as it would mean a significant change in winex11.drv, winequartz.drv and the GDI32 (aka win32k.sys) that would need to be done mostly in a few big chunks to not completly break everything. So what would remain is adding the actual Eng... and object access API to GDI. These APIs are (all?) documented in the DDK and could be implemented based on MSDN information alone together with maybe some test cases. The actual driver interface might remain mostly the same as it is now with some extra addition to return to the GDI engine extra flags to indicate hooks for DIB surfaces. Then implementation of the Eng... functions would have to start and as they are fleshed out and work they get integrated into the calling logic one for one. Until this is completely done the current separations for DIBs into appstate and serverstate would have to remain, so that the X11 driver can still pass them to the X11 server for rendering of not implemented DIB engine operations. Once the DIB engine is finished (if ever :-) this could be removed as the X11 driver would not anymore hook any of the DIB operations. If winequartz.drv wants to continue hooking DIB operations it can do so of course. To start with, the actual header winddi.h defining most of the Eng.. calls could be added as ddk header to Wine. There seems to be a copyright free version of this header file from Casper S. Hornstrup that is part of the w32api package. I have thought about modifying the driver function call array instead as Alexandre has pointed out in the past as possible solution instead of adding the actual Eng... calls explicitedly into the GDI engine as fall back. But this seems not a good solution to me. The driver wants to be informed of graphic operations for device specific surfaces most often I would assume and only might want to not get called for device contexts containing a dib section. And as some have pointed out winequartz may even want to get called for DIBs too. In order to allow for such a dynamic overriding of function pointers in the driver function array, that array would have to be allocated dynamically on a device context base and I think this would make everything slower, more memory consuming and it wouldn't really be easier although I admit that adding Eng.. calls everywhere and correctly is quite some work to do. The issue about network transparency for the display driver would not be an issue IMO. Once complete the DIB engine would handle all DIB operations locally and so no need for translating direct memory access into remote calls to some display server would be necessary. And the blitting of DIBs to the display when necessary would still be done through the driver of course so everything would be transparent as far as the capabilities of the used display device itself allow for that. Rolf Kalbermatter

Feb. 11, 2007

Re: wineboot: Start items in StartUp folder on boot, includes security measures.

by James Hawkins

On 2/11/07, Misha Koshelev <mk144210(a)bcm.tmc.edu> wrote: > Ok, thanks to everybody's responses on the wine-devel list. Here is my > new version of this patch. It starts the items in the StartUp folder > like Windows does (again, if anybody who knows about IShellFolder will > look over my code that would be great :) I tested it and it works for > the Vector NTI installer, but I would really like to have an expert's > opinion on whether it is missing osmething). There were a lot of > comments on wine-devel about malware using this system to start itself > so here is what I added: > > - When wineboot finds a file that it wants to start in the StartUp > folder, it asks the user whether he wants to run the program. His > options are: Always, Yes, No (default), and Never. > - If he selects Yes the program is run, if he select No it is not. > - If he selects Always or Never, I create a registry key in: > HKEY_CURRENT_USER\Software\Wine\StartupItems with the full pathname > of the program and the value "always" or "never." When wineboot sees > this program in the StartUp folder it checks this key, and if it is > set it performs the appropriate action. > > To me it seems like this would be enough to prevent malware from using > this system because the user could just click no or never. Also, someone > pointed out that wineboot already runs quite a lot of other RUN registry > keys that can be used for malware, and currently there is no system for > these keys like the one I made for startup. Any comments will be > appreciated. Thanks. > These anti-malware changes are unnecessary. We implement Wine to be bug-for-bug compatible with Windows. Windows doesn't ask this question, and Wine shouldn't either. It's not our policy to not implement portions of Windows that make it easier for malware to run. -- James Hawkins

Feb. 11, 2007

Re: wineboot: Start items in StartUp folder on boot, includes security measures.

by Joris Huizer

It seems the patch itself got lost ____________________________________________________________________________________ Food fight? Enjoy some healthy debate in the Yahoo! Answers Food & Drink Q&A. http://answers.yahoo.com/dir/?link=list&sid=396545367

Feb. 11, 2007

wineboot: Start items in StartUp folder on boot, includes security measures.

by Misha Koshelev

Hi everybody, Thanks for your suggestions. I just posted a new patch on wine-patches where I tried to incorporate these and now it does the following (in addition to my previous patch which just started items in the StartUp folder): - When wineboot finds a file that it wants to start in the StartUp folder, it asks the user whether he wants to run the program. His options are: Always, Yes, No (default), and Never. - If he selects Yes the program is run, if he select No it is not. - If he selects Always or Never, I create a registry key in: HKEY_CURRENT_USER\Software\Wine\StartupItems with the full pathname of the program and the value "always" or "never." When wineboot sees this program in the StartUp folder it checks this key, and if it is set it performs the appropriate action. What do you guys think? If you like the system, it would be pretty easy to incorporate this into the run key running as well (which are currently just run without any user confirmation)? Thanks Misha p.s. please please please anyone who is familiar with IShellFolder if you could look over those parts and just say yes it looks good that would make me feel better. I think it is correct but really an expert's opinion would be great.

Feb. 11, 2007

Re: DirectX related question

by Tim Schmidt

On 2/11/07, Tom Wickline <twickline(a)gmail.com> wrote: > Fix the bugs in Wine and send your patches to wine-patches. > > File bug reports pertaining to this game, as well as become a maintainer > for the game in our AppDB: > http://appdb.winehq.org/appview.php?iAppId=4051 > > Purchase a copy of CrossOver and vote for DirectX support: > http://www.codeweavers.com/compatibility/browse/name?app_id=249 I'll purchase crossover, but it looks like SupComm wants pixel shader 2.0, so I was thinking more along the lines of someone who wants to hack on DirectX 10, but has no DirectX 10 capable hardware. Or no DirectX 10 games to test against, etc. Anyone? --tim

Feb. 11, 2007

Re: comtctl32 : updown : Getter and Setter Tests for Updown control

by Leslie Choong

Thanks for the input. UDM_SETRANGE has no return value according to MSDN so I'll remove those assignments. On 2/11/07, James Hawkins <truiken(a)gmail.com> wrote: > On 2/10/07, Leslie Choong <septikus(a)gmail.com> wrote: > > Hi there, My name is Leslie Choong and I am currently finishing up my > > under graduate work at UCLA. This patch is being sent as part of the > > coursework for CS 130 : Software Engineering. Please take a look and > > let me know if you have any suggestions or comments for change. > > Thanks! > > -Leslie Choong > > > > + /* Set Range from 0 to 100 */ > + r = SendMessage(updown, UDM_SETRANGE, 0 , MAKELONG(100,0) ); > + r= SendMessage(updown, UDM_GETRANGE, 0,0); > > If you're not going to check the first return value, then take out the > 'r =', else it seems like you're missing a test. On the other hand, > why don't you test the return value? > > -- > James Hawkins >

Feb. 11, 2007

Re: First implementation of a directplay service provider

by Kai Blin

On Saturday 10 February 2007 19:39, Alessandro Pignotti wrote: > I'm working to implement a service provider compatible with the protocol > used by directplay over TCP/IP. > Currently i've implemented the lobby code and tested it against > simpleconnect.exe and chatconnect.exe from the DirectX 7 SDK. At the very end of the patch, you missed a C++ style comment. (+ data->dwReserved1=0x1f4; //Values taken from registry (are they useful at all?)) Btw, I think you should set that data to NULL for now, rather than any random magic value. You shouldn't need the +#define LOBBYINFORMATIONFLAG_CLIENTSERVER 0x00000001 +#define LOBBYINFORMATIONFLAG_MIGRATEHOST 0x00000004 +#define LOBBYINFORMATIONFLAG_NODPSRV 0x00000040 +#define LOBBYINFORMATIONFLAG_PASSWORD 0x00000080 +#define LOBBYINFORMATIONFLAG_NOENUMS 0x00000100 +#define LOBBYINFORMATIONFLAG_FASTSIGN 0x00000200 +#define LOBBYINFORMATIONFLAG_FULLSIGN 0x00000400 +#define LOBBYINFORMATIONFLAG_ENCAPSULATE 0x00002000 stuff, as dplay.h defines that already, iirc. + inf->lobbyID=0x01020304;//Just a fixed Id now, will randomize someday There is some pattern to the DPIDs after the first. They're not random. I just didn't quite figure out how it works yet. Btw, you missed a C++ style comment there.. A few lines over that line, too. You're not sending a dplay version in your header so far. Is that intentional? Why are you declaring dummy functions and then comment out setting them in SPInit()? Good work, anyhow. Kai -- Kai Blin, <kai Dot blin At gmail Dot com> WorldForge developer http://www.worldforge.org/ Wine developer http://wiki.winehq.org/KaiBlin/ -- Will code for cotton.

Feb. 11, 2007

Re: comtctl32 : updown : Getter and Setter Tests for Updown control

by James Hawkins

On 2/10/07, Leslie Choong <septikus(a)gmail.com> wrote: > Hi there, My name is Leslie Choong and I am currently finishing up my > under graduate work at UCLA. This patch is being sent as part of the > coursework for CS 130 : Software Engineering. Please take a look and > let me know if you have any suggestions or comments for change. > Thanks! > -Leslie Choong > + /* Set Range from 0 to 100 */ + r = SendMessage(updown, UDM_SETRANGE, 0 , MAKELONG(100,0) ); + r= SendMessage(updown, UDM_GETRANGE, 0,0); If you're not going to check the first return value, then take out the 'r =', else it seems like you're missing a test. On the other hand, why don't you test the return value? -- James Hawkins

Feb. 11, 2007

Re: opengl code, WoW and graphic cards with 64MB video memory

by Stefan Dösinger

Am Samstag 10 Februar 2007 15:44 schrieb Chris Robinson: > AFAIK, OpenGL doesn't really care how much video memory you have. If you > run out, it'll just start hapilly swapping to your system RAM automatically > (with a nice performance hit). If your system RAM runs out, then you can > have problems. Yes, opengl does not have the concept of video memory like DirectX has. OpenGL implementations can work without video memory, for example mesa software rendering, or rendering using a remote opengl server. On implementations with video memory, the opengl driver has to take care of that. The way it does that is transparent to wine and the applications. > That error, though, looks like its trying to use an extension that the > driver/card doesn't fully support. It gets a NULL pointer for some > function, tries to call it without checking, and you get a nice NULL > pointer dereference. It doesn't have to be caused by opengl at all.

Feb. 11, 2007

Re: DirectX related question

by Tom Wickline

On 2/11/07, Tim Schmidt <timschmidt(a)gmail.com> wrote: > Already looking at buying a new computer to play Supreme Commander > (http://en.wikipedia.org/wiki/Supreme_commander) is there anything I > can do (including, but not limited to purchasing hardware) to help get > this game running under Wine? I can't promise miracles, but if I can > break down a few obstacles, consider it done. Fix the bugs in Wine and send your patches to wine-patches. File bug reports pertaining to this game, as well as become a maintainer for the game in our AppDB: http://appdb.winehq.org/appview.php?iAppId=4051 Purchase a copy of CrossOver and vote for DirectX support: http://www.codeweavers.com/compatibility/browse/name?app_id=249 Tom > > --tim > > >

Feb. 11, 2007

Re: signedness/WINAPI changing question

by Francois Gouget

On Sat, 10 Feb 2007, Joris Huizer wrote: > > I find some function > LONG WINAPI AVIStreamSampleToTime(PAVISTREAM > pstream, LONG lSample) > (in the avifil32 dll), the second parameter should > really be an ULONG instead of a LONG. It'd fix the > signedness problems. > > My question is, is such a change allowed? No. Our headers must match the PSDK ones otherwise it would cause trouble for people trying to recompile Windows code with them. Since the PSDK says the second parameter is a LONG, that's what we have to use too. -- Francois Gouget <fgouget(a)free.fr> http://fgouget.free.fr/ In theory, theory and practice are the same, but in practice they're different.

Feb. 11, 2007

Re: signedness/WINAPI changing question

by Michael Stefaniuc

Joris Huizer wrote: > I have a small question: > > I find some function > LONG WINAPI AVIStreamSampleToTime(PAVISTREAM > pstream, LONG lSample) > (in the avifil32 dll), the second parameter should > really be an ULONG instead of a LONG. It'd fix the > signedness problems. > > My question is, is such a change allowed? If it is a official WinAPI you have to conform to what Windows has there. If it is an internal function you can change it. > And what should I do to update for such a change > (except for the header gcc warns about) > > In case such change must not be performed, I'll just > add a local variable which is a casted version. > I thought this needs asking; adding in unnecessary > variables doesn't seem the best fix to me. bye michael -- Michael Stefaniuc Tel.: +49-711-96437-199 Sr. Network Engineer Fax.: +49-711-96437-111 Red Hat GmbH Email: mstefani(a)redhat.com Hauptstaetterstr. 58 http://www.redhat.de/ D-70178 Stuttgart

Feb. 11, 2007

Re: doc: Add a Quick start to the Wine User Guide

by Daniel

On Sun, Feb 11, 2007 at 07:32:10PM +1100, Jeff L wrote: > + Run wine using the <link > + linkend="running"><emphasis><filename>wine</> > + <filename>filespec/appname.exe</></></link> command. This > + The first command you will run will be to install a package. > + Typically something like <filename>wine > + /media/cdrom/setup.exe</> or the equivalent. and this is asking for pain. $ cd filespec && wine appname.exe and $ cd /media/cdrom && wine setup.exe are what you want to use. Daniel -- A: Because it reverses the logical flow of conservation. Q: Why is top posting frowned upon?

Feb. 11, 2007

doc: Add a Quick start to the Wine User Guide

by Jeff L

This change came about when a friend described his problems in getting wine going to see if it would help him with making a Windows app run under Linux. He did not want to get into the details of wine as his was a opportunistic need and his comment that hit home was "that many a newbie expects software to just install but wine seems too complicated and there is not a cheat sheet". It seems that there is nowhere where the basics are described step by step for the first time casual user. Jeff Latimer Index: en/wineusr-introduction.sgml =================================================================== RCS file: /cvsroot/wine/docs/en/wineusr-introduction.sgml,v retrieving revision 1.4 diff -u -u -r1.4 wineusr-introduction.sgml --- en/wineusr-introduction.sgml 12 Dec 2006 04:11:06 -0000 1.4 +++ en/wineusr-introduction.sgml 11 Feb 2007 08:04:31 -0000 @@ -52,6 +52,50 @@ </para> </sect2> + <sect2> + <title>Quick start</title> + <para> + The process of installing and running wine can be summarised as + follows: + <itemizedlist> + <listitem> + <para> + Get a distribution as indicated in <link + linkend="getting-wine">Getting Wine</link> and see + the <ulink url="http://www.winehq.org/site/download">Wine + Downloads</> page. For the casual or new user the simplest + is to get an rpm distribution. + </para> + </listitem> + <listitem> + <para> + Configure wine using the <link + linkend="config-wine-main"><emphasis><filename>winecfg</></> + </link> command. For most people wine should now be usable. + </para> + </listitem> + <listitem> + <para> + To test your installation run wine's Windows 3.1 like file + manager using the <filename>wine winefile</> command. + </para> + </listitem> + <listitem> + <para> + Run wine using the <link + linkend="running"><emphasis><filename>wine</> + <filename>filespec/appname.exe</></></link> command. + </para> + <para> + The first command you will run will be to install a package. + Typically something like <filename>wine + /media/cdrom/setup.exe</> or the equivalent. + </para> + </listitem> + </itemizedlist> + </para> + </sect2> + </sect1> <sect1 id="what-is-wine">

Feb. 11, 2007

DirectX related question

by Tim Schmidt

Already looking at buying a new computer to play Supreme Commander (http://en.wikipedia.org/wiki/Supreme_commander) is there anything I can do (including, but not limited to purchasing hardware) to help get this game running under Wine? I can't promise miracles, but if I can break down a few obstacles, consider it done. --tim

Feb. 11, 2007

Re: wineboot: Start items in StartUp folder on boot.

by richardvoigt＠gmail.com

On 2/10/07, Jacob Alberty <jacob.alberty(a)vetmanage.com> wrote: > Why not integrate this functionality into wineboot? That way if a user wants > to completely deny the start-up folder they can just not add wineboot to the > list of programs to be started on login, but if they want that functionality > they can simply add wineboot to the list of programs for start up when they > login? It would allow similar functionality to windows whilst still keeping > it a separate system. I think everyone agrees that wineboot is where this functionality should be, if it's implemented at all? Well, part of my idea was that even if the configuration option is set to "silently deny", any option that was previously accepted with the don't ask again option checked (or Always in case wine has buttons for Never, Not This Time, Run This Time, Always) would still execute, which is rather different from totally disabling wineboot. Then you could presumably run wineboot explicitly or some helper program, in order to manage the entries. > > > On 2/10/07, richardvoigt(a)gmail.com <richardvoigt(a)gmail.com> wrote: > > On 2/10/07, David Lichterman <laviddichterman(a)gmail.com > wrote: > > > Stefan Dösinger wrote: > > > > Am Samstag 10 Februar 2007 05:20 schrieb Vitaliy Margolen: > > > >> 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. > > > > Malicious programs can also write themselves to > > > > HKLM/Software/Microsoft/Windows/Run, a key that > wineboot reads. So I do not > > > > see any advantage in implementing the Run key, but not the autostart > folder. > > > > > > > > > > > > > ------------------------------------------------------------------------ > > > > > > > > > > > I second that opinion. I do computer tech support (ie getting viruses > > > and spy/malware off of windows) at my university and if there's a case > > > for not implementing one of those two run at boot features, disabling > > > the Run key would be the stronger since most, if not all malicious > > > programs now use the run registry location as opposed to the Startup > folder. > > > > > > It really comes down to the amount of power a user should have. Maybe > > > require a gksu whenever an app tries to write something to that folder > > > or that registry location? > > > > What a gksu? > > > > How about prompting the user during startup? > > > > e.g., "Start <title> using command line <program + args>? Yes/No ([x] > > Don't ask again" > > Don't ask again items could either be stored as hash codes in a > > configuration file outside the wine filesystem, or else by deleting > > command/moving to a usual Unixy autostart location. > > > > This should be done for all startup programs, whether start menu or > registry. > > > > It would be the best of both worlds, it works as expected for the user > > without requiring them to give up control of their system. > > > > There could even be a winecfg option whether to prompt the user, > > silently allow, automatically+loudly deny, or silently deny. > > > > > > > >

Feb. 11, 2007

Re: Comctl32 Status Bar Test

by Felix Nawothnig

Alex Arazi wrote: > - ok(rc.top == 2, "Expected 2, got %d\n", rc.top); > - ok(rc.bottom == 21, "Expected 21, got %d\n", rc.bottom); > - ok(rc.left == 0, "Expected 0, got %d\n", rc.left); > - ok(rc.right == 50, "Expected 50, got %d\n", rc.right); I didn't really look at your new tests but the second of those tests you removed failed ("got 1" IIRC) on Windows (XP) because we don't create a parent window (and because the 21 is wrong. Should be 22 IIRC) - native comctl32 sometimes does some strange stuff when a control doesn't have one - so the test should create it. Felix

Feb. 11, 2007

Re: wineboot: Start items in StartUp folder on boot.

by Jacob Alberty

Why not integrate this functionality into wineboot? That way if a user wants to completely deny the start-up folder they can just not add wineboot to the list of programs to be started on login, but if they want that functionality they can simply add wineboot to the list of programs for start up when they login? It would allow similar functionality to windows whilst still keeping it a separate system. On 2/10/07, richardvoigt(a)gmail.com <richardvoigt(a)gmail.com> wrote: > > On 2/10/07, David Lichterman <laviddichterman(a)gmail.com> wrote: > > Stefan Dösinger wrote: > > > Am Samstag 10 Februar 2007 05:20 schrieb Vitaliy Margolen: > > >> 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. > > > Malicious programs can also write themselves to > > > HKLM/Software/Microsoft/Windows/Run, a key that wineboot reads. So I > do not > > > see any advantage in implementing the Run key, but not the autostart > folder. > > > > > > > > > > ------------------------------------------------------------------------ > > > > > > > > I second that opinion. I do computer tech support (ie getting viruses > > and spy/malware off of windows) at my university and if there's a case > > for not implementing one of those two run at boot features, disabling > > the Run key would be the stronger since most, if not all malicious > > programs now use the run registry location as opposed to the Startup > folder. > > > > It really comes down to the amount of power a user should have. Maybe > > require a gksu whenever an app tries to write something to that folder > > or that registry location? > > What a gksu? > > How about prompting the user during startup? > > e.g., "Start <title> using command line <program + args>? Yes/No ([x] > Don't ask again" > Don't ask again items could either be stored as hash codes in a > configuration file outside the wine filesystem, or else by deleting > command/moving to a usual Unixy autostart location. > > This should be done for all startup programs, whether start menu or > registry. > > It would be the best of both worlds, it works as expected for the user > without requiring them to give up control of their system. > > There could even be a winecfg option whether to prompt the user, > silently allow, automatically+loudly deny, or silently deny. > > >

Feb. 11, 2007

Re: wineboot: Start items in StartUp folder on boot.

by richardvoigt＠gmail.com

On 2/10/07, David Lichterman <laviddichterman(a)gmail.com> wrote: > Stefan Dösinger wrote: > > Am Samstag 10 Februar 2007 05:20 schrieb Vitaliy Margolen: > >> 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. > > Malicious programs can also write themselves to > > HKLM/Software/Microsoft/Windows/Run, a key that wineboot reads. So I do not > > see any advantage in implementing the Run key, but not the autostart folder. > > > > > > ------------------------------------------------------------------------ > > > > > I second that opinion. I do computer tech support (ie getting viruses > and spy/malware off of windows) at my university and if there's a case > for not implementing one of those two run at boot features, disabling > the Run key would be the stronger since most, if not all malicious > programs now use the run registry location as opposed to the Startup folder. > > It really comes down to the amount of power a user should have. Maybe > require a gksu whenever an app tries to write something to that folder > or that registry location? What a gksu? How about prompting the user during startup? e.g., "Start <title> using command line <program + args>? Yes/No ([x] Don't ask again" Don't ask again items could either be stored as hash codes in a configuration file outside the wine filesystem, or else by deleting command/moving to a usual Unixy autostart location. This should be done for all startup programs, whether start menu or registry. It would be the best of both worlds, it works as expected for the user without requiring them to give up control of their system. There could even be a winecfg option whether to prompt the user, silently allow, automatically+loudly deny, or silently deny.

Feb. 11, 2007

Re: wineshelllink: disable startup notification

by Alexander Nicolaysen Sørnes

Fredag 09 februar 2007 18:25, skrev Tijl Coosemans: > Wine doesn't support startup notification afaict and endlessly bouncing > cursors are annoying. Wine does support startup notifications, but not if the 'enable window manager to control windows applications' is disabled in winecfg. Regards, Alexander N. Sørnes > > --- tools/wineshelllink.orig Fri Feb 9 17:46:58 2007 > +++ tools/wineshelllink Fri Feb 9 17:59:14 2007 > @@ -88,6 +88,7 @@ > [Desktop Entry] > Name=$linkname > Exec=wine "$path" $args > +StartupNotify=false > Type=Application > EOF > [ -z "$descr" ] || echo "Comment=$descr"

Feb. 10, 2007

Re: wineboot: Start items in StartUp folder on boot.

by David Lichterman

Stefan Dösinger wrote: > Am Samstag 10 Februar 2007 05:20 schrieb Vitaliy Margolen: >> 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. > Malicious programs can also write themselves to > HKLM/Software/Microsoft/Windows/Run, a key that wineboot reads. So I do not > see any advantage in implementing the Run key, but not the autostart folder. > > > ------------------------------------------------------------------------ > > I second that opinion. I do computer tech support (ie getting viruses and spy/malware off of windows) at my university and if there's a case for not implementing one of those two run at boot features, disabling the Run key would be the stronger since most, if not all malicious programs now use the run registry location as opposed to the Startup folder. It really comes down to the amount of power a user should have. Maybe require a gksu whenever an app tries to write something to that folder or that registry location? /2cents -Dave

Feb. 10, 2007

Handling of EXCEPTION_BREAKPOINT

by Vitaliy Margolen

It seems Wine has problems with correct return address for the int3 brakepoint exception. It's covered in bug http://bugs.winehq.org/show_bug.cgi?id=7063 There is even a test case with a proposed fixes. Can anyone with knowledge of the debugger events take a look at it? If the patch can be committed Wine will get that much closer to the supporting more unti-debugger protection schemes. Vitaliy Margolen.

Feb. 10, 2007

Fullscreen broken in XVidMode

by Vitaliy Margolen

For about a month now Wine is completely unusable for fullscreen games when using XVidMode instead of XRandr extension. Worse, this is a regression, caused by this patch: f6702ec4afb4098cbb67d6bd670a9f0527191f80 is first bad commit commit f6702ec4afb4098cbb67d6bd670a9f0527191f80 Author: Dmitry Timoshkov Date: Tue Jan 9 23:57:33 2007 +0800 winex11.drv: Force the fullscreen state update once the window is mapped. :040000 040000 f83b3a76eeecd52a04ed04201c49ac15244b0a25 d57c3162633300eabdb9fea65d530eb91cd929f5 M dlls Can we get some ideas going about why this is happening and how to fix it? Vitaliy Margolen.

Feb. 10, 2007

Re: opengl code, WoW and graphic cards with 64MB video memory

by Chris Robinson

On Saturday 10 February 2007 06:24:04 am Nick Law wrote: > It could be just a coincidence, however it seems that most users that > have the problem where WoW hangs after login in, seem to have graphics > cards with 64MB memory. Is it possible that the opengl code may not > handle a condition where memory runs out on the graphics card and > generates the following error .. > > /The instruction at '0x00000000' referenced memory at '0x00000000'. > The memory could not be "read"./ > > Does the opengl code test for such a condition or does it assume there > is an infinite amount of graphics card memory and the application should > test for this anyway ? AFAIK, OpenGL doesn't really care how much video memory you have. If you run out, it'll just start hapilly swapping to your system RAM automatically (with a nice performance hit). If your system RAM runs out, then you can have problems. That error, though, looks like its trying to use an extension that the driver/card doesn't fully support. It gets a NULL pointer for some function, tries to call it without checking, and you get a nice NULL pointer dereference.

Feb. 10, 2007

opengl code, WoW and graphic cards with 64MB video memory

by Nick Law

This is probably a question for Roderick or Stefan or anybody that is familiar with the opengl code in wine. It could be just a coincidence, however it seems that most users that have the problem where WoW hangs after login in, seem to have graphics cards with 64MB memory. Is it possible that the opengl code may not handle a condition where memory runs out on the graphics card and generates the following error .. /The instruction at '0x00000000' referenced memory at '0x00000000'. The memory could not be "read"./ Does the opengl code test for such a condition or does it assume there is an infinite amount of graphics card memory and the application should test for this anyway ? Regards Nick Law

Feb. 10, 2007

signedness/WINAPI changing question

by Joris Huizer

I have a small question: I find some function LONG WINAPI AVIStreamSampleToTime(PAVISTREAM pstream, LONG lSample) (in the avifil32 dll), the second parameter should really be an ULONG instead of a LONG. It'd fix the signedness problems. My question is, is such a change allowed? And what should I do to update for such a change (except for the header gcc warns about) In case such change must not be performed, I'll just add a local variable which is a casted version. I thought this needs asking; adding in unnecessary variables doesn't seem the best fix to me. regards, Joris ____________________________________________________________________________________ Don't pick lemons. See all the new 2007 cars at Yahoo! Autos. http://autos.yahoo.com/new_cars.html

Feb. 10, 2007

Re: Wine beta ASIO-driver.

by Tom Wickline

On 2/9/07, Tor Einar Tønnessen <t.e.tonnessen(a)losmail.no> wrote: > > 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. You may want to read this post and the thread : http://www.winehq.org/pipermail/wine-devel/2006-September/050639.html Tom > > Tor Einar >

Feb. 10, 2007

Re: Some thoughts about the ominous DIB Engine

by Stefan Dösinger

Am Samstag 10 Februar 2007 09:49 schrieb Rolf Kalbermatter: > Felix Nawothnig wrote: > >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 > > Well, this would mostly mirror the Windows architecture nowadays where > almost all of this is in win32k.sys and GDI32 is mostly a user space > wrapper around that. A bit like ntdll does for kernel operations. > > But I would be a bit concerned about performance if most calls have to > be passed to the server side to be handled but maybe that is not really > an issue? Didn't MS put part of the GDI somehow back in user space when > going from NT4 to 2K just because of performance concerns? I think performance could be ok if we use shared memory to get the dibs in and out of the server, but I think Alexandre does not like shmmem for the one or other reason. Afaik MS had GDI in user space in NT 3.5, but for performance reasons they put it into the kernel in 4.0 and win95. But I think for windows some considerations regarding hardware acceleration also apply. If I understand things correctly, performance problems occur if a DIB section is switched from server mode to app mode, or vice versa. As long as it stays in one or the other mode it is fine. DirectDraw is a much simpler interface than GDI. DDraw currently draws mainly in appmod, problems occur if GetDC is used on a surface. This could maybe avoided if the ddraw implementation was changed to use GDI for blitting too, instead of its own code. However, problems will occur if the application Locks the surface. So I think this would only shift the problem to other apps, and it would not help Direct3D apps, or opengl accelerated DirectDraw.

Feb. 10, 2007

Re: wineboot: Start items in StartUp folder on boot.

by Stefan Dösinger

Am Samstag 10 Februar 2007 05:20 schrieb Vitaliy Margolen: > 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. Malicious programs can also write themselves to HKLM/Software/Microsoft/Windows/Run, a key that wineboot reads. So I do not see any advantage in implementing the Run key, but not the autostart folder.

Feb. 10, 2007

name conflicts - Wine and OpenWatcom

by Wesley Parish

I'm running Mandriva 2k7 and started installing Wine. The installation stalled on discovering I have OpenWatcom installed. Wine didn't like /usr/bin/wrc, the OpenWatcom Windows Resource Compiler. I could rename wrc to wwrc - what would people suggest? Wesley Parish -- Clinersterton beademung, with all of love - RIP James Blish ----- Mau e ki, he aha te mea nui? You ask, what is the most important thing? Maku e ki, he tangata, he tangata, he tangata. I reply, it is people, it is people, it is people.

Feb. 10, 2007

Re: Helping a user migrate an odbc app to Wine

by Stefan Munz

Am Donnerstag, 8. Februar 2007 08:23 schrieb Kai Blin: > On Thursday 08 February 2007 01:42, Dan Kegel wrote: > > Can somebody help this (german-speaking) fellow: > > http://www.unixboard.de/vb3/showthread.php?t=26943 > > > > He says his company's internal application requires > > you to input a DSN when installing it, and he doesn't > > know how to come up with a DSN under Wine. > > The german speaking part is not a problem, I just don't know my way around > that odbc stuff, not even on win32 native. > > > Presumably he doesn't want to mess with Unixodbc, > > he just wants to keep using the Microsoft drivers...? > > I figure using the appropriate native dlls would work? > I vaguely remember Windows had a tool to set up odbc drivers, what was the > exe called? it is located in windows/system32 normally. Something like odbcconf.exe or odbcad32.exe. With one of those you can create a DSN and after that provide it to the app. I post a similiar reply in the unixboard. cu, Stefan -- Dipl.-Inform. Stefan Munz. . . . . . . . . . stefan.munz(a)itomig.de ITOMIG GbR . . . . . . . . . . . . . . . . . www.itomig.de Sand 14 . . . . . . . . . . . . . . . . . . mobil: +49 178 729 72 72 D-72076 Tübingen . . . . . . . . . . . . . .

Feb. 10, 2007

Re: Some thoughts about the ominous DIB Engine

by Rolf Kalbermatter

Felix Nawothnig wrote: >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 Well, this would mostly mirror the Windows architecture nowadays where almost all of this is in win32k.sys and GDI32 is mostly a user space wrapper around that. A bit like ntdll does for kernel operations. But I would be a bit concerned about performance if most calls have to be passed to the server side to be handled but maybe that is not really an issue? Didn't MS put part of the GDI somehow back in user space when going from NT4 to 2K just because of performance concerns? Would still remain the question where and how to hook this into dib handling but I think GDI would be better. Basically call the dc driver and if that fails branch into the local dibeng API for apropriate functions. Rolf Kalbermatter

Feb. 10, 2007

Re: wineboot: Start items in StartUp folder on boot.

by John Smith

I thought wine's goal was "bug for bug" with windows, for good or for ill. On 2/9/07, Misha Koshelev <mk144210(a)bcm.tmc.edu> 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 > > >

Feb. 10, 2007

Re: wineboot: Start items in StartUp folder on boot.

by Misha Koshelev

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

Feb. 10, 2007

Re: wineboot: Start items in StartUp folder on boot.

by Vitaliy Margolen

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.

Feb. 10, 2007

wineboot: Start items in StartUp folder on boot.

by Misha Koshelev

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

Feb. 10, 2007

Re: winecfg: Add check for device access to Drives tab.

by Vitaliy Margolen

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.

Feb. 9, 2007

Re: shell32[3/3]: allow overwriting files in SHFileOperation(FO_COPY) (with confirmation dialogs, fixes bug #7046)

by James Hawkins

On 2/9/07, Mikołaj Zalewski <mikolaj(a)zalewski.pl> 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?= <mikolaj(a)zalewski.pl> > 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 */ > IDS_RESTART_TITLE "Neustarten" > diff --git a/dlls/shell32/shell32_En.rc b/dlls/shell32/shell32_En.rc > index 09530c6..a67cc8a 100644 > --- a/dlls/shell32/shell32_En.rc > +++ b/dlls/shell32/shell32_En.rc > @@ -185,8 +185,12 @@ STRINGTABLE DISCARDABLE > IDS_TRASHFOLDER_TEXT "Are you sure that you want to send '%1' and all it's content to the Trash?" > IDS_TRASHMULTIPLE_TEXT "Are you sure that you want to send these %1 items to the Trash?" > IDS_CANTTRASH_TEXT "The item '%1' can't be sent to Trash. Do you want to delete it instead?" > - IDS_OVERWRITEFILE_TEXT "OverWrite File %1?" > - IDS_OVERWRITEFILE_CAPTION "Confirm File OverWrite" > + IDS_OVERWRITEFILE_TEXT "This folder already contains a file called '%1'.\n\nDo you want to replace it?" > + IDS_OVERWRITEFILE_CAPTION "Confirm file overwrite" > + 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 "Restart" > diff --git a/dlls/shell32/shell32_Eo.rc b/dlls/shell32/shell32_Eo.rc > index e8fa407..3bfca07 100644 > --- a/dlls/shell32/shell32_Eo.rc > +++ b/dlls/shell32/shell32_Eo.rc > @@ -163,8 +163,12 @@ STRINGTABLE DISCARDABLE > IDS_DELETEFOLDER_CAPTION "Konfirmu forigon de dosierujo" > IDS_DELETEITEM_TEXT "Жu vi estas certa pri forigo de '%1'?" > IDS_DELETEMULTIPLE_TEXT "Жu vi estas certa pri forigo de жi tiuj %1 komponantoj?" > - IDS_OVERWRITEFILE_TEXT "Жu vi supreskribas la dosieron %1?" > + IDS_OVERWRITEFILE_TEXT "This folder already contains a file called '%1'.\n\nDo you want to replace it?" > IDS_OVERWRITEFILE_CAPTION "Konfirmu supreskribiton de dosieron" > + 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_Es.rc b/dlls/shell32/shell32_Es.rc > index dd83a6e..c3d2f4c 100644 > --- a/dlls/shell32/shell32_Es.rc > +++ b/dlls/shell32/shell32_Es.rc > @@ -162,8 +162,12 @@ STRINGTABLE DISCARDABLE > IDS_DELETEFOLDER_CAPTION "Confirmar eliminaciуn de carpeta" > IDS_DELETEITEM_TEXT "їSeguro que desea eliminar '%1'?" > IDS_DELETEMULTIPLE_TEXT "їSeguro que desea eliminar estos %1 elementos?" > - IDS_OVERWRITEFILE_TEXT "їSobreescribir el archivo '%1'?" > + IDS_OVERWRITEFILE_TEXT "This folder already contains a file called '%1'.\n\nDo you want to replace it?" > IDS_OVERWRITEFILE_CAPTION "Confirmar sobreescritura de archivo" > + 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_Fi.rc b/dlls/shell32/shell32_Fi.rc > index e842bbd..e43a94e 100644 > --- a/dlls/shell32/shell32_Fi.rc > +++ b/dlls/shell32/shell32_Fi.rc > @@ -164,8 +164,12 @@ STRINGTABLE DISCARDABLE > IDS_DELETEFOLDER_CAPTION "Vahvista kansion tuhoaminen" > IDS_DELETEITEM_TEXT "Haluatko varmasti tuhota '%1':n?" > IDS_DELETEMULTIPLE_TEXT "Haluatko varmasti tuhota nдmд %1?" > - IDS_OVERWRITEFILE_TEXT "Ylikirjoita tiedosto %1?" > + IDS_OVERWRITEFILE_TEXT "This folder already contains a file called '%1'.\n\nDo you want to replace it?" > IDS_OVERWRITEFILE_CAPTION "Vahvista tiedoston ylikirjoitus" > + 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 "Kдynnistд uudelleen" > diff --git a/dlls/shell32/shell32_Fr.rc b/dlls/shell32/shell32_Fr.rc > index 043c66c..246045c 100644 > --- a/dlls/shell32/shell32_Fr.rc > +++ b/dlls/shell32/shell32_Fr.rc > @@ -176,8 +176,12 @@ STRINGTABLE DISCARDABLE > IDS_TRASHFOLDER_TEXT "Кtes-vous sыr de vouloir mettre «%1» et tout ce qu'il contient dans la corbeille?" > IDS_TRASHMULTIPLE_TEXT "Кtes-vous sыr de vouloir mettre ces %1 йlйments dans la corbeille?" > IDS_CANTTRASH_TEXT "L'йlйment «%1» ne peut pas кtre mis dans la corbeille. Souhaitez-vous le supprimer а la place?" > - IDS_OVERWRITEFILE_TEXT "Йcraser le fichier %1?" > + IDS_OVERWRITEFILE_TEXT "This folder already contains a file called '%1'.\n\nDo you want to replace it?" > IDS_OVERWRITEFILE_CAPTION "Confirmer l'йcrasement du fichier" > + 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 "Redйmarrer" > diff --git a/dlls/shell32/shell32_It.rc b/dlls/shell32/shell32_It.rc > index 809f44a..19f7339 100644 > --- a/dlls/shell32/shell32_It.rc > +++ b/dlls/shell32/shell32_It.rc > @@ -164,8 +164,12 @@ STRINGTABLE DISCARDABLE > IDS_DELETEFOLDER_CAPTION "Confermare la cancellazione della cartella" > IDS_DELETEITEM_TEXT "Sei sicuro di voler cancellare '%1'?" > IDS_DELETEMULTIPLE_TEXT "Sei sicuro di voler cancellare questi %1 elementi?" > - IDS_OVERWRITEFILE_TEXT "Sovrascrivere il File %1?" > + IDS_OVERWRITEFILE_TEXT "This folder already contains a file called '%1'.\n\nDo you want to replace it?" > IDS_OVERWRITEFILE_CAPTION "Confermare la sovrascrizione del File" > + 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 "Riavvia" > diff --git a/dlls/shell32/shell32_Ko.rc b/dlls/shell32/shell32_Ko.rc > index 413ad7b..bb00f83 100644 > --- a/dlls/shell32/shell32_Ko.rc > +++ b/dlls/shell32/shell32_Ko.rc > @@ -173,8 +173,12 @@ IDS_TRASHITEM_TEXT "ґзЅЕАє '%1' А»(ё¦) ИЮБцЕлАё·О єёі»±вё¦ №Щ¶шґП±о?" > IDS_TRASHFOLDER_TEXT "ґзЅЕАє '%1' °ъ ±Ч ѕИАЗ і»їлА» ИЮБцЕлАё·О єёі»±вё¦ №Щ¶шґП±о?" > IDS_TRASHMULTIPLE_TEXT "ґзЅЕАє '%1' µйА»(ё¦) ИЮБцЕлАё·О єёі»±вё¦ №Щ¶шґП±о?" > IDS_CANTTRASH_TEXT "The item '%1' can't be sent to Trash. Do you want to delete it instead?" > -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 "ЖДАП µ¤ѕоѕІ±в И(r)АО" > +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_No.rc b/dlls/shell32/shell32_No.rc > index a7ad4f4..c7ec269 100644 > --- a/dlls/shell32/shell32_No.rc > +++ b/dlls/shell32/shell32_No.rc > @@ -172,8 +172,12 @@ STRINGTABLE DISCARDABLE > IDS_TRASHFOLDER_TEXT "Virkelig legge «%1» og alt innholdet i papirkurven?" > IDS_TRASHMULTIPLE_TEXT "Virkelig legge disse %1 valgte elementene i papirkurven?" > IDS_CANTTRASH_TEXT "Elementet «%1» kan ikke legges i papirkurven. Vil du slette det i stedet?" > - IDS_OVERWRITEFILE_TEXT "Overskrive filen «%1»?" > + IDS_OVERWRITEFILE_TEXT "This folder already contains a file called '%1'.\n\nDo you want to replace it?" > IDS_OVERWRITEFILE_CAPTION "Bekreft overskriving av fil" > + 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 "Starte pе nytt" > diff --git a/dlls/shell32/shell32_Pl.rc b/dlls/shell32/shell32_Pl.rc > index 60b6a75..d6139e7 100644 > --- a/dlls/shell32/shell32_Pl.rc > +++ b/dlls/shell32/shell32_Pl.rc > @@ -173,8 +173,12 @@ STRINGTABLE DISCARDABLE > IDS_TRASHFOLDER_TEXT "Czy jesteњ pewien, їe chcesz umieњciж folder '%1' i caі№ jego zawartoњж w koszu" > IDS_TRASHMULTIPLE_TEXT "Elementуw: %1 - czy na pewno chcesz je umieњciж w Koszu?" > IDS_CANTTRASH_TEXT "Nie mogк przenieњж elementu '%1' do Kosza. Czy chcesz go zamiast tego usun№ж?" > - IDS_OVERWRITEFILE_TEXT "Zast№piж plik %1?" > + IDS_OVERWRITEFILE_TEXT "This folder already contains a file called '%1'.\n\nDo you want to replace it?" > IDS_OVERWRITEFILE_CAPTION "Potwierdџ zast№pienie pliku" > + 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 "Uruchom ponownie" > diff --git a/dlls/shell32/shell32_Pt.rc b/dlls/shell32/shell32_Pt.rc > index 1826162..0a6a274 100644 > --- a/dlls/shell32/shell32_Pt.rc > +++ b/dlls/shell32/shell32_Pt.rc > @@ -256,8 +256,12 @@ STRINGTABLE DISCARDABLE > IDS_DELETEFOLDER_CAPTION "Confirmar exclusгo de pasta" > IDS_DELETEITEM_TEXT "Vocк tem certeza que deseja excluir '%1'?" > IDS_DELETEMULTIPLE_TEXT "Vocк tem certeza que deseja excluir estes %1 itens?" > - IDS_OVERWRITEFILE_TEXT "Sobreescrever arquivo %1?" > + IDS_OVERWRITEFILE_TEXT "This folder already contains a file called '%1'.\n\nDo you want to replace it?" > IDS_OVERWRITEFILE_CAPTION "Confirmar sobreescrever arquivo" > + 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 "Reiniciar" > diff --git a/dlls/shell32/shell32_Ru.rc b/dlls/shell32/shell32_Ru.rc > index a3c5da8..65fa824 100644 > --- a/dlls/shell32/shell32_Ru.rc > +++ b/dlls/shell32/shell32_Ru.rc > @@ -165,8 +165,12 @@ STRINGTABLE DISCARDABLE > IDS_DELETEFOLDER_CAPTION "Подтверждение удаления папки" > IDS_DELETEITEM_TEXT "Удалить '%1'?" > IDS_DELETEMULTIPLE_TEXT "Удалить эти обьекты (%1?" > - 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_Tr.rc b/dlls/shell32/shell32_Tr.rc > index b41be53..197562c 100644 > --- a/dlls/shell32/shell32_Tr.rc > +++ b/dlls/shell32/shell32_Tr.rc > @@ -172,8 +172,12 @@ STRINGTABLE DISCARDABLE > IDS_TRASHFOLDER_TEXT "'%1' adlэ црeyi ve tьm iзeriрini зцpe gцndermek istediрinizden emin misiniz?" > IDS_TRASHMULTIPLE_TEXT "Bu %1 црeyi зцpe gцndermek istediрinizden emin misiniz?" > IDS_CANTTRASH_TEXT "'%1' adlэ црe зцpe gцnderilemiyor. Tamamen silmek ister misiniz?" > - IDS_OVERWRITEFILE_TEXT "%1 dosyasэnэn ьzerine yazmak istiyor musunuz?" > + IDS_OVERWRITEFILE_TEXT "This folder already contains a file called '%1'.\n\nDo you want to replace it?" > IDS_OVERWRITEFILE_CAPTION "Dosya Ьzerine Yazmayэ Onayla" > + 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 "Yeniden Baюlat" > diff --git a/dlls/shell32/shell32_Uk.rc b/dlls/shell32/shell32_Uk.rc > index c535ba9..a4cf564 100644 > --- a/dlls/shell32/shell32_Uk.rc > +++ b/dlls/shell32/shell32_Uk.rc > @@ -161,8 +161,12 @@ STRINGTABLE DISCARDABLE > IDS_DELETEFOLDER_CAPTION "Підтвердження вилучення теки" > IDS_DELETEITEM_TEXT "Ви впевнені, що хочете вилучити '%1'?" > IDS_DELETEMULTIPLE_TEXT "Ви впевнені, що хочете вилучити ці %1 елементи(ів)?" > - 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?" > } > > /* columns in the shellview */ > diff --git a/dlls/shell32/shell32_main.h b/dlls/shell32/shell32_main.h > index a17eec4..2937065 100644 > --- a/dlls/shell32/shell32_main.h > +++ b/dlls/shell32/shell32_main.h > @@ -153,9 +153,10 @@ void FreeChangeNotifications(void); > #define ASK_TRASH_FOLDER 8 > #define ASK_TRASH_MULTIPLE_ITEM 9 > #define ASK_CANT_TRASH_ITEM 10 > +#define ASK_OVERWRITE_FOLDER 11 > > BOOL SHELL_DeleteDirectoryW(HWND hwnd, LPCWSTR pwszDir, BOOL bShowUI); > -BOOL SHELL_ConfirmDialogW(HWND hWnd, int nKindOfDialog, LPCWSTR szDir); > +BOOL SHELL_ConfirmYesNoW(HWND hWnd, int nKindOfDialog, LPCWSTR szDir); > > /* 16-bit functions */ > void WINAPI DragAcceptFiles16(HWND16 hWnd, BOOL16 b); > diff --git a/dlls/shell32/shfldr_unixfs.c b/dlls/shell32/shfldr_unixfs.c > index 4668afe..a4f4ade 100644 > --- a/dlls/shell32/shfldr_unixfs.c > +++ b/dlls/shell32/shfldr_unixfs.c > @@ -1829,7 +1829,7 @@ static HRESULT UNIXFS_delete_with_syscalls(UnixFolder *This, UINT cidl, LPCITEMI > static const WCHAR empty[] = {0}; > int i; > > - if (!SHELL_ConfirmDialogW(GetActiveWindow(), ASK_DELETE_SELECTED, empty)) > + if (!SHELL_ConfirmYesNoW(GetActiveWindow(), ASK_DELETE_SELECTED, empty)) > return S_OK; > > lstrcpyA(szAbsolute, This->m_pszPath); > diff --git a/dlls/shell32/shlfileop.c b/dlls/shell32/shlfileop.c > index d1ea475..b245e00 100644 > --- a/dlls/shell32/shlfileop.c > +++ b/dlls/shell32/shlfileop.c > @@ -27,6 +27,7 @@ > #include <stdarg.h> > #include <string.h> > #include <ctype.h> > +#include <assert.h> > > #include "windef.h" > #include "winbase.h" > @@ -65,6 +66,14 @@ static DWORD SHNotifyMoveFileW(LPCWSTR src, LPCWSTR dest); > static DWORD SHNotifyCopyFileW(LPCWSTR src, LPCWSTR dest, BOOL bFailIfExists); > static DWORD SHFindAttrW(LPCWSTR pName, BOOL fileOnly); > > +typedef struct > +{ > + SHFILEOPSTRUCTW *req; > + DWORD dwYesToAllMask; > + BOOL bManyItems; > + BOOL bCancelled; > +} FILE_OPERATION; > + > /* Confirm dialogs with an optional "Yes To All" as used in file operations confirmations > */ > static const WCHAR CONFIRM_MSG_PROP[] = {'W','I','N','E','_','C','O','N','F','I','R','M','E',0}; > @@ -250,22 +259,32 @@ static BOOL SHELL_ConfirmIDs(int nKindOfDialog, SHELL_ConfirmIDstruc *ids) > ids->icon_resource_id = IDI_WARNING; > ids->caption_resource_id = IDS_OVERWRITEFILE_CAPTION; > ids->text_resource_id = IDS_OVERWRITEFILE_TEXT; > - return TRUE; > + return TRUE; > + case ASK_OVERWRITE_FOLDER: > + ids->hIconInstance = NULL; > + ids->icon_resource_id = IDI_WARNING; > + ids->caption_resource_id = IDS_OVERWRITEFILE_CAPTION; > + ids->text_resource_id = IDS_OVERWRITEFOLDER_TEXT; > + return TRUE; > default: > FIXME(" Unhandled nKindOfDialog %d stub\n", nKindOfDialog); > } > return FALSE; > } > > -BOOL SHELL_ConfirmDialogW(HWND hWnd, int nKindOfDialog, LPCWSTR szDir) > +static BOOL SHELL_ConfirmDialogW(HWND hWnd, int nKindOfDialog, LPCWSTR szDir, FILE_OPERATION *op) > { > WCHAR szCaption[255], szText[255], szBuffer[MAX_PATH + 256]; > SHELL_ConfirmIDstruc ids; > DWORD_PTR args[1]; > HICON hIcon; > + int ret; > > - if (!SHELL_ConfirmIDs(nKindOfDialog, &ids)) > - return FALSE; > + assert(nKindOfDialog >= 0 && nKindOfDialog < 32); > + if (op && (op->dwYesToAllMask & (1 << nKindOfDialog))) > + return IDYES; > + > + assert(SHELL_ConfirmIDs(nKindOfDialog, &ids)); > > LoadStringW(shell32_hInstance, ids.caption_resource_id, szCaption, sizeof(szCaption)/sizeof(WCHAR)); > LoadStringW(shell32_hInstance, ids.text_resource_id, szText, sizeof(szText)/sizeof(WCHAR)); > @@ -275,7 +294,23 @@ BOOL SHELL_ConfirmDialogW(HWND hWnd, int nKindOfDialog, LPCWSTR szDir) > szText, 0, 0, szBuffer, sizeof(szBuffer), (va_list*)args); > hIcon = LoadIconW(ids.hIconInstance, (LPWSTR)MAKEINTRESOURCE(ids.icon_resource_id)); > > - return (IDYES == SHELL_ConfirmMsgBox(hWnd, szBuffer, szCaption, hIcon, FALSE)); > + ret = SHELL_ConfirmMsgBox(hWnd, szBuffer, szCaption, hIcon, op && op->bManyItems); > + if (op) { > + if (ret == IDD_YESTOALL) { > + op->dwYesToAllMask |= (1 << nKindOfDialog); > + ret = IDYES; > + } > + if (ret == IDCANCEL) > + op->bCancelled = TRUE; > + if (ret != IDYES) > + op->req->fAnyOperationsAborted = TRUE; > + } > + return ret == IDYES; > +} > You need to conform to the style of the rest of the file, e.g., if (IsAttribDir(entryToCopy->attributes) && bCancelIfAnyDirectories) return ERROR_CANCELLED; create_dest_dirs(fileDest->szDirectory); if (!lstrcmpiW(entryToCopy->szFullPath, fileDest->szFullPath)) { if (IsAttribFile(entryToCopy->attributes)) return ERROR_NO_MORE_SEARCH_HANDLES; else return ERROR_SUCCESS; } 4 space indentation, empty lines between logical pieces of code, brackets underneath. -- James Hawkins

Feb. 9, 2007

Re: Bugzilla: Adding a 'patch' keyword

by Nick Law

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 ?

Feb. 9, 2007

Wine beta ASIO-driver.

by Tor Einar Tønnessen

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

Feb. 9, 2007

Re: comctl32: rebar: rewrite the layouting code

by Paul Vriens

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.

Feb. 9, 2007

Re: shell32[2/3]: add a confirmation dialog with a "Yes to All" option

by Mikołaj Zalewski

> 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

Feb. 9, 2007

Re: shell32[2/3]: add a confirmation dialog with a "Yes to All" option

by Robert Shearman

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

Feb. 9, 2007

Re: comctl32: rebar: rewrite the layouting code

by Mikołaj Zalewski

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

Feb. 9, 2007

Re: RasError.h? Where is this or does it not exist?

by John Smith

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 <fgouget(a)free.fr> 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 <fgouget(a)free.fr> http://fgouget.free.fr/ > The last time religion ruled, it was called the dark ages. >

Feb. 9, 2007

Re: Some thoughts about the ominous DIB Engine

by Detlef Riekenberg

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

Feb. 9, 2007

re: comctl32: rebar: rewrite the layouting code

by Dan Kegel

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

Feb. 9, 2007

Re: comctl32: rebar: rewrite the layouting code

by Mikołaj Zalewski

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

Feb. 9, 2007

Re: Bugzilla: Adding a 'patch' keyword

by Tony Lambregts

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

Feb. 9, 2007

Re: shell32: make sure BrowseForFolder doesn't return NULL for the Desktop folder as this means a cancel (should fix bug #5533)

by Mikołaj Zalewski

> This function is a bit ugly. It seems this policy should be made in > the BrsFolder_OnCommand function, rather than in pidl.c as a file. Yes, after I've found _ILCreateDesktop there is no need for a helper funciton. I'll send a patch without it. Mikolaj Zalewski

Feb. 9, 2007

Re: RasError.h? Where is this or does it not exist?

by Francois Gouget

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 <fgouget(a)free.fr> http://fgouget.free.fr/ The last time religion ruled, it was called the dark ages.

Feb. 9, 2007

Re: comctl32: rebar: rewrite the layouting code

by Robert Shearman

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! -- Rob Shearman

Feb. 9, 2007

Re: shell32: make sure BrowseForFolder doesn't return NULL for the Desktop folder as this means a cancel (should fix bug #5533)

by Robert Shearman

Mikołaj Zalewski wrote: > +/************************************************************************* > + * _ILMakePidlNotNull > + * > + * A null pidl is a valid pidl that represents the Desktop. However if we don't > + * want a NULL pidl (e.g. because NULL indicates an error) this function will > + * make an explicit empty pidl if the parameter is NULL. > + */ > +HRESULT _ILMakePidlNotNull(LPITEMIDLIST *pidl) > +{ > + if (*pidl == NULL) > + *pidl = _ILCreateDesktop(); > + if (*pidl == NULL) > + return E_OUTOFMEMORY; > + return S_OK; > +} > This function is a bit ugly. It seems this policy should be made in the BrsFolder_OnCommand function, rather than in pidl.c as a file. -- Rob Shearman

Feb. 9, 2007

Re: ntdll: Add prototypes to winnt.h for the SList functions.

by Alexandre Julliard

Francois Gouget <fgouget(a)free.fr> 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 julliard(a)winehq.org

Feb. 9, 2007

Re: Some thoughts about the ominous DIB Engine

by Damjan Jovanovic

On 2/9/07, Rolf Kalbermatter <r.kalbermatter(a)hccnet.nl> 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

Feb. 9, 2007

Re: Some thoughts about the ominous DIB Engine

by Felix Nawothnig

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.

Feb. 9, 2007

Questions about gdi32:WidenPath patch sent on jan. 27

by Laurent Vromman

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

Feb. 9, 2007

Re: Some thoughts about the ominous DIB Engine

by Felix Nawothnig

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

Feb. 9, 2007

Re: Bugzilla: Adding a 'patch' keyword

by Francois Gouget

On Thu, 8 Feb 2007, Jeremy Newman wrote: > Since nobody else jumped on this, I went ahead and added a "patch" > keyword. Argh! So now I finally discover that after all it is possible to use the query system to get a list of the bugs that have patches. So we don't need the 'patch' keyword :-/ Sorry for all the noise. The trick is to use the 'Advanced Querying Using Boolean Charts' at the bottom, select 'Attachment is patch', 'is equal to' and '1'. Or as a neat URL: http://bugs.winehq.org/buglist.cgi?bug_status=UNCONFIRMED&bug_status=NEW&bu… So this shows that there are 128 open bugs with patches. So that's 128 bugs to check: * either the patch has been applied to WineHQ and then the bug should be closed (unless there are other issues, but then maybe these should go in a separate bug). * or the patch is just waiting for someone to review it, polish it up and send it to wine-patches (ok it might need a bit more than just polishing, but still, it's a start). -- Francois Gouget <fgouget(a)free.fr> http://fgouget.free.fr/ Linux, WinNT, MS-DOS - also known as the Good, the Bad and the Ugly.

Feb. 9, 2007

Re: Some thoughts about the ominous DIB Engine

by Ken Thomases

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

Feb. 9, 2007

Re: Some thoughts about the ominous DIB Engine

by Michael Stefaniuc

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 Engineer Fax.: +49-711-96437-111 Red Hat GmbH Email: mstefani(a)redhat.com Hauptstaetterstr. 58 http://www.redhat.de/ D-70178 Stuttgart

Feb. 9, 2007

Re: [1/9] WineD3D: BeginScene and EndScene tests and fixes

by Alexandre Julliard

Stefan Dösinger <stefan(a)codeweavers.com> writes: > From 4dc1b3cd7faf9c61bc6f862f416b6af07e1e85e8 Mon Sep 17 00:00:00 2001 > From: Stefan Doesinger <stefan(a)codeweavers.com> > 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 julliard(a)winehq.org

Feb. 9, 2007

Some thoughts about the ominous DIB Engine

by Rolf Kalbermatter

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

Feb. 9, 2007

Re: winegcc: sign-compare fixes

by richardvoigt＠gmail.com

> > > memmove(&arr->base[i], &arr->base[i + 1], > > (arr->size - i - 1) * > > > sizeof(arr->base[0])); > > > arr->size--; > > > } > > > > If the element size could be greater than one byte, > > the multiplication > > here should be checked for overflow (actually, this > > is more necessary > > when the array is created or expanded). > > > > > > > > > Well, the base field in the structure is defined as > "const char** base" so sizeof(base[0]) == sizeof(const > char *), should be 4 or so. > How do you mean overflow in this case? sorry for > asking dumb questions... > One desires that the argument is the size of memory which holds numelems = (arr->size - i - 1) elements of each = sizeof (arr->base[0]) bytes each. As you say each = 4 bytes on 32-bit systems. Then the value is numelems * each = numelems * 4 = numelems << 2. Thus if either of the two most significant bits in numelems are set, they will be lost as a result of the shift (multiplication). In this case the correct value is larger than addressable virtual memory, which should be illegal. Actually though, the limit should be placed on arr->size in the allocation function. The essential problem here is that this can be used to remove sanity checking in the case where the inputs are supplied by a client with lesser permissions. Imagine, for example, a kernel function being invoked via an ioctl... though the problem is equally valid for any network-facing service. Say a client is allowed to create and access buffer for exchange with a device (USB printer or the like), and that the client can allocate the buffer by providing the number of buffer elements, and the element size is fixed and non-unity, we'll use 4 in this example. If the privileged service does something like the following: handle createbuffer(int buflen) { if (buflen <= 0) return NULL int bytecount = 4 * buflen; if (bytecount > quota) return NULL; int* p = malloc(bytecount); if (!p) return NULL; return createbufferhandle(buflen, p); } and lets the client read from the buffer: int readbufferatindex(handle buffer, int index) { int size = buffersizefromhandle(buffer); if (index < 0 || index >= size) return 0; return bufferptrfromhandle(buffer)[index]; } Seems safe enough, right? Each client is allowed only a limited buffer, maybe elsewhere the number of buffers is limited, so the client can't execute a DOS attack. malloc guarantees that the buffer doesn't overlap any other buffer, and the bounds checking in readbufferatindex prevents clients from reading outside their buffer. Until I do this: buffer = createbuffer(0x40000010); Uh-oh. I passed the quota check, because bytecount was calculated at 64 bytes. malloc easily allocated 64 bytes not overlapping with any other user. But the stored buffersize is set so large that the bounds check is worthless; I can read any memory I want.

Feb. 9, 2007

Re: comctl32: datetime: initial tests for date and time picker

by Mike McCormack

Kanit Therdsteerasukdi wrote: > I'm a student at UCLA taking CS130: Software Engineering. For CS130, we > are writing conformance tests for Common Controls (comctl32). I will be > working on the Date and Time Picker. Attached is an initial test, > testing the getters and setters. Looks like good work. > +#include <stdio.h> This is possibly not needed. > +static HINSTANCE g_hinst; You should be able to use NULL instead of the hinst when creating the window, which would eliminate the need for g_hinst. > + assert(hWndDateTime!=NULL); > + return hWndDateTime; Maybe it would be nicer to check hWndDateTime with an ok() macro in test_datetime_control() then use skip() if it's NULL. This way the test will fail without crashing in the case that Window creation fails, for example, when there's no X display available. When tests crash, make doesn't detect that they failed. > + return; > +} The return is redundant, and probably better off removed. > + r = SendMessage(hWndDateTime, DTM_SETRANGE, GDTR_MIN | GDTR_MAX, (LPARAM)st); > + ok(r != 0, "Expected nonzero, got %ld\n", r); MSDN does say "returns nonzero if successful", but it's probably better to check the exact value that it does return, in case there's a program out there that does the same. ie. ok(r == 1, "Expected nonzero, got %ld\n", r); Mike

Feb. 9, 2007

Re: DirectDrawRenderer=opengl - screen size changeable for final rendering?

by Stefan Dösinger

> thats the point. i dont know how wine handles the ddraw-over-opengl > scenario. i just had very blury graphics in JA2. nothing to wonder > about as i assume at least one quad is drawn with the image as texture. > so the filtering kicks in and voila we have bad image quality. No, I think opengl ddraw rendering is still pretty buggy. I wrote the code to do it mainly for Direct3D7 games which blit their HUD onto the screen using DirectDraw blitting calls. I tested it with Prince of Persia 3D, Swat 3 and Battlezone 2. I have some fixes in my patch list I'm going to send in the next days to fix some readback bugs. (Half-Life 2 uses the blitting code to make screenshots and savegame images). Furthermore partial render target locking is completely broken in git, I have fixes for that too. > assuming that my "render a quad" theory is right it would work to place > a key in the registry, where i would tell the ogl-ddraw-renderer to use > my res instead of the one the apps wants. OpenGL DirectDraw rendering renders by setting up the projection matrix to have 0/0 at the top left of the screen and with/height at the bottom right. Then it calculates the source coordinates with Xsrc / Source->pow2Width and Ysrc / Source->pow2Height and draws a quad. So yes, in theory we could scale things up by just setting a higher resolution. One could get nicer graphics with linear / bilinear / anisotropic texture filtering, but there are some issues: * Color keying: Filtering will change the color values slightly, so mess up color keying * Mouse input: We'd have to do the same for received mouse events * readback: If the application locks the render target or reads it back into an offscreen texture, you have to undo filtering and scaling It will be easier to just use multisampling on the final rendering. The nvidia driver has such an option to force multisampling. But that is I think simmilar to what your tft does. Of course for properly changed resolutions you have to run in fullscreen, not virtual desktop. It would be a pretty messy thing to force a foreign resolution onto a game. You can try to do that of course, but I don't think such a patch would be accepted into wine.

Feb. 8, 2007

Re: [2] wineshelllink: Keep using the slash as path separator.

by Vitaliy Margolen

Hans Leidekker wrote: > On Thursday 08 February 2007 16:38:07 Vitaliy Margolen wrote: > >> And creates invalid menu entries. Did you test this patch with >> multi-level menu structure? When I tried your patch it created all menu >> entries in the top level menu, with the name like: > > Strange, I tested the patch extensively before sending it including > multilevel menu structures. It showed no differences for paths without > dashes and fixed paths with dashes for me. I just tested it again and > still produces the correct results here. I even tried /bin/bash instead > of /bin/sh but I can't reproduce what you're seeing. > > Could you send me a good and a bad tarball created like this? > > tar zcvf good.tar.gz \ > $HOME/.local/share/applications \ > $HOME/.local/share/desktop-directories \ > $HOME/.config/menus/applications-merged > > -Hans Ok I figured it out I think. It's the older stuff that I had in there that was messing things up. After cleaning it up and using your patch, everything worked like a charm. So nvm - false alarm. Thanks for a good job! Vitaliy.

Feb. 8, 2007

Re: [2] wineshelllink: Keep using the slash as path separator.

by Hans Leidekker

On Thursday 08 February 2007 16:38:07 Vitaliy Margolen wrote: > And creates invalid menu entries. Did you test this patch with > multi-level menu structure? When I tried your patch it created all menu > entries in the top level menu, with the name like: Strange, I tested the patch extensively before sending it including multilevel menu structures. It showed no differences for paths without dashes and fixed paths with dashes for me. I just tested it again and still produces the correct results here. I even tried /bin/bash instead of /bin/sh but I can't reproduce what you're seeing. Could you send me a good and a bad tarball created like this? tar zcvf good.tar.gz \ $HOME/.local/share/applications \ $HOME/.local/share/desktop-directories \ $HOME/.config/menus/applications-merged -Hans

Feb. 8, 2007

RE: Helping a user migrate an odbc app to Wine

by Rolf Kalbermatter

Boaz Harrosh [mailto:boazharrosh(a)gmail.com] wrote: >This is totally not true and it is right there in documentation. (User guide) Ok! I stand corrected. Sorry. >All you do is install mdac downloadable from Microsoft.com, or any MS product >like Office. Than run odbcad32.exe to set your DSNs. I had expected some of these drivers to make use of private APIs that might not be available under Wine. >That's it, works like a charm and is the only known way to man to connect to >an MSSQL server from Unix. Well there is at least FreeTDS unless you need to communicate with the server through other means than TCP/IP. Rolf Kalbermatter

Feb. 8, 2007

Re: Bugzilla: Adding a 'patch' keyword

by Jeremy Newman

Since nobody else jumped on this, I went ahead and added a "patch" keyword. On Mon, 2007-02-05 at 19:48 +0100, 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? >

Feb. 8, 2007

winealsa commit d2f29311caa8041bd992a3867d71d6311c7ff8fa

by Marcus Meissner

Hi Marten, Your commit: http://source.winehq.org/git/wine.git/?a=commit;h=d2f29311caa8041bd992a3867… Has some regressions on Coverity. Namely Coverity complains that "areas" is used uninitializied. And yes it is: static DWORD CALLBACK DBSB_MMAPLoop(LPVOID data) { IDsDriverBufferImpl* pdbi = (IDsDriverBufferImpl*)data; WINE_WAVEDEV *wwo = &(WOutDev[pdbi->drv->wDevID]); snd_pcm_uframes_t frames, wanted, ofs; const snd_pcm_channel_area_t *areas; int state = WINE_WS_STOPPED; snd_pcm_state_t alsastate; TRACE_(waveloop)("0x%8p\n", data); TRACE("0x%8p, framelength: %lu, area: %8p\n", data, pdbi->mmap_buflen_frames, pdbi->mmap_areas); if (areas != pdbi->mmap_areas || areas->addr != pdbi->mmap_areas->addr) FIXME("Can't access sound driver's buffer directly.\n"); Please fix :) Ciao, Marcus

Feb. 8, 2007

Re: DirectDrawRenderer=opengl - screen size changeable for final rendering?

by Christoph Frick

On Thu, Feb 08, 2007 at 07:01:04PM +0100, Stefan Dösinger wrote: > DirectDraw games access the screen directly by using coordinates from > 0, 0 to with, height. If wine makes the surface bigger the rendering > will just end up in a corner. The best thing we can do is to scale it, > but that is what your monitor does if you set a lower resoltution. thats the point. i dont know how wine handles the ddraw-over-opengl scenario. i just had very blury graphics in JA2. nothing to wonder about as i assume at least one quad is drawn with the image as texture. so the filtering kicks in and voila we have bad image quality. so i wondered if i could configre somewhere to render this quad instead of 800x600 like the app wants it but with 1600x1200 i would get quite some good antialiasing for this old game. this would of course assume, that wine "fakes" the screen until a redraw, where the polygon is drawn again. if i would just change the res of the monitor there i get also some fsaa for free because the tft would scale it for me - changing the res each time is a cumbersome task for one how does not like to change res at all ;) > So you *may* be able to trick the game into using a different > resolution, but this will have to be a per-game hack and can't be done > in general. assuming that my "render a quad" theory is right it would work to place a key in the registry, where i would tell the ogl-ddraw-renderer to use my res instead of the one the apps wants. -- cu

Feb. 8, 2007

Re: How to find rendering code

by Stefan Dösinger

Am Mittwoch 07 Februar 2007 00:14 schrieb Markus: > Hi, > > I am new to Wine development and wanted to ask on the list, whether someone > could point me to the correct place where the code for issues 3 and 4 in > http://bugs.winehq.org/show_bug.cgi?id=7273 might be located. It looks like > the solution could be rather straightforward to implement but I have no > idea how to find the respective rendering method. The first step is usually to find out which library the game uses for rendering: Try some debug channels: d3d7, d3d8, d3d9, opengl . Whatever channel spits out most lines during rendering is the most likely rendering method used. I suspect d3d9 for this game. For d3d games the code you will find most interesting is in dlls/wined3d. Opengl is located in dlls/opengl32 and dlls/winex11.drv. d3d7 has some parts in dlls/ddraw, d3d8 in dlls/d3d8 and d3d9 in dlls/d3d9. But those libraries are usually not the cause for bugs like the ones you see.

Feb. 8, 2007

Re: RedHat rpms

by Lei Zhang

I build RPMs for RHEL 3, give them a try: http://linux.ucla.edu/~leiz/software/wine/rpms.php On 2/8/07, Bill Medland <billmedland(a)shaw.ca> wrote: > Just checking > > I'm looking to see if there are rpms being built for Red Hate Enterprise > Linux 3 these days. > I see that the Red Hat rpms nowadays are for fc. but they aren't > suitable for RHEL3 > The download page says that the RedHat/Fedora area is for RedAht 8,9 and > fedora, but I don't see any RedHat 8 or 9 there. Are they not there or > am I looking in the wrong place? > -- > Bill Medland > > > >

Feb. 8, 2007

Re: DirectDrawRenderer=opengl - screen size changeable for final rendering?

by Stefan Dösinger

Am Dienstag 06 Februar 2007 14:13 schrieb Christoph Frick: > hiho > > what i ever wondered but never dared to ask: > > i tried recently the said key with jagged alliance 2. as the game has > quite a low resolution 640 or 800 it would be nice to allow higher > resolutions when rendering ddraw with opengl (e.g. game wants 800 but > for the final rendering use 1600). is this doable via registry or > somewhere else? for the files: i run the apps in desktop-mode. Do you mean if if you can use a higher resolution than the game sets? For Direct3D games this can work, but for DirectDraw it is going to fail. Direct3D games which draw only untransformed vertices pass coordinates in the range of [-1.0 ; +1.0], which later get scaled to viewport coordinates. With a different viewport we can trick the game into doing that. It will get tricky when the app draws transformed vertices(which have screen coordinates). DirectDraw games access the screen directly by using coordinates from 0, 0 to with, height. If wine makes the surface bigger the rendering will just end up in a corner. The best thing we can do is to scale it, but that is what your monitor does if you set a lower resoltution. So you *may* be able to trick the game into using a different resolution, but this will have to be a per-game hack and can't be done in general.

Feb. 8, 2007

Re: Helping a user migrate an odbc app to Wine

by Boaz Harrosh

On 2/8/07, Rolf Kalbermatter <r.kalbermatter(a)hccnet.nl> wrote: > Ouch, I wouldn't see how this could work. Running the Microsoft > drivers together with the whole Microsoft ODBC manager under Wine > too would probably be the only way to get that working. But I think > it is safe to assume that that would require quite some work in Wine > before this could possibly work, not to talk about license issues. > > Rolf Kalbermatter > > This is totally not true and it is right there in documentation. (User guide) All you do is install mdac downloadable from Microsoft.com, or any MS product like Office. Than run odbcad32.exe to set your DSNs. that's it, works like a charm and is the only known way to man to connect to an MSSQL server from Unix. After you install MDAC, you can also install Oracle's drivers for windows but that is a bit more tricky, just like on windows. Also search archives it was there before. Free Life Boaz

Feb. 8, 2007

Re: Getting Fallout 2 to work well

by Stefan Dösinger

Am Montag 05 Februar 2007 17:19 schrieb Mitchell Mebane: > How much work would this be? I know nothing about Windows or X11 > programming, but is it something that I might be able to study up on and > propose for a Summer of Code project? It was suggested as a SOC project last year, but nobody showed interest in it. So I guess yes. Search a bit in the forums, there is a lot of information about this topic, and transgaming offered us their GDI engine some time ago, but it never made it into the wine tree(don't ask me for the details, but I think Alexandre didn't like it). So you have some code to illustrate what needs to be done.

Feb. 8, 2007

RedHat rpms

by Bill Medland

Just checking I'm looking to see if there are rpms being built for Red Hate Enterprise Linux 3 these days. I see that the Red Hat rpms nowadays are for fc. but they aren't suitable for RHEL3 The download page says that the RedHat/Fedora area is for RedAht 8,9 and fedora, but I don't see any RedHat 8 or 9 there. Are they not there or am I looking in the wrong place? -- Bill Medland

Feb. 8, 2007

Re: winegcc: sign-compare fixes

by Joris Huizer

--- "richardvoigt(a)gmail.com" <richardvoigt(a)gmail.com> wrote: > On 2/7/07, Joris Huizer <joris_huizer(a)yahoo.com> > wrote: > > I believe this one causes problems -- please do > not commit yet > > > > Joris Huizer <joris_huizer(a)yahoo.com> wrote: > > > > ________________________________ > > Need Mail bonding? > > Go to the Yahoo! Mail Q&A for great tips from > Yahoo! Answers users.>From > > 8686a200bd1f1cbd934d761013c487a9ddc195c9 Mon Sep > 17 > > 00:00:00 2001 > > From: Joris Huizer > > Date: Wed, 7 Feb 2007 15:19:25 +0100 > > Subject: [PATCH] winegcc sign-compare fixes > > To: wine-patches > > > > --- > > tools/winegcc/utils.c | 13 +++++++------ > > tools/winegcc/winegcc.c | 11 ++++++----- > > 2 files changed, 13 insertions(+), 11 > deletions(-) > > > > diff --git a/tools/winegcc/utils.c > b/tools/winegcc/utils.c > > index 1af91e9..c144077 100644 > > --- a/tools/winegcc/utils.c > > +++ b/tools/winegcc/utils.c > > @@ -120,14 +120,14 @@ void strarray_add(strarray* > arr, const c > > > > void strarray_del(strarray* arr, int i) > > { > > - if (i < 0 || i >= arr->size) error("Invalid > index i=%d", i); > > + if (i < 0 || (unsigned int)i >= arr->size) > error("Invalid index i=%d", i); > > The unsigned int comparison here makes the negative > check superfluous. > Perhaps the argument should even be changed to > unsigned as well, to > match the range of arr->size (if the element is one > byte). Alright, that makes sence, will do > > > memmove(&arr->base[i], &arr->base[i + 1], > (arr->size - i - 1) * > > sizeof(arr->base[0])); > > arr->size--; > > } > > If the element size could be greater than one byte, > the multiplication > here should be checked for overflow (actually, this > is more necessary > when the array is created or expanded). > > > > Well, the base field in the structure is defined as "const char** base" so sizeof(base[0]) == sizeof(const char *), should be 4 or so. How do you mean overflow in this case? sorry for asking dumb questions... ____________________________________________________________________________________ Finding fabulous fares is fun. Let Yahoo! FareChase search your favorite travel sites to find flight and hotel bargains. http://farechase.yahoo.com/promo-generic-14795097

Feb. 8, 2007

Re: [2] wineshelllink: Keep using the slash as path separator.

by Vitaliy Margolen

Hans Leidekker wrote: > Fixes incorrect handling of paths with dashes. > And creates invalid menu entries. Did you test this patch with multi-level menu structure? When I tried your patch it created all menu entries in the top level menu, with the name like: wine-Programs-Ubi Soft-IL-2 Sturmovik Demo Instead of being a menu: wine Programs Ubi Soft IL-2 Sturmovik Demo Last one is the way it should be but now it's 2 menus: IL 2 Sturmovik Demo Vitaliy.

Feb. 8, 2007

Re: [GDI32] Fix for GetTextExtentExPointW() and ExtTextOutW() - Fixes Bug 50

by John Smith

Hey Pedro, Was there supposed to be an attachment on your last message? I didn't see one. Regards, John Klehm On 2/8/07, Pedro Araujo Chaves Jr. <inckie(a)gmail.com> wrote: > > Attached is my proposed patch for Bug #50; the test case was attached > in my previous message. > -- > Patch description: > > This patch fixes Wine's Bug #50: "PrgWin95: Text justification needs > beefing up". > > What it does: first, it takes in consideration that not always the > number of extra pixels will be a multiple of the number of break > characters in a given extent of a given string that should be > justified, and so the integer division of extra by breaks in > SetTextJustification() is likely to leave a remainder (which the > latter function addresses, of course, but ExtTextOutW() seems to > overlook — that's the reason for the changes at lines 1788 (breakRem), > and 1901 and 1922 (dc->breakExtra || breakRem), which prevent some > lines from being ignored in the justification). > > That fixed, if there remained any pixels indeed, their number > shouldn't be greater than dc->breakCount; then the first breakRem > break characters in that given extent are widened by one pixel (lines > 1925-1929 added). > > GetTextExtentExPointW() is also fixed so that it now returns the > expected width of the text when it is to be justified. This has the > good side effect that TabbedTextOut() now also returns the proper > width when called after SetTextJustification(). What the patch does > here is that GetTextExtentExPointW() now calculates the extra width > only when (breakExtra || breakRem) resolves TRUE , and corrects the > extra space additions by applying them only to break characters. What > was broken before is that it always added extra space, regardless of > whether it was measuring a single character or a full string, or > whether it was a break character or not. (Lines added: 1191, 1199, > 1227, 1229, 1236-1245, 1254-1268). > > This patch is copyrighted by Banco do Brasil under the LGPL. > > -- > Regards, > Pedro Araújo. > > >

Feb. 8, 2007

RasError.h? Where is this or does it not exist?

by John Smith

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 really want to think that the file isn't there but I can't rule out that I'm not somewhat stupid =P. So I appeal to you such wise guys as you are. Sorry for the dumb question, I just would hate to make the file if it already exists somewhere. Regards, John Klehm

Feb. 8, 2007

Re: advapi32: sign-compare fixes

by Francois Gouget

On Wed, 7 Feb 2007, Vitaliy Margolen wrote: [...] > This isn't correct either. lstrlenW() also returns INT and you > can't just cast it to (unsigned). Unsigned what? int/long/dword? In C, 'unsigned' is synonymous with 'unsigned int'. So it's unambiguous. -- Francois Gouget <fgouget(a)free.fr> http://fgouget.free.fr/ Dieu dit: "M-x Lumière". Et la lumière fut.

Feb. 8, 2007

Re: [PATCH] coverity: CID35: fixed wrong condition

by Marcus Meissner

On Tue, Feb 06, 2007 at 07:20:40PM +0100, Felix Nawothnig wrote: > Marcus Meissner wrote: > >>>- if(nRelPos>=0) { /* if this or preceding row */ > >>>+ if(nRelPos<=0) { /* if this or preceding row */ > >>> while(nRelPos<=0) { > >>Shouldn't that become a "do { ... } while()" then? > >No, since there is a return item; after the while () loop. > > I meant replacing just the while(), not the if() while(). > > It's mostly a matter of style though as gcc most likely will compile it > to a do {} while() anyway. I only wanted to do the minimalistic change to avoid errors creeping in ;) Ciao, Marcus

Feb. 8, 2007

IE Dev Toolbar now compatible!

by Darryl Dixon

Hi All, Just a brief to let you know that it looks like Microsoft is finally taking compatability seriously ;) - the new Beta 3 version of the IE Developers Toolbar (http://www.microsoft.com/downloads/details.aspx?FamilyID=e59c3964-672d-4511…) improves on the previous Beta release by installing and working correctly with wine 0.9.30 with an IE6 'ies4linux' install. In the previous Beta, the 'View DOM' button did not work in wine 0.9.30 - this new version fixes that and adds lots of enhancements. I don't know if this is useful to many here, but it sure is for me, so I thought I'd share. Nice to see Microsoft improving their software to work better with Wine for once (even though I'm sure it's unintentional ;). Keep up the good work, guys. regards, Darryl Dixon Winterhouse Consulting Ltd http://www.winterhouseconsulting.com

Feb. 8, 2007

RE: Helping a user migrate an odbc app to Wine

by Rolf Kalbermatter

Dan Kegel [mailto:dank(a)kegel.com] wrote: >Can somebody help this (german-speaking) fellow: >http://www.unixboard.de/vb3/showthread.php?t=26943 > >He says his company's internal application requires you to >input a DSN when installing it, and he doesn't know how to >come up with a DSN under Wine. Hmm, the DSN is just a name. You first would have to configure it and yes that means under Wine to deal with unixODBC. Alternatively you could change the connection string to pass all relevant information to the driver directly and have the configuration of those parameters in the application itself. >Presumably he doesn't want to mess with Unixodbc, he just wants >to keep using the Microsoft drivers...? Ouch, I wouldn't see how this could work. Running the Microsoft drivers together with the whole Microsoft ODBC manager under Wine too would probably be the only way to get that working. But I think it is safe to assume that that would require quite some work in Wine before this could possibly work, not to talk about license issues. Rolf Kalbermatter

Feb. 8, 2007

Re: ole32: Remove casts

by Mike McCormack

Robert Shearman wrote: >> Ref counts can be assumed to be between 0 and MAXLONG, so the fact >> that LONG is signed isn't important. > > NO. The DCOM spec says that STDOBJREF::cPublicRefs is unsigned, > therefore the ref counts can be assumed to be up to MAXULONG. Therefore, > this change is incorrect and it would lead to subtle signedness errors. Do you have a specific example of these errors? The only operations that are done (and should be done) on ref counts are initialization, InterlockedIncrement and InterlockedDecrement. asm generated will be exactly the same. In the highly unlikely case that the refcount passes MAXLONG, the behaviour will still be correct, but if refcounts are getting up that high, then you need to start worrying about them wrapping around to zero anyway. Casts are more problematic than the problems that you're imagining. Mike

Feb. 8, 2007

Re: ole32: Remove casts

by Robert Shearman

Mike McCormack wrote: > --- > This is the way ref counting is done everywhere else in Wine. > > Ref counts can be assumed to be between 0 and MAXLONG, so the fact > that LONG is signed isn't important. NO. The DCOM spec says that STDOBJREF::cPublicRefs is unsigned, therefore the ref counts can be assumed to be up to MAXULONG. Therefore, this change is incorrect and it would lead to subtle signedness errors. > > Casting ULONG* to LONG* to solve the above problem is unnecessary. > -- Rob Shearman

Feb. 8, 2007

Re: Helping a user migrate an odbc app to Wine

by Kai Blin

On Thursday 08 February 2007 01:42, Dan Kegel wrote: > Can somebody help this (german-speaking) fellow: > http://www.unixboard.de/vb3/showthread.php?t=26943 > > He says his company's internal application requires > you to input a DSN when installing it, and he doesn't > know how to come up with a DSN under Wine. The german speaking part is not a problem, I just don't know my way around that odbc stuff, not even on win32 native. > Presumably he doesn't want to mess with Unixodbc, > he just wants to keep using the Microsoft drivers...? I figure using the appropriate native dlls would work? I vaguely remember Windows had a tool to set up odbc drivers, what was the exe called? Cheers, Kai -- Kai Blin, <kai Dot blin At gmail Dot com> WorldForge developer http://www.worldforge.org/ Wine developer http://wiki.winehq.org/KaiBlin/ -- Will code for cotton.

Feb. 8, 2007

Re: msi: Make MsiInstallProduct conformance test depend on proper UI level processing.

by Misha Koshelev

On Wed, 2007-02-07 at 23:46 -0600, James Hawkins wrote: > On 2/7/07, Misha Koshelev <mk144210(a)bcm.tmc.edu> wrote: > > > > > Well, by definition, that's not really a conformance test because it > > > doesn't conform to windows. Did you make the property public and add > > > the property to the Property table? > > > > > > http://msdn2.microsoft.com/en-us/library/aa370912.aspx > > > > > > > Aha, google search figured it out: > > > > * Property name ALL CAPS - passed from UI to execute. > > * otherwise not. > > > > Too bad it's not documented on msdn (you think they would...) > > > > "Properties with names containing no lowercase letters are public properties..." > > http://msdn2.microsoft.com/en-us/library/aa370905.aspx > Too bad I don't read things carefully enough :) Anyway, I am sending the patch to wine-patches now. It is able to determine UI level properly (UI vs execute-only) on Win98, WinXP, and wine. Phew, time to go to bed. Misha

Feb. 8, 2007

Re: msi: Make MsiInstallProduct conformance test depend on proper UI level processing.

by James Hawkins

On 2/7/07, Misha Koshelev <mk144210(a)bcm.tmc.edu> wrote: > > > Well, by definition, that's not really a conformance test because it > > doesn't conform to windows. Did you make the property public and add > > the property to the Property table? > > > > http://msdn2.microsoft.com/en-us/library/aa370912.aspx > > > > Aha, google search figured it out: > > * Property name ALL CAPS - passed from UI to execute. > * otherwise not. > > Too bad it's not documented on msdn (you think they would...) > "Properties with names containing no lowercase letters are public properties..." http://msdn2.microsoft.com/en-us/library/aa370905.aspx -- James Hawkins

Feb. 8, 2007

Re: msi: Make MsiInstallProduct conformance test depend on proper UI level processing.

by Misha Koshelev

> Well, by definition, that's not really a conformance test because it > doesn't conform to windows. Did you make the property public and add > the property to the Property table? > > http://msdn2.microsoft.com/en-us/library/aa370912.aspx > Aha, google search figured it out: * Property name ALL CAPS - passed from UI to execute. * otherwise not. Too bad it's not documented on msdn (you think they would...) Misha

Feb. 8, 2007

Re: msi: Make MsiInstallProduct conformance test depend on proper UI level processing.

by Misha Koshelev

> Well, by definition, that's not really a conformance test because it > doesn't conform to windows. Did you make the property public and add > the property to the Property table? > > http://msdn2.microsoft.com/en-us/library/aa370912.aspx > First of all, I added the Property to the Property table, which is, what I understand from that link (paragraph three I think) all that it takes to make it public (in fact, what happens when you go from UI to Execute is that the value of the property seems to be reset back to the value from the Properties table). Two things: 1) I am testing the behavior in UI mode to make sure the test works, but the actual "test" is to test the mode NONE | otherflags, which, before the bug fix, would result in a UI install, whereas in Windows (all versions) it would result in an execute-only install. This test breaks on wine without the patch to fix it, whereas it would execute on all Windows version without error, thus in this sense it "conforms" to Windows. The question is whether we are able to detect a failure to conform. 2) I tried on Win98 and in Win98 it works the same way it does on Wine. I will play with it some more, but because of these points it seems to me that it is still a reasonable test (it will succeed on all version of Windows, on Wine that properly detects UI flags, but fail on wine that does not detect UI flags; however, in the future, if wine MSI is made more like Win XP MSI, it would be possible that we will not be able to detect failure anymore). Misha

Feb. 8, 2007

Re: msi: Make MsiInstallProduct conformance test depend on proper UI level processing.

by James Hawkins

On 2/7/07, Misha Koshelev <mk144210(a)bcm.tmc.edu> wrote: > On Wed, 2007-02-07 at 16:46 -0600, James Hawkins wrote: > > On 2/7/07, Misha Koshelev <mk144210(a)bcm.tmc.edu> wrote: > > > On Wed, 2007-02-07 at 13:23 -0600, James Hawkins wrote: > > > > On 2/7/07, Misha Koshelev <mk144210(a)bcm.tmc.edu> wrote: > > > > > On Wed, 2007-02-07 at 12:30 -0600, James Hawkins wrote: > > > > > > On 2/7/07, Misha Koshelev <mk144210(a)bcm.tmc.edu> wrote: > > > > > > > Hi, here is my proposed patch to the current msi MsiInstallProduct > > > > > > > consistency test that will make it's success depend on proper process of > > > > > > > UI flags (as well as everything else it depends on to make a successful > > > > > > > install). It seems to me like this is the simplest way to add this test > > > > > > > (it is only 5-6 lines added total), and it seems fair to me to add it to > > > > > > > this existing test for two reasons: > > > > > > > 1. The test is already testing a full product install (installs files, > > > > > > > services, registry values, etc) and my modification will simply result > > > > > > > in either no modification to these actions if UI level processing is > > > > > > > good or complete failure if it is bad, which will make the problem very > > > > > > > easy to diagnose. > > > > > > > 2. Looking through instructions on msdn it seems that there isn't a > > > > > > > kosher way to make a very simple MSI file that just, say, writes a > > > > > > > registry value (without doing costing, install validation, having a full > > > > > > > features table, installing some features, etc.) which would make a > > > > > > > separate function easy to implement and it does not really seem > > > > > > > necessary to copy and paste the whole test_MsiInstallProduct (or > > > > > > > similar) function just to check UI level processing. > > > > > > > > > > > > > > Changelog: > > > > > > > > > > > > > > * msi: Make MsiInstallProduct conformance test depend on proper UI > > > > > > > level processing. > > > > > > > > > > > > > > > > > > > You need to put whatever you're trying to test into a new test > > > > > > function. As-is, it's not clear what you're testing and we need to > > > > > > keep the tests logically separate. Test both a success and a failure > > > > > > case, plus all the in between cases. > > > > > > > > > > > > > If the full UI is started (incorrectly) > > > > > > > + * the InstallUISequence table will be used, and the install will fail. If the full UI is > > > > > > > + * not started (correctly) the InstallExecuteSequence table will be used. > > > > > > > > > > > > Why does the install fail if we run the InstallUISequence action?. > > > > > > Also, InstallExecuteSequence runs no matter what so this comment would > > > > > > need to be fixed. > > > > > > a fa > > > > > > > > > > Weird, because it does indeed fail when running in full UI mode. > > > > > > > > > > > > > It's failing because you don't have the InstallUISequence set up > > > > correctly. I suggest you read through msdn about Windows Installer. > > > > > > > > > > > > > > Do you know a better (more proper) way to do this then? > > > > > > > > > > > > > Like I said before, I don't know what you're trying to do. It wasn't > > > > obvious from the last patch. > > > > > > > > > > > > > > I was researching this last night and I found either custom action 19 (this > > > > > number is off the top of my head) that will fail the install and display > > > > > a message or a failed Launch Condition which will also fail install and > > > > > display a message. > > > > > > > > > > > > > Why do you want the install to fail? > > > > > > > > > The custom action 19 (?) worked beautifully in my > > > > > tests, but the problem is that it display a dialog box if it thinks it > > > > > is in full UI mode and waits for the user to press okay, and if I > > > > > understand correctly user input like this is a no no in writing wine > > > > > conformance tests > > > > > > > > > > > > > Correct. No user intervention. > > > > > > > > > > > > > > Do you have any suggestions for how to fail an > > > > > install in full UI mode without displaying a dialog box, or would this > > > > > be okay in the case of this specific conformance test? > > > > > > > > > > > > > I don't know why you want the install to fail, so I don't have any suggestions. > > > > > > > > > > Ok sorry, I will make it clearer. The reason I am writing this > > > conformance test is to tickle the bug that my patch fixed earlier (6992) > > > in which the Vector NTI installer failed because MSI_InstallPackage was > > > not properly checking the UI level (using the mask) and so having any > > > flags such as INSTALLUILEVEL_SOURCERESONLY on top of INSTALLUILEVEL_NONE > > > was making it think a full graphical install was wanted (because > > > INSTALLUILEVEL_NONE | INSTALLUILEVEL_SOURCESONLY > > > > INSTALLUILEVEL_REDUCED), and since this particular MSI was designed so > > > that it would only work for a non-UI install (initiated by the actual > > > main MSI/installer which first sets the internal install level, and not > > > be the user clicking on one of the "child" MSIs), it would quit with a > > > message (custom action 19). I would like to make a consistency check > > > that checks this to make sure that MSI_InstallPackage does in fact check > > > the UI level correctly, taking the mask on the UILevel property into > > > account. > > > > > > This, my original idea was to have a full install in the > > > ExecuteSequence, and have just one action in the UISequence that would > > > fail the install. Thus, to test this check one would set the UI level > > > to INSTALLUILEVEL_NONE | INSTALLUILEVEL_SOURCESONLY and then ask wine > > > MSI to install the package. If the package succeeded, that means that > > > MSI_InstallPackage was checking the UI level correctly (as it does now > > > since my patch that fixed bug 6992), and everything would be installed. > > > Otherwise, it would fail, nothing would be installed, and we would know > > > that the consistency check failed and wine MSI was not properly checking > > > UI level flags (as it was before my patch and as it would if some > > > regression occurred, e.g., changes in the MSI_InstallPackage code that > > > used the UI level without regard for the flags). So that is what I am > > > trying to do. Just write a conformance test that fails (in some kind of > > > proper way) in UI install but does not in the non-UI install in a way > > > that would be easy to determine with an ok(soemthing) statement. > > > > > > > You can't do this test by making the install fail, because you have no > > way to check why the install failed. Anything you test with the UI > > sequence cannot present a UI to the user. Why don't you just use a > > custom action 51 in the install ui seq to set a property to some > > value, and then make the condition of the component of an install file > > the value of the property? That way you can check if the file was > > installed or not. Either way, you're going to have to write a new > > test function for this. > > > > That sounds good. I actually made a new function doing what you said, > and in testing under the wine MSI it works perfectly (writes specific > file in UI mode but not in execute only mode, returns success, > everything okay), but when I tried in XP I got a very weird behavior (or > maybe not so weird). Specifically, XP MSI seems to reset the property > between the UI sequence and execute sequence (no errors occur, but the > file does not get written in UI sequence; if I take the condition out > the file does get written; in fact I decided to make a custom action > called StopMessage that displays the value of my property, that is > simply a custom action 19, and in Wine MSI it displays my modified > property value if I put it in the UI table or the execute table, but in > Win XP MSI it only displays my modified value in the UI table, but in > the Execute table it goes back either to blank or to the initial value > if I define it in Properties; I even tried adding it to the > SecureCustomProperties property but it did not help). Is this just a > weird XP thing that I should just ignore and post my code as is, or is > there some other way to set a property in the UI sequence that retains > its value in the execute sequence in wine and XP? What if wine MSI > decides to copy this behavior at a later date, my conformance test would > not work anymore. > Well, by definition, that's not really a conformance test because it doesn't conform to windows. Did you make the property public and add the property to the Property table? http://msdn2.microsoft.com/en-us/library/aa370912.aspx -- James Hawkins

Feb. 8, 2007

Re: msi: Make MsiInstallProduct conformance test depend on proper UI level processing.

by Misha Koshelev

On Wed, 2007-02-07 at 16:46 -0600, James Hawkins wrote: > On 2/7/07, Misha Koshelev <mk144210(a)bcm.tmc.edu> wrote: > > On Wed, 2007-02-07 at 13:23 -0600, James Hawkins wrote: > > > On 2/7/07, Misha Koshelev <mk144210(a)bcm.tmc.edu> wrote: > > > > On Wed, 2007-02-07 at 12:30 -0600, James Hawkins wrote: > > > > > On 2/7/07, Misha Koshelev <mk144210(a)bcm.tmc.edu> wrote: > > > > > > Hi, here is my proposed patch to the current msi MsiInstallProduct > > > > > > consistency test that will make it's success depend on proper process of > > > > > > UI flags (as well as everything else it depends on to make a successful > > > > > > install). It seems to me like this is the simplest way to add this test > > > > > > (it is only 5-6 lines added total), and it seems fair to me to add it to > > > > > > this existing test for two reasons: > > > > > > 1. The test is already testing a full product install (installs files, > > > > > > services, registry values, etc) and my modification will simply result > > > > > > in either no modification to these actions if UI level processing is > > > > > > good or complete failure if it is bad, which will make the problem very > > > > > > easy to diagnose. > > > > > > 2. Looking through instructions on msdn it seems that there isn't a > > > > > > kosher way to make a very simple MSI file that just, say, writes a > > > > > > registry value (without doing costing, install validation, having a full > > > > > > features table, installing some features, etc.) which would make a > > > > > > separate function easy to implement and it does not really seem > > > > > > necessary to copy and paste the whole test_MsiInstallProduct (or > > > > > > similar) function just to check UI level processing. > > > > > > > > > > > > Changelog: > > > > > > > > > > > > * msi: Make MsiInstallProduct conformance test depend on proper UI > > > > > > level processing. > > > > > > > > > > > > > > > > You need to put whatever you're trying to test into a new test > > > > > function. As-is, it's not clear what you're testing and we need to > > > > > keep the tests logically separate. Test both a success and a failure > > > > > case, plus all the in between cases. > > > > > > > > > > > If the full UI is started (incorrectly) > > > > > > + * the InstallUISequence table will be used, and the install will fail. If the full UI is > > > > > > + * not started (correctly) the InstallExecuteSequence table will be used. > > > > > > > > > > Why does the install fail if we run the InstallUISequence action?. > > > > > Also, InstallExecuteSequence runs no matter what so this comment would > > > > > need to be fixed. > > > > > a fa > > > > > > > > Weird, because it does indeed fail when running in full UI mode. > > > > > > > > > > It's failing because you don't have the InstallUISequence set up > > > correctly. I suggest you read through msdn about Windows Installer. > > > > > > > > > > > Do you know a better (more proper) way to do this then? > > > > > > > > > > Like I said before, I don't know what you're trying to do. It wasn't > > > obvious from the last patch. > > > > > > > > > > > I was researching this last night and I found either custom action 19 (this > > > > number is off the top of my head) that will fail the install and display > > > > a message or a failed Launch Condition which will also fail install and > > > > display a message. > > > > > > > > > > Why do you want the install to fail? > > > > > > > The custom action 19 (?) worked beautifully in my > > > > tests, but the problem is that it display a dialog box if it thinks it > > > > is in full UI mode and waits for the user to press okay, and if I > > > > understand correctly user input like this is a no no in writing wine > > > > conformance tests > > > > > > > > > > Correct. No user intervention. > > > > > > > > > > > Do you have any suggestions for how to fail an > > > > install in full UI mode without displaying a dialog box, or would this > > > > be okay in the case of this specific conformance test? > > > > > > > > > > I don't know why you want the install to fail, so I don't have any suggestions. > > > > > > > Ok sorry, I will make it clearer. The reason I am writing this > > conformance test is to tickle the bug that my patch fixed earlier (6992) > > in which the Vector NTI installer failed because MSI_InstallPackage was > > not properly checking the UI level (using the mask) and so having any > > flags such as INSTALLUILEVEL_SOURCERESONLY on top of INSTALLUILEVEL_NONE > > was making it think a full graphical install was wanted (because > > INSTALLUILEVEL_NONE | INSTALLUILEVEL_SOURCESONLY > > > INSTALLUILEVEL_REDUCED), and since this particular MSI was designed so > > that it would only work for a non-UI install (initiated by the actual > > main MSI/installer which first sets the internal install level, and not > > be the user clicking on one of the "child" MSIs), it would quit with a > > message (custom action 19). I would like to make a consistency check > > that checks this to make sure that MSI_InstallPackage does in fact check > > the UI level correctly, taking the mask on the UILevel property into > > account. > > > > This, my original idea was to have a full install in the > > ExecuteSequence, and have just one action in the UISequence that would > > fail the install. Thus, to test this check one would set the UI level > > to INSTALLUILEVEL_NONE | INSTALLUILEVEL_SOURCESONLY and then ask wine > > MSI to install the package. If the package succeeded, that means that > > MSI_InstallPackage was checking the UI level correctly (as it does now > > since my patch that fixed bug 6992), and everything would be installed. > > Otherwise, it would fail, nothing would be installed, and we would know > > that the consistency check failed and wine MSI was not properly checking > > UI level flags (as it was before my patch and as it would if some > > regression occurred, e.g., changes in the MSI_InstallPackage code that > > used the UI level without regard for the flags). So that is what I am > > trying to do. Just write a conformance test that fails (in some kind of > > proper way) in UI install but does not in the non-UI install in a way > > that would be easy to determine with an ok(soemthing) statement. > > > > You can't do this test by making the install fail, because you have no > way to check why the install failed. Anything you test with the UI > sequence cannot present a UI to the user. Why don't you just use a > custom action 51 in the install ui seq to set a property to some > value, and then make the condition of the component of an install file > the value of the property? That way you can check if the file was > installed or not. Either way, you're going to have to write a new > test function for this. > That sounds good. I actually made a new function doing what you said, and in testing under the wine MSI it works perfectly (writes specific file in UI mode but not in execute only mode, returns success, everything okay), but when I tried in XP I got a very weird behavior (or maybe not so weird). Specifically, XP MSI seems to reset the property between the UI sequence and execute sequence (no errors occur, but the file does not get written in UI sequence; if I take the condition out the file does get written; in fact I decided to make a custom action called StopMessage that displays the value of my property, that is simply a custom action 19, and in Wine MSI it displays my modified property value if I put it in the UI table or the execute table, but in Win XP MSI it only displays my modified value in the UI table, but in the Execute table it goes back either to blank or to the initial value if I define it in Properties; I even tried adding it to the SecureCustomProperties property but it did not help). Is this just a weird XP thing that I should just ignore and post my code as is, or is there some other way to set a property in the UI sequence that retains its value in the execute sequence in wine and XP? What if wine MSI decides to copy this behavior at a later date, my conformance test would not work anymore. Thanks Misha

Feb. 8, 2007

Re: winedump: sign-compare fixes

by richardvoigt＠gmail.com

On 2/7/07, Dmitry Timoshkov <dmitry(a)codeweavers.com> wrote: > "Joris Huizer" <joris_huizer(a)yahoo.com> wrote: > > > -static const MINIDUMP_DIRECTORY* get_mdmp_dir(const MINIDUMP_HEADER* hdr, int str_idx) > > +static const MINIDUMP_DIRECTORY* get_mdmp_dir(const MINIDUMP_HEADER* hdr,unsigned long int str_idx) > > Please keep white space unchanged. > > > - while (ptr - (const unsigned char*)table < len) > > + while ((unsigned long)(ptr - (const unsigned char*)table) < len) > > > - int i, length; > > + unsigned long int i, length; > > > - while (file - (const char*)symbols < sizeof(PDB_SYMBOLS) + symbols->module_size) > > + while ((unsigned long int)(file - (const char*)symbols) < sizeof(PDB_SYMBOLS) + symbols->module_size) > > Your changes are inconsistent: sometimes you change 'int' to 'unsigned long int', > sometimes to 'unsigned long'. Why not change 'int' simply to 'unsigned'? > Seeing int extended to unsigned long like this makes me question whether the correct type wouldn't be size_t.... especially as it is compared to sizeof(...) > -- > Dmitry. > > >

Feb. 8, 2007

Re: winegcc: sign-compare fixes

by richardvoigt＠gmail.com

On 2/7/07, Joris Huizer <joris_huizer(a)yahoo.com> wrote: > I believe this one causes problems -- please do not commit yet > > Joris Huizer <joris_huizer(a)yahoo.com> wrote: > > ________________________________ > Need Mail bonding? > Go to the Yahoo! Mail Q&A for great tips from Yahoo! Answers users.>From > 8686a200bd1f1cbd934d761013c487a9ddc195c9 Mon Sep 17 > 00:00:00 2001 > From: Joris Huizer > Date: Wed, 7 Feb 2007 15:19:25 +0100 > Subject: [PATCH] winegcc sign-compare fixes > To: wine-patches > > --- > tools/winegcc/utils.c | 13 +++++++------ > tools/winegcc/winegcc.c | 11 ++++++----- > 2 files changed, 13 insertions(+), 11 deletions(-) > > diff --git a/tools/winegcc/utils.c b/tools/winegcc/utils.c > index 1af91e9..c144077 100644 > --- a/tools/winegcc/utils.c > +++ b/tools/winegcc/utils.c > @@ -120,14 +120,14 @@ void strarray_add(strarray* arr, const c > > void strarray_del(strarray* arr, int i) > { > - if (i < 0 || i >= arr->size) error("Invalid index i=%d", i); > + if (i < 0 || (unsigned int)i >= arr->size) error("Invalid index i=%d", i); The unsigned int comparison here makes the negative check superfluous. Perhaps the argument should even be changed to unsigned as well, to match the range of arr->size (if the element is one byte). > memmove(&arr->base[i], &arr->base[i + 1], (arr->size - i - 1) * > sizeof(arr->base[0])); > arr->size--; > } If the element size could be greater than one byte, the multiplication here should be checked for overflow (actually, this is more necessary when the array is created or expanded). >

Feb. 8, 2007

Helping a user migrate an odbc app to Wine

by Dan Kegel

Can somebody help this (german-speaking) fellow: http://www.unixboard.de/vb3/showthread.php?t=26943 He says his company's internal application requires you to input a DSN when installing it, and he doesn't know how to come up with a DSN under Wine. Presumably he doesn't want to mess with Unixodbc, he just wants to keep using the Microsoft drivers...? - Dan

Feb. 8, 2007

Re: msi: Make MsiInstallProduct conformance test depend on proper UI level processing.

by James Hawkins

On 2/7/07, Misha Koshelev <mk144210(a)bcm.tmc.edu> wrote: > On Wed, 2007-02-07 at 13:23 -0600, James Hawkins wrote: > > On 2/7/07, Misha Koshelev <mk144210(a)bcm.tmc.edu> wrote: > > > On Wed, 2007-02-07 at 12:30 -0600, James Hawkins wrote: > > > > On 2/7/07, Misha Koshelev <mk144210(a)bcm.tmc.edu> wrote: > > > > > Hi, here is my proposed patch to the current msi MsiInstallProduct > > > > > consistency test that will make it's success depend on proper process of > > > > > UI flags (as well as everything else it depends on to make a successful > > > > > install). It seems to me like this is the simplest way to add this test > > > > > (it is only 5-6 lines added total), and it seems fair to me to add it to > > > > > this existing test for two reasons: > > > > > 1. The test is already testing a full product install (installs files, > > > > > services, registry values, etc) and my modification will simply result > > > > > in either no modification to these actions if UI level processing is > > > > > good or complete failure if it is bad, which will make the problem very > > > > > easy to diagnose. > > > > > 2. Looking through instructions on msdn it seems that there isn't a > > > > > kosher way to make a very simple MSI file that just, say, writes a > > > > > registry value (without doing costing, install validation, having a full > > > > > features table, installing some features, etc.) which would make a > > > > > separate function easy to implement and it does not really seem > > > > > necessary to copy and paste the whole test_MsiInstallProduct (or > > > > > similar) function just to check UI level processing. > > > > > > > > > > Changelog: > > > > > > > > > > * msi: Make MsiInstallProduct conformance test depend on proper UI > > > > > level processing. > > > > > > > > > > > > > You need to put whatever you're trying to test into a new test > > > > function. As-is, it's not clear what you're testing and we need to > > > > keep the tests logically separate. Test both a success and a failure > > > > case, plus all the in between cases. > > > > > > > > > If the full UI is started (incorrectly) > > > > > + * the InstallUISequence table will be used, and the install will fail. If the full UI is > > > > > + * not started (correctly) the InstallExecuteSequence table will be used. > > > > > > > > Why does the install fail if we run the InstallUISequence action?. > > > > Also, InstallExecuteSequence runs no matter what so this comment would > > > > need to be fixed. > > > > a fa > > > > > > Weird, because it does indeed fail when running in full UI mode. > > > > > > > It's failing because you don't have the InstallUISequence set up > > correctly. I suggest you read through msdn about Windows Installer. > > > > > > > > Do you know a better (more proper) way to do this then? > > > > > > > Like I said before, I don't know what you're trying to do. It wasn't > > obvious from the last patch. > > > > > > > > I was researching this last night and I found either custom action 19 (this > > > number is off the top of my head) that will fail the install and display > > > a message or a failed Launch Condition which will also fail install and > > > display a message. > > > > > > > Why do you want the install to fail? > > > > > The custom action 19 (?) worked beautifully in my > > > tests, but the problem is that it display a dialog box if it thinks it > > > is in full UI mode and waits for the user to press okay, and if I > > > understand correctly user input like this is a no no in writing wine > > > conformance tests > > > > > > > Correct. No user intervention. > > > > > > > > Do you have any suggestions for how to fail an > > > install in full UI mode without displaying a dialog box, or would this > > > be okay in the case of this specific conformance test? > > > > > > > I don't know why you want the install to fail, so I don't have any suggestions. > > > > Ok sorry, I will make it clearer. The reason I am writing this > conformance test is to tickle the bug that my patch fixed earlier (6992) > in which the Vector NTI installer failed because MSI_InstallPackage was > not properly checking the UI level (using the mask) and so having any > flags such as INSTALLUILEVEL_SOURCERESONLY on top of INSTALLUILEVEL_NONE > was making it think a full graphical install was wanted (because > INSTALLUILEVEL_NONE | INSTALLUILEVEL_SOURCESONLY > > INSTALLUILEVEL_REDUCED), and since this particular MSI was designed so > that it would only work for a non-UI install (initiated by the actual > main MSI/installer which first sets the internal install level, and not > be the user clicking on one of the "child" MSIs), it would quit with a > message (custom action 19). I would like to make a consistency check > that checks this to make sure that MSI_InstallPackage does in fact check > the UI level correctly, taking the mask on the UILevel property into > account. > > This, my original idea was to have a full install in the > ExecuteSequence, and have just one action in the UISequence that would > fail the install. Thus, to test this check one would set the UI level > to INSTALLUILEVEL_NONE | INSTALLUILEVEL_SOURCESONLY and then ask wine > MSI to install the package. If the package succeeded, that means that > MSI_InstallPackage was checking the UI level correctly (as it does now > since my patch that fixed bug 6992), and everything would be installed. > Otherwise, it would fail, nothing would be installed, and we would know > that the consistency check failed and wine MSI was not properly checking > UI level flags (as it was before my patch and as it would if some > regression occurred, e.g., changes in the MSI_InstallPackage code that > used the UI level without regard for the flags). So that is what I am > trying to do. Just write a conformance test that fails (in some kind of > proper way) in UI install but does not in the non-UI install in a way > that would be easy to determine with an ok(soemthing) statement. > You can't do this test by making the install fail, because you have no way to check why the install failed. Anything you test with the UI sequence cannot present a UI to the user. Why don't you just use a custom action 51 in the install ui seq to set a property to some value, and then make the condition of the component of an install file the value of the property? That way you can check if the file was installed or not. Either way, you're going to have to write a new test function for this. -- James Hawkins

Feb. 7, 2007

Re: Undoc. comctl32 mem management functions

by Robert Shearman

Felix Nawothnig wrote: > Hi. comctl32 exports (undocumented) Alloc() and friends which call > LocalAlloc => GlobalAlloc => HeapAlloc since it's doesn't use any > fancy LMEM / GMEM flags... so shouldn't Alloc() call HeapAlloc() > directly? > > If Global/Local* behave different than Heap* on Windows - wouldn't it > then be desirable to replace the Alloc()/etc. calls in our comctl32 > (we use it all over the place) by Heap*? There are probably quite a few locations where it doesn't make a difference, but there are also probably a few locations where it does. Since it is easier to use the Alloc/ReAlloc/Free functions, why bother changing them to the longer Heap* variants? > > Reason I'm asking: Since it's not documented the Free(NULL) semantics > are not clear (although it's safe in our implementation) - and I'm > wondering if we really want to internally use undocumented functions > with unclear semantics when there is an easy (documented) way. Well, I think it needs to be tested on Windows if Free(NULL) is valid before changing the calls in comctl32. -- Rob Shearman

Feb. 7, 2007

Re: [PATCH 3/6] oleaut32: Comment out "dual" attribute of IKindaEnumWidget in tmarshal test to cause the interface to be marshaled correctly.

by Alexandre Julliard

Robert Shearman <rob(a)codeweavers.com> writes: > Did you remove ~/.wine? It only registers the typelib if the typelib > hasn't already been registered (perhaps this should be changed.) Ah sorry, I missed that part. Yes, I think that needs to be changed, we can't ask people to rm -rf their .wine dir all the time. At the very least there needs to be an easy way to force the re-registration. -- Alexandre Julliard julliard(a)winehq.org

Feb. 7, 2007

Re: [PATCH 3/6] oleaut32: Comment out "dual" attribute of IKindaEnumWidget in tmarshal test to cause the interface to be marshaled correctly.

by Robert Shearman

Alexandre Julliard wrote: > Robert Shearman <rob(a)codeweavers.com> writes: > > >> This fixes a bunch of tmarshal tests. >> > > It doesn't seem to make any difference for me: > > ../../../tools/runtest -q -P wine -M oleaut32.dll -T ../../.. -p oleaut32_test.exe.so tmarshal.c && touch tmarshal.ok > tmarshal.c:139: Test failed: CoMarshalInterface failed with error 0x80040155 > tmarshal.c:765: Test failed: CoUnmarshalInterface failed with error 0x80040155 > tmarshal.c:784: Test failed: EXCEPINFO differs from expected: wCode = 0x2, scode = 0x7bc7a2c8 > tmarshal.c:803: Test failed: EXCEPINFO differs from expected: wCode = 0x2, scode = 0x7bc7a2c8 > tmarshal.c:915: Test failed: EXCEPINFO differs from expected: wCode = 0x2, scode = 0x7bc7a2c8 > tmarshal.c:942: Test failed: EXCEPINFO differs from expected: wCode = 0x2, scode = 0x7bc7a2c8 > tmarshal.c:977: Test failed: EXCEPINFO differs from expected: wCode = 0x2, scode = 0x80004001 > make: *** [tmarshal.ok] Error 7 Did you remove ~/.wine? It only registers the typelib if the typelib hasn't already been registered (perhaps this should be changed.) -- Rob Shearman

Feb. 7, 2007

Re: [PATCH 3/6] oleaut32: Comment out "dual" attribute of IKindaEnumWidget in tmarshal test to cause the interface to be marshaled correctly.

by Alexandre Julliard

Robert Shearman <rob(a)codeweavers.com> writes: > This fixes a bunch of tmarshal tests. It doesn't seem to make any difference for me: ../../../tools/runtest -q -P wine -M oleaut32.dll -T ../../.. -p oleaut32_test.exe.so tmarshal.c && touch tmarshal.ok tmarshal.c:139: Test failed: CoMarshalInterface failed with error 0x80040155 tmarshal.c:765: Test failed: CoUnmarshalInterface failed with error 0x80040155 tmarshal.c:784: Test failed: EXCEPINFO differs from expected: wCode = 0x2, scode = 0x7bc7a2c8 tmarshal.c:803: Test failed: EXCEPINFO differs from expected: wCode = 0x2, scode = 0x7bc7a2c8 tmarshal.c:915: Test failed: EXCEPINFO differs from expected: wCode = 0x2, scode = 0x7bc7a2c8 tmarshal.c:942: Test failed: EXCEPINFO differs from expected: wCode = 0x2, scode = 0x7bc7a2c8 tmarshal.c:977: Test failed: EXCEPINFO differs from expected: wCode = 0x2, scode = 0x80004001 make: *** [tmarshal.ok] Error 7 -- Alexandre Julliard julliard(a)winehq.org

Feb. 7, 2007

Re: Getting Fallout 2 to work well

by Joonas Koivunen

2007/2/5, Mitchell Mebane <mitchell.mebane(a)gmail.com>: > > Stefan Dösinger wrote: > > Am Freitag 02 Februar 2007 08:34 schrieb Joonas Koivunen: > > Profiling with oprofile (GDI session) shows that most of the time is used > in the game (I suppose it's the "anon" from wine-preload), next most time > consuming is winex11 drivers X11DRV_DIB_SetImageBits which seems to be > > doing the conversion. > > It seems that you have a game that has problems with the gdi engine(or lack > thereof): http://wiki.winehq.org/DIBEngine > > http://bugs.winehq.org/show_bug.cgi?id=421 > > How much work would this be? I know nothing about Windows or X11 > programming, but is it something that I might be able to study up on and > propose for a Summer of Code project? > > --mmebane > For the past days, after Stefan pointed me to that bug and article, I've been trying to figure out what would be needed in order to fasten at least Fallout 2 up. I haven't been able to pinpoint any call made by the game requesting an image from X, and it always blits the whole screen at a time. Doing 640x480 8bpp -> 32bpp seems to be the problem and the fact that it does as many as possible blits. Nor have I been able to find a call asking it to blend two surfaces.. Could someone give me any hints on this? The 8bpp -> 32bpp conversion could possibly be optimized.. But I haven't yet looked at it. A bit out of topic; playing fallout2.exe makes X11 grow much larger, and it doesn't seem to free the memory. A SoC project sounds great! -- -- Joonas Koivunen

Feb. 7, 2007

Re: msi: Register the typelib

by Alexandre Julliard

Mike McCormack <mike(a)codeweavers.com> writes: > +ITypeLib *get_msi_typelib( LPWSTR *path ) > +{ > + static CRITICAL_SECTION cs = { NULL, -1, 0, 0, 0, 0 }; Please use the standard pattern for static critical sections. Setting the debug info to NULL is reserved for global sections. -- Alexandre Julliard julliard(a)winehq.org

Feb. 7, 2007

Re: msi: Make MsiInstallProduct conformance test depend on proper UI level processing.

by Misha Koshelev

On Wed, 2007-02-07 at 13:23 -0600, James Hawkins wrote: > On 2/7/07, Misha Koshelev <mk144210(a)bcm.tmc.edu> wrote: > > On Wed, 2007-02-07 at 12:30 -0600, James Hawkins wrote: > > > On 2/7/07, Misha Koshelev <mk144210(a)bcm.tmc.edu> wrote: > > > > Hi, here is my proposed patch to the current msi MsiInstallProduct > > > > consistency test that will make it's success depend on proper process of > > > > UI flags (as well as everything else it depends on to make a successful > > > > install). It seems to me like this is the simplest way to add this test > > > > (it is only 5-6 lines added total), and it seems fair to me to add it to > > > > this existing test for two reasons: > > > > 1. The test is already testing a full product install (installs files, > > > > services, registry values, etc) and my modification will simply result > > > > in either no modification to these actions if UI level processing is > > > > good or complete failure if it is bad, which will make the problem very > > > > easy to diagnose. > > > > 2. Looking through instructions on msdn it seems that there isn't a > > > > kosher way to make a very simple MSI file that just, say, writes a > > > > registry value (without doing costing, install validation, having a full > > > > features table, installing some features, etc.) which would make a > > > > separate function easy to implement and it does not really seem > > > > necessary to copy and paste the whole test_MsiInstallProduct (or > > > > similar) function just to check UI level processing. > > > > > > > > Changelog: > > > > > > > > * msi: Make MsiInstallProduct conformance test depend on proper UI > > > > level processing. > > > > > > > > > > You need to put whatever you're trying to test into a new test > > > function. As-is, it's not clear what you're testing and we need to > > > keep the tests logically separate. Test both a success and a failure > > > case, plus all the in between cases. > > > > > > > If the full UI is started (incorrectly) > > > > + * the InstallUISequence table will be used, and the install will fail. If the full UI is > > > > + * not started (correctly) the InstallExecuteSequence table will be used. > > > > > > Why does the install fail if we run the InstallUISequence action?. > > > Also, InstallExecuteSequence runs no matter what so this comment would > > > need to be fixed. > > > a fa > > > > Weird, because it does indeed fail when running in full UI mode. > > > > It's failing because you don't have the InstallUISequence set up > correctly. I suggest you read through msdn about Windows Installer. > > > > > Do you know a better (more proper) way to do this then? > > > > Like I said before, I don't know what you're trying to do. It wasn't > obvious from the last patch. > > > > > I was researching this last night and I found either custom action 19 (this > > number is off the top of my head) that will fail the install and display > > a message or a failed Launch Condition which will also fail install and > > display a message. > > > > Why do you want the install to fail? > > > The custom action 19 (?) worked beautifully in my > > tests, but the problem is that it display a dialog box if it thinks it > > is in full UI mode and waits for the user to press okay, and if I > > understand correctly user input like this is a no no in writing wine > > conformance tests > > > > Correct. No user intervention. > > > > > Do you have any suggestions for how to fail an > > install in full UI mode without displaying a dialog box, or would this > > be okay in the case of this specific conformance test? > > > > I don't know why you want the install to fail, so I don't have any suggestions. > Ok sorry, I will make it clearer. The reason I am writing this conformance test is to tickle the bug that my patch fixed earlier (6992) in which the Vector NTI installer failed because MSI_InstallPackage was not properly checking the UI level (using the mask) and so having any flags such as INSTALLUILEVEL_SOURCERESONLY on top of INSTALLUILEVEL_NONE was making it think a full graphical install was wanted (because INSTALLUILEVEL_NONE | INSTALLUILEVEL_SOURCESONLY > INSTALLUILEVEL_REDUCED), and since this particular MSI was designed so that it would only work for a non-UI install (initiated by the actual main MSI/installer which first sets the internal install level, and not be the user clicking on one of the "child" MSIs), it would quit with a message (custom action 19). I would like to make a consistency check that checks this to make sure that MSI_InstallPackage does in fact check the UI level correctly, taking the mask on the UILevel property into account. This, my original idea was to have a full install in the ExecuteSequence, and have just one action in the UISequence that would fail the install. Thus, to test this check one would set the UI level to INSTALLUILEVEL_NONE | INSTALLUILEVEL_SOURCESONLY and then ask wine MSI to install the package. If the package succeeded, that means that MSI_InstallPackage was checking the UI level correctly (as it does now since my patch that fixed bug 6992), and everything would be installed. Otherwise, it would fail, nothing would be installed, and we would know that the consistency check failed and wine MSI was not properly checking UI level flags (as it was before my patch and as it would if some regression occurred, e.g., changes in the MSI_InstallPackage code that used the UI level without regard for the flags). So that is what I am trying to do. Just write a conformance test that fails (in some kind of proper way) in UI install but does not in the non-UI install in a way that would be easy to determine with an ok(soemthing) statement. Any advice would be appreciated. Thanks. Misha

Feb. 7, 2007

Re: msi: Make MsiInstallProduct conformance test depend on proper UI level processing.

by James Hawkins

On 2/7/07, Misha Koshelev <mk144210(a)bcm.tmc.edu> wrote: > On Wed, 2007-02-07 at 12:30 -0600, James Hawkins wrote: > > On 2/7/07, Misha Koshelev <mk144210(a)bcm.tmc.edu> wrote: > > > Hi, here is my proposed patch to the current msi MsiInstallProduct > > > consistency test that will make it's success depend on proper process of > > > UI flags (as well as everything else it depends on to make a successful > > > install). It seems to me like this is the simplest way to add this test > > > (it is only 5-6 lines added total), and it seems fair to me to add it to > > > this existing test for two reasons: > > > 1. The test is already testing a full product install (installs files, > > > services, registry values, etc) and my modification will simply result > > > in either no modification to these actions if UI level processing is > > > good or complete failure if it is bad, which will make the problem very > > > easy to diagnose. > > > 2. Looking through instructions on msdn it seems that there isn't a > > > kosher way to make a very simple MSI file that just, say, writes a > > > registry value (without doing costing, install validation, having a full > > > features table, installing some features, etc.) which would make a > > > separate function easy to implement and it does not really seem > > > necessary to copy and paste the whole test_MsiInstallProduct (or > > > similar) function just to check UI level processing. > > > > > > Changelog: > > > > > > * msi: Make MsiInstallProduct conformance test depend on proper UI > > > level processing. > > > > > > > You need to put whatever you're trying to test into a new test > > function. As-is, it's not clear what you're testing and we need to > > keep the tests logically separate. Test both a success and a failure > > case, plus all the in between cases. > > > > > If the full UI is started (incorrectly) > > > + * the InstallUISequence table will be used, and the install will fail. If the full UI is > > > + * not started (correctly) the InstallExecuteSequence table will be used. > > > > Why does the install fail if we run the InstallUISequence action?. > > Also, InstallExecuteSequence runs no matter what so this comment would > > need to be fixed. > > a fa > > Weird, because it does indeed fail when running in full UI mode. > It's failing because you don't have the InstallUISequence set up correctly. I suggest you read through msdn about Windows Installer. > > Do you know a better (more proper) way to do this then? > Like I said before, I don't know what you're trying to do. It wasn't obvious from the last patch. > > I was researching this last night and I found either custom action 19 (this > number is off the top of my head) that will fail the install and display > a message or a failed Launch Condition which will also fail install and > display a message. > Why do you want the install to fail? > The custom action 19 (?) worked beautifully in my > tests, but the problem is that it display a dialog box if it thinks it > is in full UI mode and waits for the user to press okay, and if I > understand correctly user input like this is a no no in writing wine > conformance tests > Correct. No user intervention. > > Do you have any suggestions for how to fail an > install in full UI mode without displaying a dialog box, or would this > be okay in the case of this specific conformance test? > I don't know why you want the install to fail, so I don't have any suggestions. -- James Hawkins

Feb. 7, 2007