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

re: lstrlen(A/W) patch

by Dan Kegel

Clinton wrote: >> Does the Richedit control return an error, or clear itself when passed >> EM_SETTEXTEX with lParam = NULL? >On Windows, it returns 1 and clears itself. Unless the ST_SELECTION >flag is set, in which case it returns 0, and actually replaces the text >with nothing. >My patch to wine results in the same behavior. I'll send it to >wine-patches. Great! Any chance you could include a conformance test in your patch? Thanks, Dan

June 7, 2006

Re: shell32: Write-strings warning fix

by Robert Shearman

Andrew Talbot wrote: >Changelog: > shell32: Write-strings warning fix. > >diff -urN a/dlls/shell32/shlview.c b/dlls/shell32/shlview.c >--- a/dlls/shell32/shlview.c 2006-05-23 17:24:50.000000000 +0100 >+++ b/dlls/shell32/shlview.c 2006-06-07 19:37:41.000000000 +0100 >@@ -779,7 +779,9 @@ > */ > > static void ShellView_MergeViewMenu(IShellViewImpl * This, HMENU hSubMenu) >-{ MENUITEMINFOA mii; >+{ >+ MENUITEMINFOA mii; >+ static CHAR mii_type_data[] = "View"; > > TRACE("(%p)->(submenu=%p)\n",This,hSubMenu); > >@@ -791,7 +793,7 @@ > mii.cbSize = sizeof(mii); > mii.fMask = MIIM_SUBMENU | MIIM_TYPE | MIIM_DATA; > mii.fType = MFT_STRING; >- mii.dwTypeData = "View"; >+ mii.dwTypeData = mii_type_data; > mii.hSubMenu = LoadMenuA(shell32_hInstance, "MENU_001"); > InsertMenuItemA(hSubMenu, FCIDM_MENU_VIEW_SEP_OPTIONS, FALSE, &mii); > } > Sorry, this is wrong. If InsertMenuItemA writes to the string then it will be corrupted and will display the wrong thing for further uses in the process. It is therefore better to cast it from a "const char *" into a "char *" or to make it a non-static array at the top of the function. I think the first choice of keeping it a "const char *" is the best choice in this case. -- Rob Shearman

June 7, 2006

Re: Linux noob

by Kuba Ober

> I'm annoyed that .wine is inaccessible through KDE and Gnome apps. It is accessible all right. You just don't know how to get there. > Not through the file manager, but often in various applications. nope. Unless you're talking about some very broken applications that I didn't come across yet. > It's not wine's fault per se that those apps lack a "show hidden > folders" option KDE applications hopefully use KDE's open/save dialog, and there it's a matter of pressing F8 to hide/unhide hidden files. I'm sure Gnome has something similar, but I don't use it so I didn't bother looking the key up. I.e. no big deal. Cheers, Kuba

June 7, 2006

Re: [uxtheme/tests] Add initial tests (Second try)

by Paul Vriens

On Wed, 2006-06-07 at 08:44 +0200, Paul Vriens wrote: > Hi, > > I've added the framework and some initial (simple) tests. No > functionality tests (yet), only parameter and return-value checking. > > This one also 'fixes' the tests for Wine when theming is enabled. > > Changelog > Added framework and initial tests > > Cheers, > > Paul. Anything I can do to improve? This patch will of course be followed up by fixes. Cheers, Paul.

June 7, 2006

Re: Feedback requested on an OpenAL audio driver patch

by Leon Freitag

My first impressions: 1) Doesn't compile here: audio.c: In function ‘OpenAL_WaveClose’: audio.c:636: error: void value not ignored as it ought to be because alcCloseDevice() is declared here as void (my openal version is 1.0.20051129) 2) It'd be better to convert ALC errors from FIXMEs to ERRs. 3) You don't link the driver to openal somewhy (there's no -lopenal switch passed to gcc). Perhaps it's related to the configure.in hack I made, but I had to modify dlls/winmm/wineopenal/Makefile.in and add openal there too. 4) You check for al/al.h and OpenAL/al.h within the configure script but you include AL/al.h and OpenAL/al.h. This doesn't work on Linux, since Linux filesystems are case sensitive. Leon

June 7, 2006

Re: Hal and functions in setupapi

by Mike McCormack

Damjan Jovanovic wrote: > That's not anything close to how SETUPAPI works on > Windows. Download devinst.c from ReactOS's SETUPAPI > and have a look. No, please don't do that, you'll risk having your patches rejected. Implement it in the way that is right for Wine. The only interfaces you need to know about are the ones that applications know about. Mike

June 7, 2006

Re: libunicode: Add some more code page tables that are available for download from ftp.unicode.org, most notably the table for the us-ascii encoding, which is quite common.

by Alexandre Julliard

Robert Shearman <rob(a)codeweavers.com> writes: > libs/unicode/Makefile.in | 3 > libs/unicode/c_1361.c | 5138 > ++++++++++++++++++++++++++++++++++++++++++++++ > libs/unicode/c_20000.c | 3587 ++++++++++++++++++++++++++++++++ > libs/unicode/c_20127.c | 683 ++++++ > libs/unicode/cpmap.pl | 3 > libs/unicode/cptable.c | 8 This won't work, the source files are not in the expected format, so the resulting tables contain garbage. You'll need to teach cpmap.pl to parse these files correctly. -- Alexandre Julliard julliard(a)winehq.org

June 7, 2006

Re: [Wine] Re: Linux noob

by Peter Beutner

Molle Bestefich wrote: > Peter Beutner wrote: >> Because it is the defacto standard to store settings >> under ~/.<appname>. > > Only for stuff that's thought to be generally uninteresting. well, speaking of system.reg, user.reg and dosdevices/, I think they are "generally uninteresting". And if you mangle with them you rather want to use regedit/winecfg, than editing them by hand. So making them hidden by default is imho fine.(and there is still WINEPREFIX if you don't like it ;) ) The other thing is the default location for drive C:, which might be better in a "visible" place(e.g. ~/Drive_C). Though you can already configure that through winecfg to any path you like.

June 7, 2006

Re: Hal and functions in setupapi

by Damjan Jovanovic

--- Christian Gmeiner <christian.gmeiner(a)students.fh-vorarlberg.ac.at> wrote: > Hi all... > > at the momemt i am reading into functions to get > some informations about > e.g. cdrom drives. At the moment > i am loking into SetupDiGetClassDevsW to support > GUID_DEVINTERFACE_CDROM and > later USB devices. > My overall goal is it to get Line 6 software for my > guitart effect board > (USB) working with wine. I would be very interested in getting USB working on wine, and I've already had a deep long look at both setupapi's device installation API and HAL. Can we work together on this? > Now i thought about a way to get all informations > about a singe cdrom > device. And i thought that I could use HAL perfectly > for this. > I thought about this way of doing it: > Add hal.c file to setupapi dll, which contains > function to get infromations > about all needed hardware. This should work very > nicly > for this case. But as I want to programm > RegisterDeviceNotification also we > need a central way to handle hal stuff. RegisterDeviceNofications() is only necessary for services (which wine poorly supports anyway) - you can always cheat by creating an invisible top-level window to receive WM_DEVICECHANGE messages. > So how should I go on? Use some own hal.c in > setupapi or add an global wine > way to interact with hal? That's not anything close to how SETUPAPI works on Windows. Download devinst.c from ReactOS's SETUPAPI and have a look. Some SETUPAPI device installer functions delegate to CFGMGR32.DLL and those either to the Windows registry or to even worse things (undocumented RPCs to the UMPNPMGR service, some of which are implemented by system calls...). In the case of CDROM enumeration, rather use wine's internal drive list and pull CDROMs from there. In the case of USB, to say it needs a lot of work is an understatement... > Thanks, > Christian > > Let me know what your plans are with USB so maybe we can work together on it. Damjan __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com

June 7, 2006

Re: Feedback requested on an OpenAL audio driver patch

by Leon Freitag

P.S. Isn't it better to use pkg-config to check where the libs are located anyway? Leon

June 7, 2006

Re: Feedback requested on an OpenAL audio driver patch

by Leon Freitag

> AC_CHECK_HEADERS(\ >+ OpenAL/al.h \ >+ al/al.h \ > AudioUnit/AudioUnit.h \ > CoreAudio/CoreAudio.h \ > IOKit/IOKitLib.h \ Your patch checks for OpenAL headers only in these places. However my distro (Suse 10.1) puts openal headers to AL/ instead of al/ and so configure with the patch as-is doesn't find files on my system. Also patching dlls/makefile.in fails. Had to patch it manually. Leon

June 7, 2006

Re: winecfg: Avoid unnecessary casts

by Detlef Riekenberg

Am Mittwoch, den 07.06.2006, 16:45 +0900 schrieb Dmitry Timoshkov: > - psh.u3.ppsp = (LPCPROPSHEETPAGEW) & psp; > + psh.u3.ppsp = psp; Where is the "&" ? -- By By ... ... Detlef

June 7, 2006

Re: Feedback requested for Mac OSX x86 stack patch

by Alexandre Julliard

"Nick Burns" <adger44(a)hotmail.com> writes: > What about overriding __cdecl and __stdcall? > Are there any internal functions that use those that should not? > That would get around the APIENTRY/WINAPI/CALLBACK problem with OpenGL That's probably the easiest, yes. It may well cover too many functions, but it's better to err in this direction. We'll still need to make sure all exported cdecl functions use __cdecl though. -- Alexandre Julliard julliard(a)winehq.org

June 7, 2006

Re: How are we doing?

by Kai Blin

* Molle Bestefich <molle.bestefich(a)gmail.com> [05/06/06, 15:21:08]: I'm not going to try and answer all of these questions, but this one I think I can answer. > Honestly, I think that you just don't like me and that's why you > comprehend everything I write in an extremely prejudicious, negative > manner. > How many FOSS projects have you interacted with? Did it occur to you that as identities on the internet can or cannot be what or who they appear to be (I think the quote to that is "On the internet, noone knows you're a dog"), you need to base your trust and respect for people on something else? In most FOSS projecs I know, it's contributed source code. The reply you got from Dmitry was an open source classic. I've seen a couple of people getting that kind of reply, including me. It's not really meant as harsh as it looks, it's more a way of saying "I know <developer> because he contributed a lot of code, you didn't, so I don't know if I can trust you or if you just want to troll". If your changelog entries reach a significant number, noone will think you are a troll. You still might have some clashes with people having a different opinion, but you'll also be a developer, so people can look at your code to decide if they want to trust you or not. This is just how FOSS development works, and I've yet to see a successful project taking a radically different approach here. Cheers, Kai -- Kai Blin, (blin at gmx dot net) Five bicycles make a volkswagen, seven make a truck. -- Adolfo Guzman

June 7, 2006

Re: [WINED3D 2/3] Fix missing light recording

by Michael Stefaniuc

Ivan Gyurdiev wrote: > >> >From nobody Mon Sep 17 00:00:00 2001 >> > > Please delete this line in case the patch is corrupt.. missed it The patch is not corrupted as it starts only with the '---' line. 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

June 7, 2006

My new hero...

by Dan Kegel

Qingdao is my new hero. He's really on a roll: http://www.winehq.org/pipermail/wine-cvs/2006-June/023427.html fixes a Visual Basic safearray redim bug, http://bugs.winehq.org/show_bug.cgi?id=5217 and he has two other fixes in unrelated areas this month. Mike, what was that you were saying about there not being any wine hackers who fixed problems all around the wine tree anymore? - Dan -- Wine for Windows ISVs: http://kegel.com/wine/isv

June 7, 2006

Re: lstrlen(A/W) patch

by Clinton Stimpson

Mike McCormack wrote: > > Clinton Stimpson wrote: > >> Oh, used internally, ok (I thought it was public and that the wine >> debugger said Paf 5.2 called that lstrlenW directly). > > The public version is defined in dlls/kernel/string.c, and has an > exception handler as required by Win32. > >> So here's another patch that fixes a crash in Personal Ancestral File >> 5.2 when opening notes for an individual that has no notes. >> I'm not sure that's how it is supposed to be fixed, but at least you >> can see that the root of the crash is a EM_SETTEXTEX message with >> lParam = NULL. > > These patches should be sent to wine-patches. > > Does the Richedit control return an error, or clear itself when passed > EM_SETTEXTEX with lParam = NULL? On Windows, it returns 1 and clears itself. Unless the ST_SELECTION flag is set, in which case it returns 0, and actually replaces the text with nothing. My patch to wine results in the same behavior. I'll send it to wine-patches. Thanks, Clint

June 6, 2006

Re: Linux noob

by Joseph Garvin

GTK dialogs can always show hidden folders, just right click and click "Show Hidden Folders." Molle Bestefich wrote: > Neil Skrypuch wrote: >> I can't say I've ever seen that. What apps in particular? > > Can't remember offhand. > I was annoyed enough by it to create the symlink at one point. > >> Both the standard Qt open file dialog and the Gtk open file dialog >> work fine >> with . directories for me, which doesn't leave many apps that could not >> work. > > No, that's not true.. The behaviour of the dialogs depend on the app > somehow. > > AFAIR, I've seen Qt dialogs activate the .wine folder as a selection > or cancel the dialog instead of descending into it, and Gtk dialogs > completely unable to display hidden folders. But I've also seen that > some Qt apps work fine. > > Sorry I can't provide any more details, it's not like I make a habit > of remembering this stuff :-). > > (... And it still wasn't my main point, either ;-).) > > >

June 6, 2006

Re: Feedback requested for Mac OSX x86 stack patch

by Nick Burns

Although I probably should not talk to myself (responding to my own email) Something did occur to me >From: "Nick Burns" <adger44(a)hotmail.com> >To: wine-devel(a)winehq.org, julliard(a)winehq.org >Subject: Re: Feedback requested for Mac OSX x86 stack patch >Date: Tue, 06 Jun 2006 18:49:54 -0700 > >>From: Alexandre Julliard <julliard(a)winehq.org> >>Date: Tue, 06 Jun 2006 21:20:51 +0200 >> >>"Nick Burns" <adger44(a)hotmail.com> writes: >> >> > Ok so that makes more sense about MSVCRT -- but if it is using cdecl -- >> > shouldnt that use WINAPIV? >> >>CDECL would be more appropriate. > >Well is CDECL for windows callable functions? >I was under the impression that WINAPI/WINAPIV were used for windows >callable functions... >(Where I got that impression I do not know.) Is that wrong? > If __cdecl was overridden would that affect msvcrt? >> >> > I did not see anything forcing a cdecl calling convention (other than >> > the spec file). And I dunno how to modify the spec file to add in more >> > attribs. >> >>cdecl is the default, that's why it's not specified. > >Since they are windows callable functions should they and others like them >be denoted as such? >Internal functions are different then those callable from windows. >That difference does not have to be made... But it allows for a little >extra performance. > Are __stdcall or __cdecl used for any internal functions? >> >> > So, should I finish this patch (e.g. catch every single callable >> > function and put the attrib on it) >> > Or, should I send the simple 99% patch first for WINAPI/WINAPIV >> > (removing meaningless redefs) -- I would probably ignore msvcrt for >> > the first patch >> >>Eventually of course we have to catch every function, but redefining >>WINAPI is already a good start. >> > >Hmm I am seeing a few problems in this area... >I was looking at why those undefs/redefs exist... and they are used around >areas where APIENTRY/WINAPI/CALLBACK are potentially used (either >internally or externally -- mainly by OpenGL headers or function protos). >This may need a different fix -- sadly the c preprocessor is a very limited >language > >Any ideas in this realm? > What about overriding __cdecl and __stdcall? Are there any internal functions that use those that should not? That would get around the APIENTRY/WINAPI/CALLBACK problem with OpenGL The main reason I overrode WINAPI and WINAPIV was because of my previously mentioned impression (...) >>-- >>Alexandre Julliard >>julliard(a)winehq.org > >- Nick > - Nick (again)

June 6, 2006

Re: Feedback requested for Mac OSX x86 stack patch

by Nick Burns

>From: Alexandre Julliard <julliard(a)winehq.org> >Date: Tue, 06 Jun 2006 21:20:51 +0200 > >"Nick Burns" <adger44(a)hotmail.com> writes: > > > Ok so that makes more sense about MSVCRT -- but if it is using cdecl -- > > shouldnt that use WINAPIV? > >CDECL would be more appropriate. Well is CDECL for windows callable functions? I was under the impression that WINAPI/WINAPIV were used for windows callable functions... (Where I got that impression I do not know.) Is that wrong? > > > I did not see anything forcing a cdecl calling convention (other than > > the spec file). And I dunno how to modify the spec file to add in more > > attribs. > >cdecl is the default, that's why it's not specified. Since they are windows callable functions should they and others like them be denoted as such? Internal functions are different then those callable from windows. That difference does not have to be made... But it allows for a little extra performance. > > > So, should I finish this patch (e.g. catch every single callable > > function and put the attrib on it) > > Or, should I send the simple 99% patch first for WINAPI/WINAPIV > > (removing meaningless redefs) -- I would probably ignore msvcrt for > > the first patch > >Eventually of course we have to catch every function, but redefining >WINAPI is already a good start. > Hmm I am seeing a few problems in this area... I was looking at why those undefs/redefs exist... and they are used around areas where APIENTRY/WINAPI/CALLBACK are potentially used (either internally or externally -- mainly by OpenGL headers or function protos). This may need a different fix -- sadly the c preprocessor is a very limited language Any ideas in this realm? >-- >Alexandre Julliard >julliard(a)winehq.org - Nick

June 6, 2006

Re: lstrlen(A/W) patch

by Mike McCormack

Clinton Stimpson wrote: > Oh, used internally, ok (I thought it was public and that the wine > debugger said Paf 5.2 called that lstrlenW directly). The public version is defined in dlls/kernel/string.c, and has an exception handler as required by Win32. > So here's another patch that fixes a crash in Personal Ancestral File > 5.2 when opening notes for an individual that has no notes. > I'm not sure that's how it is supposed to be fixed, but at least you can > see that the root of the crash is a EM_SETTEXTEX message with lParam = > NULL. These patches should be sent to wine-patches. Does the Richedit control return an error, or clear itself when passed EM_SETTEXTEX with lParam = NULL? Mike

June 6, 2006

Re: lstrlen(A/W) patch

by Clinton Stimpson

Mike McCormack wrote: > > Clinton Stimpson wrote: > >> The following patch will fix the crash. >> MSDN documentation says "*lstrlen* assumes that /lpString/ is a >> null-terminated string, or NULL" > > The inline lstrlenW is used only internally by Wine code, and we want > it to crash when passed a NULL pointer. In this case, you should fix > the Wine code calling lstrlenW to not use a NULL pointer. > > Mike Mike, Oh, used internally, ok (I thought it was public and that the wine debugger said Paf 5.2 called that lstrlenW directly). So here's another patch that fixes a crash in Personal Ancestral File 5.2 when opening notes for an individual that has no notes. I'm not sure that's how it is supposed to be fixed, but at least you can see that the root of the crash is a EM_SETTEXTEX message with lParam = NULL. Also, it looks like bugs 4344 and 4585 were fixed quite recently. Thanks, Clint Index: caret.c =================================================================== RCS file: /home/wine/wine/dlls/riched20/caret.c,v retrieving revision 1.27 diff -u -r1.27 caret.c --- caret.c 23 May 2006 12:48:31 -0000 1.27 +++ caret.c 7 Jun 2006 01:16:34 -0000 @@ -382,8 +382,10 @@ ME_DeleteSelection(editor); assert(nCursor>=0 && nCursor<editor->nCursors); - if (len == -1) + if (len == -1 && str) len = lstrlenW(str); + else if(len == -1) + len = 0; while (len) { pos = str; Index: editor.c =================================================================== RCS file: /home/wine/wine/dlls/riched20/editor.c,v retrieving revision 1.108 diff -u -r1.108 editor.c --- editor.c 23 May 2006 12:48:31 -0000 1.108 +++ editor.c 7 Jun 2006 01:16:34 -0000 @@ -1591,7 +1591,9 @@ { LPWSTR wszText = (LPWSTR)lParam; SETTEXTEX *pStruct = (SETTEXTEX *)wParam; - size_t len = lstrlenW(wszText); + size_t len = 0; + if(wszText) + len = lstrlenW(wszText); int from, to; ME_Style *style; TRACE("EM_SETTEXEX - %s, flags %d, cp %d\n", debugstr_w(wszText), (int)pStruct->flags, pStruct->codepage);

June 6, 2006

Re: Prospects of an OpenAL audio driver...

by Nick Burns

>Date: Tue, 06 Jun 2006 22:36:26 +0200 > >Nick Burns wrote: > >>OpenAL 1.1 supports recording... (1.0 does not have recording so that is a >>problem yes) >>-- My driver handles this atm -- it checks for recording capabilities and >>supports accordingly > >half or full duplex ? > Unknown... (sorry not an openal master ...yet...). I can ask the dev working on OpenAL about these types of things. >> >>The OpenAL api is rather simple >>- For playback : you make buffers and queue them then poll them (to find >>out when they are done) >> There are some extensions that cut out >>copies/support eax/... (I have not looked at em yet) >> (support 2d and 3d audio) > >hmm that's what we said for Alsa... 3 years later quality is still not >there :-/ > Hehe -- I had no knowledge of this (just learned oss, alsa and openal existed like 3 weeks ago) >>- For recording (1.1 only) : start capturing -- poll (get data -- if >>there) -- stop recording > > >> >>The dsound mapping stuff I want to understand better (are there any docs >>for this?) >>I am sure we can layer it on OpenAL (hopefully good) > >I doubt it for direct HW mapping (HEL should be fine). Unfortunately, no >doc. > Hmm... Is there a way I can request some docs (or is the source code + msdn the doc)? >> >>PortAudio looks like a good choice as well -- afaict -- but I dont have >>any exp with it (not that I had any openal exp when i started that driver >>hehe) >> >The whole point here is that OpenAL doesn't bring much to the picture >(apart perhaps from a portability perspective, but it's still overkill). >A+ > I would not say overkill (well maybe for linux its overkill but....) Mac OSX only has JACK(does not work atm), ESD(...slow), and now CoreAudio(crashs in winecfg -- does play games -- but has ... static) drivers CoreAudio is the only one that can show any decent performance -- and its not really very... Portable OpenAL can show good performance on Mac OSX and other platforms (so others can test things and stuff -- even under windows) I am not saying that OpenAL should be the catch-all sound driver -- but its nice to have an alternative (that I can play GTA3 with -- although i suggest not playing with a trackpad) You can take a look at my driver (posted to this list -- and its in the archive at http://www.winehq.org/pipermail/wine-devel/2006-June/048273.html) It is heavily based on the esd driver (my starting point). Which was heavily based off of arts/alsa... - Nick

June 6, 2006

Re: Linux noob

by Molle Bestefich

Neil Skrypuch wrote: > I can't say I've ever seen that. What apps in particular? Can't remember offhand. I was annoyed enough by it to create the symlink at one point. > Both the standard Qt open file dialog and the Gtk open file dialog work fine > with . directories for me, which doesn't leave many apps that could not > work. No, that's not true.. The behaviour of the dialogs depend on the app somehow. AFAIR, I've seen Qt dialogs activate the .wine folder as a selection or cancel the dialog instead of descending into it, and Gtk dialogs completely unable to display hidden folders. But I've also seen that some Qt apps work fine. Sorry I can't provide any more details, it's not like I make a habit of remembering this stuff :-). (... And it still wasn't my main point, either ;-).)

June 6, 2006

Re: Linux noob

by Neil Skrypuch

On Tuesday, June 06, 2006 17:53, Molle Bestefich wrote: > Neil Skrypuch wrote: > > You can always type .wine in to access it, even if it isn't visible. > > No. Some apps break when you do that. > Either they don't access the folder correctly, or they close or > activate the selection dialog. I can't say I've ever seen that. What apps in particular? Both the standard Qt open file dialog and the Gtk open file dialog work fine with . directories for me, which doesn't leave many apps that could not work. - Neil

June 6, 2006

Re: Linux noob

by Neil Skrypuch

On Tuesday, June 06, 2006 17:53, Molle Bestefich wrote: > Neil Skrypuch wrote: > > You can always type .wine in to access it, even if it isn't visible. > > No. Some apps break when you do that. > Either they don't access the folder correctly, or they close or > activate the selection dialog. I can't say I've ever seen that before. What apps in particular? It certainly works with the standard Qt and Gtk open file dialogs. - Neil

June 6, 2006

Re: D3D9: Add a test for setting / getting vertex shader constants

by Raphael

On Wednesday 07 June 2006 00:01, Ivan Gyurdiev wrote: > Raphael wrote: > > On Tuesday 06 June 2006 23:17, H. Verbeet wrote: > >> This is a test for Ivan's patch for shader constants > >> (http://source.winehq.org/git/?p=wine.git;a=commit;h=5f5969b3c5bd237277b > >>8f2 f1eaa4ddacce5fb63b) > >> > >> Changelog: > >> - Add a test for setting / getting vertex shader constants > > > > Simple testing :) > > Thanks for the test and bugfix - I'll submit some of my own, starting > with the mipmaps patch. > > > can you add border tests in future: > > > > hret = IDirect3DDevice9_SetVertexShaderConstantB(device_ptr, > > MAX_VSHADER_CONSTANTS - 4, bool_in, 4); > > > > hret = IDirect3DDevice9_SetVertexShaderConstantB(device_ptr, > > MAX_VSHADER_CONSTANTS - 2, bool_in, 4); > > > > I'm interested to see how windows handle that :) > > MAX_VSHADER_CONSTANTS is most likely the wrong border for boolean and > integer constants. > Shaders 3.0 support a max of 16 integer and 16 boolean constants [ so is > the limit the max for all shader versions? ] No, D3D8 need to support 96 float integers :) Regards, Raphael

June 6, 2006

Re: D3D9: Add a test for setting / getting vertex shader constants

by Ivan Gyurdiev

Raphael wrote: > On Tuesday 06 June 2006 23:17, H. Verbeet wrote: > >> This is a test for Ivan's patch for shader constants >> (http://source.winehq.org/git/?p=wine.git;a=commit;h=5f5969b3c5bd237277b8f2 >> f1eaa4ddacce5fb63b) >> >> Changelog: >> - Add a test for setting / getting vertex shader constants >> > > Simple testing :) > Thanks for the test and bugfix - I'll submit some of my own, starting with the mipmaps patch. > can you add border tests in future: > > hret = IDirect3DDevice9_SetVertexShaderConstantB(device_ptr, > MAX_VSHADER_CONSTANTS - 4, bool_in, 4); > > hret = IDirect3DDevice9_SetVertexShaderConstantB(device_ptr, > MAX_VSHADER_CONSTANTS - 2, bool_in, 4); > > I'm interested to see how windows handle that :) > MAX_VSHADER_CONSTANTS is most likely the wrong border for boolean and integer constants. Shaders 3.0 support a max of 16 integer and 16 boolean constants [ so is the limit the max for all shader versions? ]

June 6, 2006

Re: acad 2004 license file bug

by Jaap Stolk

On 6/6/06, Mike Hearn <mike(a)plan99.net> wrote: > Mike doesn't have AutoCad so it may not be fixed. The problem must lie > elsewhere. Native MSI can be installed if you use Win98 mode, or you could > try debugging Wines own MSI implementation. I don't think autocad 2004 runs in win98, and I would prefer to debug Wines own MSI. (I don't particularly need to run the program, I would just like to add support for it to wine.) > > Should I try the suggested "fix": copy the bin/acadfeui/eula directory > > from the cd-rom to the c:\ root ? > > Sure, why not, it may work. Didn't work in my case for some reason. anyway, I removed winetools, so I'm back to the IE6 error (even before I get to the eula). On 6/6/06, Mike Hearn <mike(a)plan99.net> wrote: > You want > > WINEDEBUG=+reg wine setup.exe 2>/tmp/log Thanks! Can someone add +reg to http://winehq.org/site/developer-cheatsheet ? The installer seems to only read this key: SOFTWARE/Microsoft/Internet Explorer/Version (and also this one) Machine/Software/Classes/AcroExch.Document/AcrobatVersion I have manually set the Internet Explorer Version key, but that doesn't seem to fool the installer. Oddly, it reads these keys just before I press the "install" button. I will look into it tomorrow.

June 6, 2006

Re: Linux noob

by Molle Bestefich

Molle Bestefich wrote: > No. Some apps break when you do that. > Either they don't access the folder correctly, or they close or > activate the selection dialog. The symlink workaround works fine though. My main argument was that hidden folders is an ugly workaround for bad directory structure.

June 6, 2006

Re: Linux noob

by Molle Bestefich

Neil Skrypuch wrote: > You can always type .wine in to access it, even if it isn't visible. No. Some apps break when you do that. Either they don't access the folder correctly, or they close or activate the selection dialog.

June 6, 2006

Re: D3D9: Add a test for setting / getting vertex shader constants

by H. Verbeet

On 06/06/06, Raphael <fenix(a)club-internet.fr> wrote: > Simple testing :) > > can you add border tests in future: > > hret = IDirect3DDevice9_SetVertexShaderConstantB(device_ptr, > MAX_VSHADER_CONSTANTS - 4, bool_in, 4); > > hret = IDirect3DDevice9_SetVertexShaderConstantB(device_ptr, > MAX_VSHADER_CONSTANTS - 2, bool_in, 4); > > I'm interested to see how windows handle that :) Sure. This test is only for checking if the values don't get overwritten though, so we want to use safe indices here :-)

June 6, 2006

Re: Linux noob

by Neil Skrypuch

On Tuesday, June 06, 2006 13:42, Molle Bestefich wrote: > I'm annoyed that .wine is inaccessible through KDE and Gnome apps. You can always type .wine in to access it, even if it isn't visible. - Neil

June 6, 2006

Re: D3D9: Add a test for setting / getting vertex shader constants

by Raphael

On Tuesday 06 June 2006 23:17, H. Verbeet wrote: > This is a test for Ivan's patch for shader constants > (http://source.winehq.org/git/?p=wine.git;a=commit;h=5f5969b3c5bd237277b8f2 >f1eaa4ddacce5fb63b) > > Changelog: > - Add a test for setting / getting vertex shader constants Simple testing :) can you add border tests in future: hret = IDirect3DDevice9_SetVertexShaderConstantB(device_ptr, MAX_VSHADER_CONSTANTS - 4, bool_in, 4); hret = IDirect3DDevice9_SetVertexShaderConstantB(device_ptr, MAX_VSHADER_CONSTANTS - 2, bool_in, 4); I'm interested to see how windows handle that :) Regards, Raphael

June 6, 2006

Re: Prospects of an OpenAL audio driver...

by Eric Pouech

Nick Burns wrote: > OpenAL 1.1 supports recording... (1.0 does not have recording so that > is a problem yes) > -- My driver handles this atm -- it checks for recording capabilities > and supports accordingly half or full duplex ? > > The OpenAL api is rather simple > - For playback : you make buffers and queue them then poll them (to > find out when they are done) > There are some extensions that cut out > copies/support eax/... (I have not looked at em yet) > (support 2d and 3d audio) hmm that's what we said for Alsa... 3 years later quality is still not there :-/ > - For recording (1.1 only) : start capturing -- poll (get data -- if > there) -- stop recording > > The dsound mapping stuff I want to understand better (are there any > docs for this?) > I am sure we can layer it on OpenAL (hopefully good) I doubt it for direct HW mapping (HEL should be fine). Unfortunately, no doc. > > PortAudio looks like a good choice as well -- afaict -- but I dont > have any exp with it (not that I had any openal exp when i started > that driver hehe) > The whole point here is that OpenAL doesn't bring much to the picture (apart perhaps from a portability perspective, but it's still overkill). A+

June 6, 2006

Re: winedbg - setting breakpoint

by Eric Pouech

Stephen Clark wrote: > Hello List, > > I am trying to get classic Myst to run again under wine. How do I set > a breakpoint in it > when it run by winevdm. > > Thanks, > Steve > the answer depends on several aspects: - setting a breakpoint on wine code: that should work wine (especially for all DLLs, 16 or 32 bit) - setting a breakpoint in Myst code. Since it runs in winevdm, I assume it's a 16 bit exec. Symbolic information and other advanced debugging stuff (DLL loading event...) is not supported. The only thing you can do is set a breakpoint by address. It should work when expressed as a segmented address (bp 0x1234:0x5678). HTH A+

June 6, 2006

Re: Feedback requested for Mac OSX x86 stack patch

by Alexandre Julliard

"Nick Burns" <adger44(a)hotmail.com> writes: > Ok so that makes more sense about MSVCRT -- but if it is using cdecl -- > shouldnt that use WINAPIV? CDECL would be more appropriate. > I did not see anything forcing a cdecl calling convention (other than > the spec file). And I dunno how to modify the spec file to add in more > attribs. cdecl is the default, that's why it's not specified. > So, should I finish this patch (e.g. catch every single callable > function and put the attrib on it) > Or, should I send the simple 99% patch first for WINAPI/WINAPIV > (removing meaningless redefs) -- I would probably ignore msvcrt for > the first patch Eventually of course we have to catch every function, but redefining WINAPI is already a good start. -- Alexandre Julliard julliard(a)winehq.org

June 6, 2006

Re: msi: Fix some copy/paste bugs in the implementationof condition operators.

by Mike Hearn

On 6/6/06, EA Durbin <ead1234(a)hotmail.com> wrote: > I've decided to concentrate my efforts in another area, so I won't be > looking at msi any longer. I admit I 'm no C expert, I'm a web developer by > trade. Though I started to look at the C code to get away from php/perl/ruby > and get aquainted with the language in my leisure time, I need no assitance > with web development. As I would still like to contribute to the wine > project I will be focusing my efforts on Appdb and Bugzilla. Well, that's great too but I don't want to see you give up! :) I know this particular adventure hasn't gone quite right but there's plenty of areas you can contribute. When I started I was no C expert either but it's a simple language and can be quickly learned. Often this happens, you debug something to find that it's in an area not many people can work on. If you want my advice, it'd be to just try your hand at debugging random apps. Find one that doesn't work, poke it a bit to find out why not, if you aren't getting anywhere throw it away and move onto the next. This lets you see a lot of the code quickly, and you'll probably find that some bugs are much easier to fix than the one you found. thanks -mike

June 6, 2006

Re: Feedback requested for Mac OSX x86 stack patch

by Nick Burns

Ok so that makes more sense about MSVCRT -- but if it is using cdecl -- shouldnt that use WINAPIV? I did not see anything forcing a cdecl calling convention (other than the spec file). And I dunno how to modify the spec file to add in more attribs. I have not used winapi_check before -- I can check that then. So, should I finish this patch (e.g. catch every single callable function and put the attrib on it) Or, should I send the simple 99% patch first for WINAPI/WINAPIV (removing meaningless redefs) -- I would probably ignore msvcrt for the first patch (I dunno when I will have time to reform msvcrt for a full patch) >Date: Tue, 06 Jun 2006 12:14:47 +0200 > >"Nick Burns" <adger44(a)hotmail.com> writes: > > > I was concerned about msvcrt not using the __stdcall/WINAPI for its > > functions (why is this?). > >Most msvcrt functions use the cdecl calling convention, not stdcall. > > > Where can I find a list of (or affect the attribs of) windows callable > > functions. > > I thought WINAPI and WINAPIV were sufficent -- If they are not more > > functions will need to be 'fixed'. > >They should be 99% sufficient, but of course the remaining 1% will be >fun to chase down. There's no complete list, though maybe winapi_check >could be used to verify these things, at least for functions exported >from the spec files. > >-- >Alexandre Julliard >julliard(a)winehq.org - Nick

June 6, 2006

Re: wined3d: Another GLSL shader status update

by Jason Green

On 6/6/06, Jason Green <jave27(a)gmail.com> wrote: > I'll add a section to the DirectX-Shaders wiki page with an > explanation soon, as well as make the comments in the source code more > verbose (and/or link to the wiki where applicable). FYI - I just added a bunch to this page to get us started: http://wiki.winehq.org/DirectX-Shaders

June 6, 2006

Re: Linux noob

by Molle Bestefich

Peter Beutner wrote: > Because it is the defacto standard to store settings > under ~/.<appname>. Only for stuff that's thought to be generally uninteresting. Your KDE desktop, for example, resides under ~/Desktop. > And with enough applications installed that use this "standard" > you probably will be glad that these directories are hidden so that > you don't have to scroll through them every time you open > your filemanager ;). I'm annoyed that .wine is inaccessible through KDE and Gnome apps. Not through the file manager, but often in various applications. It's not wine's fault per se that those apps lack a "show hidden folders" option, but it would be nice to make wine visible, as it contains useful stuff that you'll often mangle with. (I personally have a symlink from "wine" to ".wine"...) I do agree that there's too many applications dumping various .xxxxxx folders in my home directory. The least they could do is to put those files somewhere where they don't interfere with my user data, someplace sane like ~/Application Data/xxxxxx, or a more unixy ~/appdata/xxxxx... (Never cared much for hidden folders - they're a symptom that you're being too careless with your directory structure.)

June 6, 2006

Re: wined3d: Another GLSL shader status update

by Jason Green

On 6/6/06, Mike Hearn <mike(a)plan99.net> wrote: > On Sun, 04 Jun 2006 12:04:21 -0400, Jason Green wrote: > Re: the recent discussion on code commenting and documentation, it'd be > nice if the patch explained this somewhere. It'd be even nicer still if at > some point one of you guys could take a break from the codeface and write > a chapter for the Wine Developer Guide on shaders and how all this works Yep, that is all planned before I submit any of the new real work to wine-patches. I'm still trying to figure out exactly where some of this stuff needs to go and what pitfalls we'll be up against. Should make it easier for Alexandre so he doesn't have to apply 800 patches / month of us moving stuff around after the fact. :-) I'll add a section to the DirectX-Shaders wiki page with an explanation soon, as well as make the comments in the source code more verbose (and/or link to the wiki where applicable).

June 6, 2006

re: Hal and functions in setupapi

by Dan Kegel

Christian wrote: > as I want to programm RegisterDeviceNotification also we > need a central way to handle hal stuff. > > So how should I go on? Use some own hal.c in setupapi or > add an global wine way to interact with hal? I think programs/explorer already registers for device notification with hal. You should look at that before you go on. - Dan -- Wine for Windows ISVs: http://kegel.com/wine/isv

June 6, 2006

Re: lstrlen(A/W) patch

by Mike McCormack

Clinton Stimpson wrote: > The following patch will fix the crash. > MSDN documentation says "*lstrlen* assumes that /lpString/ is a > null-terminated string, or NULL" The inline lstrlenW is used only internally by Wine code, and we want it to crash when passed a NULL pointer. In this case, you should fix the Wine code calling lstrlenW to not use a NULL pointer. Mike

June 6, 2006

Re: msi: Fix some copy/paste bugs in the implementation of condition operators.

by Jakob Eriksson

EA Durbin wrote: > Okay what am i misunderstanding?, explain it to me as its imperative I > learn, and I'd love to learn. > > %u is an unsigned integer which is 0 to +32,767. %u is an unsigned integer which is 0 to +65535. > > %i is a signed integer –32,767 to +32,767. %i is a signed integer -32768 to +32767.

June 6, 2006

Re: APPDB patch

by Tony Lambregts

EA Durbin wrote: > fixed typographical errors. > > > ------------------------------------------------------------------------ > > ? patch.diff > Index: TODO > =================================================================== > RCS file: /home/wine/appdb/TODO,v > retrieving revision 1.22 > diff -u -p -r1.22 TODO > --- TODO 12 Jun 2005 02:50:18 -0000 1.22 > +++ TODO 6 Jun 2006 02:19:34 -0000 > @@ -7,7 +7,7 @@ WineHQ Application Database TODO List > AppDB Todo: > > * Improve application/version submission process > - Currently a user submits an application/version and a admin reviews it and > + Currently a user submits an application/version and an admin reviews it and > either makes changes to it and accepts it or writes a comment and rejects it. Upon > rejection the submission is deleted > > There is no sense in keeping our todos in two places. We should probabably just point to the wiki in this file. http://wiki.winehq.org/AppdbInfo Tony Lambregts

June 6, 2006

Hal and functions in setupapi

by Christian Gmeiner

Hi all... at the momemt i am reading into functions to get some informations about e.g. cdrom drives. At the moment i am loking into SetupDiGetClassDevsW to support GUID_DEVINTERFACE_CDROM and later USB devices. My overall goal is it to get Line 6 software for my guitart effect board (USB) working with wine. Now i thought about a way to get all informations about a singe cdrom device. And i thought that I could use HAL perfectly for this. I thought about this way of doing it: Add hal.c file to setupapi dll, which contains function to get infromations about all needed hardware. This should work very nicly for this case. But as I want to programm RegisterDeviceNotification also we need a central way to handle hal stuff. So how should I go on? Use some own hal.c in setupapi or add an global wine way to interact with hal? Thanks, Christian

June 6, 2006

Re: lstrlen(A/W) patch

by Andreas Mohr

Hi, On Mon, Jun 05, 2006 at 09:24:24PM -0600, Clinton Stimpson wrote: > > I encountered a crash when using PAF 5.2. > > The following patch will fix the crash. > MSDN documentation says "*lstrlen* assumes that /lpString/ is a > null-terminated string, or NULL" MSDN documentation says many things... most of them wrong. ;-) (only slightly exaggerated, given Wine's experience with MSDN "correctness" over the years) IOW, I severely doubt that this is indeed the way Windows behaves, otherwise it'd have been fixed in Wine a long time ago already since apps would rely on and fully expect this behaviour of such a central and important function. Most likely you encountered application misbehaviour (feeding a NULL parameter to a function expecting non-NULL) due to a different Wine bug which thus caused the app to mis-step. Would be interesting to figure out why this happened (e.g. via +relay trace). Andreas Mohr

June 6, 2006

Wine updated in Fedora Extras!

by Neal Gompa

Wine has been updated to 0.9.14 on May 30, 2006! So, this release took 6 days... Still, generally 3-5 days is pretty good estimation...

June 6, 2006

Re: winedbg: remove unneeded states from grammar (take 2)

by Juan Lang

--- Alexandre Julliard <julliard(a)winehq.org> wrote: > Won't that make it impossible to use command keywords as identifiers > in commands that accept them, like disass? Come to think of it, your > previous NOCMD patch probably has the same issue. Hm. I expected not, because of the ASTRING_EXPECTED state. But I think you're right. Please revert those patches then, with my apologies. --Juan __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com

June 6, 2006

Re: acad 2004 license file bug

by Jonathan Ernst

Le mardi 06 juin 2006 à 13:03 +0100, Mike Hearn a écrit : > On Tue, 06 Jun 2006 12:36:07 +0100, Mike Hearn wrote: > > Right now we don't set the registry key saying we have IE installed, even > > though many of the DLLs the app probably needs are there and functioning > > correctly. I think the plan is to add this reg key after the last of > > Jaceks IE work is merged but only the big J himself could comment on that. > > Specifically I can't figure out if we're supposed to install a > Windows gecko based product or if it can use my native Linux Firefox ... As I said in wine-user, you don't need mozilla, but the Mozilla ActiveX control : http://source.winehq.org/mozactivex I don't know why shdocvw doesn't prompt the user to install it in this case though. At least it used to prompt the user and download the Mozilla ActiveX control when needed by other apps before. Best regards. Jonathan Ernst

June 6, 2006

Re: msi: Fix some copy/paste bugs in the implementationof condition operators.

by EA Durbin

>On Mon, 05 Jun 2006 10:14:50 -0600, Vitaliy Margolen wrote: > > So until you show us some code that verifies what you are talking about, > > please stay away from the e-mail clinet. > >He has done exactly that though not in a form we can put in the test >suite, and he is not "flaming" anybody. I think you need to calm down a >bit. > >thanks -mike I've decided to concentrate my efforts in another area, so I won't be looking at msi any longer. I admit I 'm no C expert, I'm a web developer by trade. Though I started to look at the C code to get away from php/perl/ruby and get aquainted with the language in my leisure time, I need no assitance with web development. As I would still like to contribute to the wine project I will be focusing my efforts on Appdb and Bugzilla. But thanks for understanding my intentions Mike.

June 6, 2006

Re: Re: wined3d: Another GLSL shader status update

by fenix＠club-internet.fr

----Message d'origine---- >A: wine-devel(a)winehq.com >De: Mike Hearn <mike(a)plan99.net> >Date: Tue, 06 Jun 2006 12:31:06 +0100 >Sujet: Re: wined3d: Another GLSL shader status update > >On Sun, 04 Jun 2006 12:04:21 -0400, Jason Green wrote: >> > This is an elaborate scheme with linked lists in each shader - is that >> > really necessary? >> > I'm very confused after reading the code (but maybe that's just me :) >> >> If we link the programs together every time the Set__Shader() is called, >> it brings performance to a halt (that what my glsl_hack4.diff did). > >Re: the recent discussion on code commenting and documentation, it'd be >nice if the patch explained this somewhere. It'd be even nicer still if at >some point one of you guys could take a break from the codeface and write >a chapter for the Wine Developer Guide on shaders and how all this works >... it seems incredibly opaque and the last thing we want is a re-run of >the DCOM situation where the only people who understood it left or hacked >on other things for a while and we lost the knowledge of how it worked. I Aggree that adding more comments about current architecture (at least on http://wiki.winehq.com/DirectX-Shaders and http://wiki.winehq.com/WineD3D) can help to better understand for non-d3d introduced wine hackers :) I was the first who delivered that code and it's my fault for the initial poor comments about architecture (who was understandable for opengl/directx hackers). We'll try to improve it (maybe beginning with "WineD3D for dummies" :) ) Anyway we are many who understand this code (and reviewing the flood of wined3d patches) so "DCOM situation" cannot happen :) >thanks -mike Regards, Raphael

June 6, 2006

Re: Re: [WINED3D 5/5] Remove constant type field in stateblock.

by fenix＠club-internet.fr

----Message d'origine---- >Date: Tue, 06 Jun 2006 04:54:17 -0400 >De: Ivan Gyurdiev <ivg2(a)cornell.edu> >A: fenix(a)club-internet.fr >Copie à: wine-devel(a)winehq.org >Sujet: Re: [WINED3D 5/5] Remove constant type field in stateblock. > >Hi Raphael, > >Strange, your email shows up as an attachment. Yes it's my webmail who have strange behaviors :( > > + int i, cnt = min(count, MAX_VSHADER_CONSTANTS - (start > > + 1)); > > should be: > > if (start > MAX_VSHADER_CONSTANTS - 1) return WINED3DERR_INVALIDCALL; > > UINT i, cnt = min(count, MAX_VSHADER_CONSTANTS - (start + 1)); > > > as count and start are UINT (better to avoid ugliy > > unsigned/signed bugs). > >The current code checks if cnt < 0 later on. Yes but it was buggy :) MAX_VSHADER_CONSTANTS - (start + 1) can result on an unsigned overflow > > Anyway what windows do if (start + count > > > MAX_VSHADER_CONSTANTS) ? > > The code seems handle this case truncating the input > >It's possible that this is buggy [ I always thought it was off by one ], >or not handling this case properly. However, I've just copied the code >that was already there - unrolled the existing SetConstant function into >its callers, and made the change I was interested in. Fixing other bugs >would go into a separate patch. Ok, fine for me Waiting for more patches to review :) I'm really waiting to get my new GC to test last impressive work on shaders. Regards, Raphael

June 6, 2006

Re: To K&R or not

by Christoph Frick

On Sun, Jun 04, 2006 at 02:12:15AM -0500, EA Durbin wrote: > One could just write a perl script to parse the code upon submission > that would convert it from K & R style to a uniform standard that it > easy to read, and fix things like the amount of spaces in an indent. just use indent(1) - the tool that was made for that purpose. beside that i just write my patches the way i want them and then indent them either within the editor (vim) or using ident automatically. this way the you dont have to deal with insane things like 2-space-indenting (;P) while working with the file. for the patch you can also use ``cvs diff -uwbB'' so no spaces you changed while editing in code by others are recognized and the patch only contains your _real_ changes. -- cu

June 6, 2006

Re: acad 2004 license file bug

by Mike Hearn

On Tue, 06 Jun 2006 12:36:07 +0100, Mike Hearn wrote: > Right now we don't set the registry key saying we have IE installed, even > though many of the DLLs the app probably needs are there and functioning > correctly. I think the plan is to add this reg key after the last of > Jaceks IE work is merged but only the big J himself could comment on that. Specifically I can't figure out if we're supposed to install a Windows gecko based product or if it can use my native Linux Firefox ...

June 6, 2006

Re: Re: Linux noob

by Mike Hearn

On Tue, 06 Jun 2006 03:27:52 +0000, NikNot wrote: > Indeed! This is something that I found infuriating since I first > used wine. What possible reason would there be to make this > a "hidden" directory? From whom exactly should it be hidden > and why? Historical reasons. I'm switching this thread to wine-devel as TransGaming do in fact make the virtual C drive visible by default and it's maybe something we should do too. On the other hand, it might just be wallpapering over other usability problems (lack of menu integration, most obviously). How often does average jack need to go poking around C:\Program Files in real Windows? thanks -mike

June 6, 2006

Re: msi: Fix some copy/paste bugs in the implementation of condition operators.

by Mike Hearn

On Mon, 05 Jun 2006 10:14:50 -0600, Vitaliy Margolen wrote: > So until you show us some code that verifies what you are talking about, > please stay away from the e-mail clinet. He has done exactly that though not in a form we can put in the test suite, and he is not "flaming" anybody. I think you need to calm down a bit. thanks -mike

June 6, 2006

Re: acad 2004 license file bug

by Mike Hearn

On Mon, 05 Jun 2006 10:23:45 +0200, Jaap Stolk wrote: > Thanks. but it doesn't seem to fool autocad. I tried: > WINEDEBUG=+server wine setup.exe > ~/mywinelog.txt > but it still logs to stout and my system can't keep up with the scrolling. > Is there a way to watch just the registry read/write ? You want WINEDEBUG=+reg wine setup.exe 2>/tmp/log Note that you redirect stderr not stdout. thanks -mike

June 6, 2006

Re: acad 2004 license file bug

by Mike Hearn

On Sun, 04 Jun 2006 20:43:17 +0200, Jaap Stolk wrote: > The autocad installer indicated that I needed internet explorer 6.0, > so I installed that using winetools. (can wine fake internet explorer, > so i don't need to install the real thing?) Mostly yes, but that area of code is still being worked on quite heavily. We're supposed to be able to use Mozilla but last time I tried running "wine iexplore" it told me it couldn't load Gecko so I'm not sure what's going on there .... Right now we don't set the registry key saying we have IE installed, even though many of the DLLs the app probably needs are there and functioning correctly. I think the plan is to add this reg key after the last of Jaceks IE work is merged but only the big J himself could comment on that. > anyway, the autocad installer now complains that the licence file > could not be found, but this bug report indicates that this problem is > supposed to be fixed: Mike doesn't have AutoCad so it may not be fixed. The problem must lie elsewhere. Native MSI can be installed if you use Win98 mode, or you could try debugging Wines own MSI implementation. > Should I try the suggested "fix": copy the bin/acadfeui/eula directory > from the cd-rom to the c:\ root ? Sure, why not, it may work. thanks -mike

June 6, 2006

Re: DirectX blitter bug

by Mike Hearn

On Sun, 04 Jun 2006 02:51:31 +0200, Alexander Nicolaysen Sørnes wrote: > This is fixed in Stefan's ddraw patchset. Awesome :) I look forward to it being merged. thanks -mike

June 6, 2006

Re: wined3d: Another GLSL shader status update

by Mike Hearn

On Sun, 04 Jun 2006 12:04:21 -0400, Jason Green wrote: > > This is an elaborate scheme with linked lists in each shader - is that > > really necessary? > > I'm very confused after reading the code (but maybe that's just me :) > > If we link the programs together every time the Set__Shader() is called, > it brings performance to a halt (that what my glsl_hack4.diff did). Re: the recent discussion on code commenting and documentation, it'd be nice if the patch explained this somewhere. It'd be even nicer still if at some point one of you guys could take a break from the codeface and write a chapter for the Wine Developer Guide on shaders and how all this works ... it seems incredibly opaque and the last thing we want is a re-run of the DCOM situation where the only people who understood it left or hacked on other things for a while and we lost the knowledge of how it worked. thanks -mike

June 6, 2006

Re: Feedback requested for Mac OSX x86 stack patch

by Alexandre Julliard

"Nick Burns" <adger44(a)hotmail.com> writes: > I was concerned about msvcrt not using the __stdcall/WINAPI for its > functions (why is this?). Most msvcrt functions use the cdecl calling convention, not stdcall. > Where can I find a list of (or affect the attribs of) windows callable > functions. > I thought WINAPI and WINAPIV were sufficent -- If they are not more > functions will need to be 'fixed'. They should be 99% sufficient, but of course the remaining 1% will be fun to chase down. There's no complete list, though maybe winapi_check could be used to verify these things, at least for functions exported from the spec files. -- Alexandre Julliard julliard(a)winehq.org

June 6, 2006

Re: winedbg: remove unneeded states from grammar (take 2)

by Alexandre Julliard

Juan Lang <juan_lang(a)yahoo.com> writes: > Oops, last one had a missing brace. Sorry about that. > > ChangeLog: many states in the command-line parser were unnecessary, so > remove them Won't that make it impossible to use command keywords as identifiers in commands that accept them, like disass? Come to think of it, your previous NOCMD patch probably has the same issue. -- Alexandre Julliard julliard(a)winehq.org

June 6, 2006

Re: [WINED3D 5/5] Remove constant type field in stateblock.

by Ivan Gyurdiev

Hi Raphael, Strange, your email shows up as an attachment. > + int i, cnt = min(count, MAX_VSHADER_CONSTANTS - (start > + 1)); > should be: > if (start > MAX_VSHADER_CONSTANTS - 1) return WINED3DERR_INVALIDCALL; > UINT i, cnt = min(count, MAX_VSHADER_CONSTANTS - (start + 1)); > as count and start are UINT (better to avoid ugliy > unsigned/signed bugs). The current code checks if cnt < 0 later on. > Anyway what windows do if (start + count > > MAX_VSHADER_CONSTANTS) ? > The code seems handle this case truncating the input It's possible that this is buggy [ I always thought it was off by one ], or not handling this case properly. However, I've just copied the code that was already there - unrolled the existing SetConstant function into its callers, and made the change I was interested in. Fixing other bugs would go into a separate patch.

June 6, 2006

Re: [WINED3D 5/5] Remove constant type field in stateblock.

by fenix＠club-internet.fr

----Message d'origine---- >Date: Tue, 06 Jun 2006 02:46:59 -0400 >De: Ivan Gyurdiev <ivg2(a)cornell.edu> >A: wine patch <wine-patches(a)winehq.org> >Sujet: [WINED3D 5/5] Remove constant type field in stateblock. > >It is wrong to maintain a mapping from a constant index to a type field, >because different constant types do not share an index - boolean >constant 0 is supposed to co-exist with floating point constant 0, not >replace it. Drawprim and other code using the type array to decide >whether to look up a constant in bools, floats, or ints is wrong - you >can't make that decision based on the index. > >To do this: >========== >- split .set and .changed stateblock arrays for constants into >individual arrays for F, B, and I constants >- don't use shared SetConstant/GetConstant function in device.c, unroll >that into its callers, and make them use separate .set and .changed >arrays. Remove old SetConstant/GetConstant functions, not enough is >shared to justify them. Remove SetConstantN, it's not used anymore. >- change stateblock to not use the type array >- change drawprim to use the .set array, instead of a type array to >check if constants need to be loaded > Hi Ivan, just one comment: + int i, cnt = min(count, MAX_VSHADER_CONSTANTS - (start + 1)); should be: if (start > MAX_VSHADER_CONSTANTS - 1) return WINED3DERR_INVALIDCALL; UINT i, cnt = min(count, MAX_VSHADER_CONSTANTS - (start + 1)); as count and start are UINT (better to avoid ugliy unsigned/signed bugs). Anyway what windows do if (start + count > MAX_VSHADER_CONSTANTS) ? The code seems handle this case truncating the input Best Regards, Raphael

June 6, 2006

Re: winedbg: remove unneeded states from grammar

by Eric Pouech

I'm not sure they are unneeded. for example, with your changes, b down would be seen by the grammar as tBREAKPOINT tDOWN which is not what we want. A+ 2006/6/6, Juan Lang <juan_lang(a)yahoo.com>: > > ChangeLog: many states in the command-line parser were unnecessary, so > remove them > > --Juan > > __________________________________________________ > Do You Yahoo!? > Tired of spam? Yahoo! Mail has the best spam protection around > http://mail.yahoo.com > > > > > > -- Eric Pouech

June 6, 2006

Re: GetDIBits() with a bitmap that is selected in a device context

by Dmitry Timoshkov

"Michael Kaufmann" <hallo(a)michael-kaufmann.ch> wrote: >I have submitted new tests to wine-patches. Thanks. > @Dmitry: One of your bitmap tests triggers an assertion on Windows 9x. > Look here: http://test.winehq.org/data/200605161000/ That's strange. Although many tests fail here under Win98SE the test runs to the end without any assertion. -- Dmitry.

June 6, 2006

Re: Feedback requested for Mac OSX x86 stack patch

by Nick Burns

Thanks for the feedback... I look forward to windows apps not dieing a horrible death on Mac OSX I was concerned about msvcrt not using the __stdcall/WINAPI for its functions (why is this?). I am guessing the d3d8/d3d9 redefinitions should be removed? Where can I find a list of (or affect the attribs of) windows callable functions. I thought WINAPI and WINAPIV were sufficent -- If they are not more functions will need to be 'fixed'. >From: Alexandre Julliard <julliard(a)winehq.org> >Date: Mon, 05 Jun 2006 21:21:01 +0200 > >"Nick Burns" <adger44(a)hotmail.com> writes: > > > (notes are at the top of the patch) > > > > I would like some feedback on my stack fix patch > > > > I do not know how it interacts with linux -- no access to a linux box > > This has been confirmed to fix numerous app issues (due to stack >alignment) > > > > I am starting to think it would be better to have these options > > configured at config time > > -- e.g. > > If Mac OSX x86 -- then use mstackrealign + force_align_arg_pointer > > > > Any ideas/thoughts? > >It looks OK, but it will clearly need some cleaning up. The msvcrt >part should be done with function attributes too. The d3d8/d3d9 >redefinitions are probably no longer necessary and should be >removed. Also there are a number of functions that use __stdcall >instead of WINAPI, these would need to be changed. > >-- >Alexandre Julliard >julliard(a)winehq.org > - Nick

June 5, 2006

Re: oleaut32 [1/2]: Copy BYREF args directly if they have the same variant type [RESEND]

by Dan Kegel

On 6/5/06, James Hawkins <truiken(a)gmail.com> wrote: > There are two or three files that are generated, and until we compile > them ourselves, we should keep them in git, because we need some of > the files to compile the tests. Oh, right. Anyway, lzexpand/tests/lzexpand_main.c is an example of a golden file embedded in a .c file. And if that was ok, checking in your couple of files ought to be ok... -- Wine for Windows ISVs: http://kegel.com/wine/isv

June 5, 2006

Re: oleaut32 [1/2]: Copy BYREF args directly if they have the same variant type [RESEND]

by James Hawkins

On 6/5/06, Dan Kegel <dank(a)kegel.com> wrote: > On 6/5/06, James Hawkins <truiken(a)gmail.com> wrote: > > The test would require us to have an idl file compiled by widl. > > I bet that'd be ok, at least until our idl compiler shapes up. > How big is the output file? Maybe you could even embed it > inside the .c file if it's not too huge. > There are two or three files that are generated, and until we compile them ourselves, we should keep them in git, because we need some of the files to compile the tests. -- James Hawkins

June 5, 2006

Re: oleaut32 [1/2]: Copy BYREF args directly if they have the same variant type [RESEND]

by Dan Kegel

On 6/5/06, James Hawkins <truiken(a)gmail.com> wrote: > The test would require us to have an idl file compiled by widl. I bet that'd be ok, at least until our idl compiler shapes up. How big is the output file? Maybe you could even embed it inside the .c file if it's not too huge.

June 5, 2006

Re: oleaut32 [1/2]: Copy BYREF args directly if they have the same variant type [RESEND]

by James Hawkins

On 6/5/06, Dan Kegel <dank(a)kegel.com> wrote: > James wrote: > > Is there anything wrong with this patch? > > Well, it doesn't have a conformance test... The test would require us to have an idl file compiled by widl. The attached file is a part of the initial type marshalling tests written by Rob Shearman. The idl file can't be compiled by widl until many more features of widl are implemented. On 6/5/06, Robert Shearman <rob(a)codeweavers.com> wrote: > > Note: it's going to take a lot more work before widl can generate a > typelib from this IDL. There are unimplemented features blocking it, > like widl being unable to express pointers correctly and not being able > to process importlibs. > One option is to compile the idl with midl and add the resulting output files to git, but I don't know if Alexandre will accept this. -- James Hawkins

June 5, 2006

re: oleaut32 [1/2]: Copy BYREF args directly if they have the same variant type [RESEND]

by Dan Kegel

James wrote: > Is there anything wrong with this patch? Well, it doesn't have a conformance test... - Dan -- Wine for Windows ISVs: http://kegel.com/wine/isv

June 5, 2006

[Fwd: Re: msi patch submission - cond.y]

by Dominic Wise

I may be wrong, but I feel it might be useful for a naive outsider to enter this discussion, even if it does mean I get burnt to a crisp. I'm neither a Wine nor a parser developer (though I do have a few years C/++ experience) and fully accept that I may be flamed to a tiny cinder for my comments, but from what I can ascertain, cond.y is a composite file, containing C and bison code. As far as I can tell (not quite brave enough to say AFAICT) the file is first read by the bison processor, which reads the bison parser rules and C code and generates compilable files for the C compiler. Having read what bison is (I think) supposed to do, the tokens declared DO look is if they might be wrong [having looked up 'tilde' and MSI on Google, it looks as though COND_I* actually relates to strings, as it seems that the tilde means 'case insensitive', but I wonder if it has been inadvertently used on integer comparisons by some installers]. It also looks as if the tests in compare_int() for COND_LE and COND_ILE may be wrong, unless there is some kind of (uncommented) logic inversion somewhere. However, uppermost in my mind is Mike McCormack's statement that 'Unfortunately cond.y has nothing to do with SQL.'. If this is indeed the case then everything I have said amounts to nought because I have assumed (very likely incorrectly) that the parser code in cond.y, being part of the MSI dll, relates to the parsing of SQL statements in MSI. If this is the case I fully expect to burn in newbie-land, and apologise for my presumption. Torch me if you want. Just trying to help, and open the discussion :)

June 5, 2006

Re: msi patch submission - cond.y

by EA Durbin

>looked up 'tilde' and MSI on Google, it looks as though COND_I* actually >relates to strings, as it seems that the tilde means 'case insensitive', >but I wonder if it has been inadvertently used on integer comparisons by >some installers]. Coming from perl, I though the tilde was part of a regex at first. ~>= being similar to COND_ILE =~ m/>=/

June 5, 2006

Re: msi patch submission - cond.y

by Dominic Wise

I may be wrong, but I feel it might be useful for a naive outsider to enter this discussion, even if it does mean I get burnt to a crisp. I'm neither a Wine nor a parser developer (though I do have 14 years C/++ experience) and fully accept that I may be flamed to a tiny cinder for my comments, but from what I can ascertain, cond.y is a composite file, containing C and bison code. As far as I can tell (not quite brave enough to say AFAICT) the file is first read by the bison processor, which reads the bison parser rules and C code and generates compilable files for the C compiler. Having read what bison is (I think) supposed to do, the tokens declared DO look is if they might be wrong [having looked up 'tilde' and MSI on Google, it looks as though COND_I* actually relates to strings, as it seems that the tilde means 'case insensitive', but I wonder if it has been inadvertently used on integer comparisons by some installers]. It also looks as if the tests in compare_int() for COND_LE and COND_ILE may be wrong, unless there is some kind of (uncommented) logic inversion somewhere. However, uppermost in my mind is Mike McCormack's statement that 'Unfortunately cond.y has nothing to do with SQL.'. If this is indeed the case then everything I have said amounts to nought because I have assumed (very likely incorrectly) that the parser code in cond.y, being part of the MSI dll, relates to the parsing of SQL statements in MSI. If this is the case I fully expect to burn in newbie-land, and apologise for my presumption. Torch me if you want. Just trying to help, and open the discussion :) On Mon, 2006-06-05 at 09:02 -0500, EA Durbin wrote: > Then what are the conditional statements in cond.y used for? Though they may > not be SQL errors, if IGE and ILEmeans IS Greater than or equal to, or Is > Less than or Equal to then it's still and error, even if it doesn't pertain > to SQL. > > Do these not mean IS Greater than or equal to, or Is Less than or Equal to ? > > > > >From: Mike McCormack <mike(a)codeweavers.com> > >To: wine-devel(a)winehq.org > >CC: ead1234(a)hotmail.com > >Subject: Re: msi patch submission - cond.y > >Date: Mon, 05 Jun 2006 22:43:09 +0900 > > > > > >EA Durbin wrote: > >>fixed various SQL errors in COND_GetOperator() and compare_int() > > > >Unfortunately cond.y has nothing to do with SQL. > > > >Mike > > > > >

June 5, 2006

Re: msi: Fix some copy/paste bugs in the implementation of condition operators.

by Joseph Garvin

EA Durbin wrote: > Okay what am i misunderstanding?, explain it to me as its imperative I > learn, and I'd love to learn. > > %u is an unsigned integer which is 0 to +32,767. > > > %i is a signed integer –32,767 to +32,767. > > If the sequence number is always going to be a positive number why > should we allot it the extra 32,767 value range? >From http://home.att.net/~jackklein/c/inttypes.html#int : "A signed int can hold all the values between *INT_MIN* and *INT_MAX* inclusive. *INT_MIN* is required to be -32767 or less, *INT_MAX* must be at least 32767. Again, many 2's complement implementations will define *INT_MIN* to be -32768 but this is not required. An unsigned int can hold all the values between 0 and *UINT_MAX * inclusive. *UINT_MAX* must be at least 65535. The int types must contain *at least* 16 bits to hold the required range of values. *NOTE:* /The required ranges for signed and unsigned int are identical to those for signed and unsigned short. On compilers for 8 and 16 bit processors (including Intel x86 processors executing in 16 bit mode, such as under MS-DOS), an int is usually 16 bits and has exactly the same representation as a short. On compilers for 32 bit and larger processors (including Intel x86 processors executing in 32 bit mode, such as Win32 or Linux) an int is usually 32 bits long and has exactly the same representation as a long."/ AFAIK, all signed and unsigned versions of the same type actually use the same number of bits, it's just that by using one of those bits as the 'sign' bit, the signed version seems to only be able to hold values half as big as the unsigned version (in fact, they're both capable of storing the same number of unique values, it's just that for the signed version half of the 65535 values are below zero). As a tip to remember this, consider for example an unsigned char. A char is just a byte, which is the smallest unit of memory most computers can address. An 'unsigned' char wouldn't yield any space savings because the minimum you can allocate at once is a byte anyway (in fact on most modern systems much larger than that, a page, but C is abstracted away from that). So unsigned/signed types must take up the same amount of memory. (we could concoct our own language where unsigned ints are actually shorts, but we'd be going out of our way)

June 5, 2006

Re: msi: Fix some copy/paste bugs in the implementation of condition operators.

by Neil Skrypuch

On Monday, June 05, 2006 12:58, EA Durbin wrote: > Okay what am i misunderstanding?, explain it to me as its imperative I > learn, and I'd love to learn. > > %u is an unsigned integer which is 0 to +32,767. > > > %i is a signed integer 32,767 to +32,767. > > If the sequence number is always going to be a positive number why should > we allot it the extra 32,767 value range? Not quite... neil(a)t40-n ~ $ cat >tmp.c <<EOF #include <stdint.h> #include <stdio.h> int main(void) { uint16_t i = -1; printf("%u\n", i); return 0; } EOF neil(a)t40-n ~ $ gcc tmp.c neil(a)t40-n ~ $ ./a.out 65535 neil(a)t40-n ~ $ if you inspect the memory that's at i, you'll find it's 0xffff. If you read it as signed, you interpret it using two's complement[1], if you read it as unsigned, you still use all the bits, but there's no sign bit*. [1] http://en.wikipedia.org/wiki/Two's_complement * Strictly speaking it's not a sign bit, but is frequently referred to as one anyways. - Neil

June 5, 2006

Re: GetDIBits() with a bitmap that is selected in a device context

by Michael Kaufmann

I have submitted new tests to wine-patches. @Dmitry: One of your bitmap tests triggers an assertion on Windows 9x. Look here: http://test.winehq.org/data/200605161000/ Regards, Michael Dmitry Timoshkov wrote: >> The application "Fritz 5.32" calls GetDIBits() with a bitmap that is >> still selected in a device context (see bug 3893). The bitmap has a >> color table. GetDIBits() creates a memory DC, selects the bitmap into >> this DC, and calls GetDIBColorTable(). But this fails, because Wine >> can't select this bitmap in a memory device context again. According >> to MSDN, calling GetDIBits with a bitmap that is selected in a device >> context is not allowed. But surprisingly it works on Windows. >> >> Does anybody have an idea how to solve this problem? > > A very first step should be to write a test case and integrate it > into the Wine GDI tests.

June 5, 2006

Re: msi: Fix some copy/paste bugs in the implementation of condition operators.

by Jonathan Ernst

Le lundi 05 juin 2006 à 14:01 -0500, EA Durbin a écrit : > > > >Vitaliy. > > > >PS: PLEASE PLEASE PLEASE ADD YOU COMMENTS BELOW THIS LINE NOT ABOVE. IT'S > >IMPOSSIBLE TO READ. > > > > > By default microsoft outlook, hotmail, all add their replies above the > previous message. It's the way 90% of the email I see works. > > Maybe that's because 90% of the people you know are using bad mail clients or are using bad settings. You'll see some reasons why top-posting is a bad thing(tm) here : http://catb.org/~esr/jargon/html/T/top-post.html Regards. Jonathan

June 5, 2006

Re: msi: Fix some copy/paste bugs in the implementation of condition operators.

by EA Durbin

Can you 100% guarantee that documentation is correct? And that there are no broken apps that will try to pass negative number? Vitaliy. Okay, i guess I see your point, but if the broken app passes a negative number its not going to work correctly anyway, as it will read from the wrong Disk medium when it encounters the query, once that works correctly.

June 5, 2006

Re: msi: Fix some copy/paste bugs in the implementation of condition operators.

by Vitaliy Margolen

Monday, June 5, 2006, 1:01:10 PM, EA Durbin wrote: >>Both of those depend on the type and not on what it "should be". >>And the type is INT it's a "signed int". > Why must it be a signed int, the comparison is always a positive number > which is an unsigned int. So if we always pass a positive number it should > still work correctly. No it will not work correctly. What if something _will_ pass a negative number? Then instead of having it as -1 you'll have 4294967295. Can you 100% guarantee that documentation is correct? And that there are no broken apps that will try to pass negative number? > Both types are integers, only the signed int requires 2 more bytes for the > sign. > > Aren't we wasting 2 bytes of memory by using signed int? Wrong. You need to read some c books. But sign uses only 1 bit, not 2 bytes. Vitaliy.

June 5, 2006

Re: msi: Fix some copy/paste bugs in the implementation of condition operators.

by Detlef Riekenberg

Am Montag, den 05.06.2006, 14:01 -0500 schrieb EA Durbin: > >And the type is INT it's a "signed int". > Why must it be a signed int, Welcome to the World of Microsoft. Another Example from MS: A Function is declared to return a BOOL and documented to return '0', '1' or '2' We are Compatible, so our Declaration is also a BOOL. -- By By ... ... Detlef

June 5, 2006

Re: Feedback requested for Mac OSX x86 stack patch

by Alexandre Julliard

"Nick Burns" <adger44(a)hotmail.com> writes: > (notes are at the top of the patch) > > I would like some feedback on my stack fix patch > > I do not know how it interacts with linux -- no access to a linux box > This has been confirmed to fix numerous app issues (due to stack alignment) > > I am starting to think it would be better to have these options > configured at config time > -- e.g. > If Mac OSX x86 -- then use mstackrealign + force_align_arg_pointer > > Any ideas/thoughts? It looks OK, but it will clearly need some cleaning up. The msvcrt part should be done with function attributes too. The d3d8/d3d9 redefinitions are probably no longer necessary and should be removed. Also there are a number of functions that use __stdcall instead of WINAPI, these would need to be changed. -- Alexandre Julliard julliard(a)winehq.org

June 5, 2006

Re: msi: Fix some copy/paste bugs in the implementation of condition operators.

by EA Durbin

> >Vitaliy. > >PS: PLEASE PLEASE PLEASE ADD YOU COMMENTS BELOW THIS LINE NOT ABOVE. IT'S >IMPOSSIBLE TO READ. > By default microsoft outlook, hotmail, all add their replies above the previous message. It's the way 90% of the email I see works. >Both of those depend on the type and not on what it "should be". >And the type is INT it's a "signed int". Why must it be a signed int, the comparison is always a positive number which is an unsigned int. So if we always pass a positive number it should still work correctly. Both types are integers, only the signed int requires 2 more bytes for the sign. Aren't we wasting 2 bytes of memory by using signed int?

June 5, 2006

Re: msi: Fix some copy/paste bugs in the implementation of condition operators.

by Vitaliy Margolen

Monday, June 5, 2006, 11:02:38 AM, EA Durbin wrote: > As Robert Shearman stated, why give it a 4 byte value when it's using a 2 > byte value. > The sequence should never be a negative number, where am I mistaken on this? Both of those depend on the type and not on what it "should be". And the type is INT it's a "signed int". Vitaliy. PS: PLEASE PLEASE PLEASE ADD YOU COMMENTS BELOW THIS LINE NOT ABOVE. IT'S IMPOSSIBLE TO READ.

June 5, 2006

winedbg - setting breakpoint

by Stephen Clark

Hello List, I am trying to get classic Myst to run again under wine. How do I set a breakpoint in it when it run by winevdm. Thanks, Steve -- "They that give up essential liberty to obtain temporary safety, deserve neither liberty nor safety." (Ben Franklin) "The course of history shows that as a government grows, liberty decreases." (Thomas Jefferson)

June 5, 2006

Re: msi: Fix some copy/paste bugs in the implementation of condition operators.

by EA Durbin

I'm not flaming, I'm trying to get assitance with the problem and sharing my findings with other developers. I openly admit im a novice C hacker, and could use some help which I thought was what the wine-devel mailing list was used for, as its for developers. As Robert Shearman stated, why give it a 4 byte value when it's using a 2 byte value. The sequence should never be a negative number, where am I mistaken on this? >From: Vitaliy Margolen <wine-devel(a)kievinfo.com> >Reply-To: wine-devel(a)winehq.org >To: "EA Durbin" <ead1234(a)hotmail.com> >CC: wine-devel(a)winehq.org >Subject: Re: msi: Fix some copy/paste bugs in the implementation of >condition operators. >Date: Mon, 5 Jun 2006 10:14:50 -0600 > >Why would you add all your findings and "test cases" into the Wine's test >suite? >Until then you should stop flaming list. With all the energy you spent >writing >these e-mails BACKWARDS as I might add.

June 5, 2006

Re: msi: Fix some copy/paste bugs in the implementation of condition operators.

by EA Durbin

Okay what am i misunderstanding?, explain it to me as its imperative I learn, and I'd love to learn. %u is an unsigned integer which is 0 to +32,767. %i is a signed integer 32,767 to +32,767. If the sequence number is always going to be a positive number why should we allot it the extra 32,767 value range? >From: Mike McCormack <mike(a)codeweavers.com> >To: EA Durbin <ead1234(a)hotmail.com> >CC: dank(a)kegel.com, wine-devel(a)winehq.org, hans(a)it.vu.nl >Subject: Re: msi: Fix some copy/paste bugs in the implementation of >condition operators. >Date: Tue, 06 Jun 2006 01:34:05 +0900 > > >EA Durbin wrote: >>It doesn't use %d currently. It uses %i. And its not to print. It uses >>this value in the SQL statement. The LastSequence value of the Media table >>is NEVER negative as i pointed out in the MSDN link. It must always be >>zero or larger and this is handled by passing %u. > >Unfortunately your lack of understanding of C lets you down here. > >Mike

June 5, 2006

Re: msi: Fix some copy/paste bugs in the implementation of condition operators.

by Robert Shearman

Mike McCormack wrote: > > EA Durbin wrote: > >> It doesn't use %d currently. It uses %i. And its not to print. It >> uses this value in the SQL statement. The LastSequence value of the >> Media table is NEVER negative as i pointed out in the MSDN link. It >> must always be zero or larger and this is handled by passing %u. > > > Unfortunately your lack of understanding of C lets you down here. Is there any guarantee that the value will be a 2-byte integer rather than a 4-byte integer? In that case, it will make a difference. BTW, I suspect that the America's Army problem is caused by the installer using a 4-byte integer in place of the usual 2-byte integer, which is parsed slightly differently. EA Durbin, if you want to test this theory you can instrument INT_evaluate in dlls/msi/where.c and dump the two values. -- Rob Shearman

June 5, 2006

Re: msi: Fix some copy/paste bugs in the implementation of condition operators.

by Mike McCormack

EA Durbin wrote: > It doesn't use %d currently. It uses %i. And its not to print. It uses > this value in the SQL statement. The LastSequence value of the Media > table is NEVER negative as i pointed out in the MSDN link. It must > always be zero or larger and this is handled by passing %u. Unfortunately your lack of understanding of C lets you down here. Mike

June 5, 2006

Re: Wine VM86 exception handling bug?

by Andrey Turkin

I used nasm and hiew. There is no point in adding additional tools dependencies. Anyway the test codes wouldn't be changed somehow often. And anyway I'm already submitted patch :) Detlef Riekenberg wrote: > Am Montag, den 05.06.2006, 11:58 +0100 schrieb Mike Hearn: >> On 6/5/06, Robert Shearman <rob(a)codeweavers.com> wrote: >>> It depends whether it's in a convenient form. For a 100-byte COM file, >>> it is probably already in its most convenient form. >> If, like Rob, you are an i386 ninja master who wields a disassembler >> as most of us wield a knife and fork then yes maybe :) For the rest of >> us source code can be occasionally convenient <chuckle> > > bin86 (BCC, together with as86 and ld86) might help wine. > > Bruce Evans C Compiler can create COM-Files > Updates are done by Robert de Bath > > Homepage: > http://freshmeat.net/redir/bin86/743/url_homepage/~mayday > > >

June 5, 2006

Re: msi: Fix some copy/paste bugs in the implementation of condition operators.

by Vitaliy Margolen

Why would you add all your findings and "test cases" into the Wine's test suite? Until then you should stop flaming list. With all the energy you spent writing these e-mails BACKWARDS as I might add. And you outright IGNORED my suggestions on the IRC chat room. So until you show us some code that verifies what you are talking about, please stay away from the e-mail clinet. Vitaliy. Monday, June 5, 2006, 10:05:39 AM, EA Durbin wrote: > It doesn't use %d currently. It uses %i. And its not to print. It uses this > value in the SQL statement. The LastSequence value of the Media table is > NEVER negative as i pointed out in the MSDN link. It must always be zero or > larger and this is handled by passing %u. > The SELECT * FROM `Media` WHERE `LastSequence` >= %i, should be The SELECT * > FROM `Media` WHERE `LastSequence` >= %u. In ready_media_for_files. >>From: Mike McCormack <mike(a)codeweavers.com> >>To: EA Durbin <ead1234(a)hotmail.com> >>CC: dank(a)kegel.com, wine-devel(a)winehq.org, hans(a)it.vu.nl >>Subject: Re: msi: Fix some copy/paste bugs in the implementation of >>condition operators. >>Date: Tue, 06 Jun 2006 00:38:16 +0900 >> >> >>EA Durbin wrote: >> >>>I did in fact write a test, which does prove this. Hans has a copy of it, >>>and i think i sent it to wine-devel too. >> >>I haven't seen any patch for the Wine regression test suite as yet, and >>that is what I have been asking you to write. >> >>>As for files.c, the query in ready_media_for_file() should be passing an >>>unsinged integer as LastSequence must be greater than zero. >> >>You patch is wrong because the value you are printing is an INT, so using >>%d is correct, and using %u will print the wrong thing when the INT is less >>than zero. >> >>Mike

June 5, 2006

Re: msi: Fix some copy/paste bugs in the implementation of condition operators.

by EA Durbin

It doesn't use %d currently. It uses %i. And its not to print. It uses this value in the SQL statement. The LastSequence value of the Media table is NEVER negative as i pointed out in the MSDN link. It must always be zero or larger and this is handled by passing %u. The SELECT * FROM `Media` WHERE `LastSequence` >= %i, should be The SELECT * FROM `Media` WHERE `LastSequence` >= %u. In ready_media_for_files. >From: Mike McCormack <mike(a)codeweavers.com> >To: EA Durbin <ead1234(a)hotmail.com> >CC: dank(a)kegel.com, wine-devel(a)winehq.org, hans(a)it.vu.nl >Subject: Re: msi: Fix some copy/paste bugs in the implementation of >condition operators. >Date: Tue, 06 Jun 2006 00:38:16 +0900 > > >EA Durbin wrote: > >>I did in fact write a test, which does prove this. Hans has a copy of it, >>and i think i sent it to wine-devel too. > >I haven't seen any patch for the Wine regression test suite as yet, and >that is what I have been asking you to write. > >>As for files.c, the query in ready_media_for_file() should be passing an >>unsinged integer as LastSequence must be greater than zero. > >You patch is wrong because the value you are printing is an INT, so using >%d is correct, and using %u will print the wrong thing when the INT is less >than zero. > >Mike

June 5, 2006

Re: msi: Fix some copy/paste bugs in the implementation of condition operators.

by Mike McCormack

EA Durbin wrote: > I did in fact write a test, which does prove this. Hans has a copy of > it, and i think i sent it to wine-devel too. I haven't seen any patch for the Wine regression test suite as yet, and that is what I have been asking you to write. > As for files.c, the query in ready_media_for_file() should be passing an > unsinged integer as LastSequence must be greater than zero. You patch is wrong because the value you are printing is an INT, so using %d is correct, and using %u will print the wrong thing when the INT is less than zero. Mike

June 5, 2006

Re: msi: Fix some copy/paste bugs in the implementation of condition operators.

by EA Durbin

My analysis has not changed it still remains the same to this day. Case, america's army installer is working backward, not going through the media in the correct order. Upon troubleshooting this I found that this is due to the query returning the wrong results for LastSequence. I don't have an analysis for what is causing this yet. But this is what is causing the bug and I've never swayed on that. I did in fact write a test, which does prove this. Hans has a copy of it, and i think i sent it to wine-devel too. As for files.c, the query in ready_media_for_file() should be passing an unsinged integer as LastSequence must be greater than zero. http://search.msdn.microsoft.com/search/Redirect.aspx?title=Media+Table+%5b… >less than or equal to the value in the LastSequence column, and greater than the LastSequence value of the previous disk (or greater than 0, for the first entry in the Media table). >From: Mike McCormack <mike(a)codeweavers.com> >To: EA Durbin <ead1234(a)hotmail.com> >CC: dank(a)kegel.com, wine-devel(a)winehq.org, hans(a)it.vu.nl >Subject: Re: msi: Fix some copy/paste bugs in the implementation of >condition operators. >Date: Tue, 06 Jun 2006 00:24:00 +0900 > > >EA Durbin wrote: > >>obviously my patch wasn't "wrong" as you so put it, as this is the same >>thing as the one I submitted. I just phrased the definition of it wrong >>assuming the conditional statements were used by SQL. > >Your patch caused the regression tests to fail, and Hans' did not. > >err:msi:msi_get_dialog_record query failed for dialog L"boo" >fixme:msi:ACTION_PerformUIAction unhandled msi action L"boo" >package.c:618: Test failed: wrong return val >make[1]: *** [package.ok] Error 1 > >You seem to have a different theory of what's causing the failure every >day. > >I'm somewhat disappointed that you refuse to write a regression test to >show what you've found. It would give me confidence in what your analysis >of the problem, assist me in fixing the problem, and prevent it from >happening again. > >Mike >

June 5, 2006

Re: msi: Fix some copy/paste bugs in the implementation of condition operators.

by Mike McCormack

EA Durbin wrote: > obviously my patch wasn't "wrong" as you so put it, as this is the same > thing as the one I submitted. I just phrased the definition of it wrong > assuming the conditional statements were used by SQL. Your patch caused the regression tests to fail, and Hans' did not. err:msi:msi_get_dialog_record query failed for dialog L"boo" fixme:msi:ACTION_PerformUIAction unhandled msi action L"boo" package.c:618: Test failed: wrong return val make[1]: *** [package.ok] Error 1 You seem to have a different theory of what's causing the failure every day. I'm somewhat disappointed that you refuse to write a regression test to show what you've found. It would give me confidence in what your analysis of the problem, assist me in fixing the problem, and prevent it from happening again. Mike

June 5, 2006

re: msi: Fix some copy/paste bugs in the implementation of condition operators.

by EA Durbin

obviously my patch wasn't "wrong" as you so put it, as this is the same thing as the one I submitted. I just phrased the definition of it wrong assuming the conditional statements were used by SQL. >From: "Dan Kegel" <dank(a)kegel.com> >To: wine-devel <wine-devel(a)winehq.org>, "Hans Leidekker" <hans(a)it.vu.nl> >CC: "EA Durbin" <ead1234(a)hotmail.com> >Subject: re: msi: Fix some copy/paste bugs in the implementation of >condition operators. >Date: Mon, 5 Jun 2006 08:07:17 -0700 > >Hans wrote: >>[http://www.winehq.org/pipermail/wine-cvs/2006-June/023395.html] >> Fix some copy/paste bugs in the implementation of condition operators. > >Congratulations on getting your patch into cvs! > >How far does this go towards fixing America's Army >(http://bugs.winehq.org/show_bug.cgi?id=5139)? > >Also, are you still working on a conformance test for this, >or did you stop once you found the obvious problem? >- Dan > > >-- >Wine for Windows ISVs: http://kegel.com/wine/isv

June 5, 2006

re: msi: Fix some copy/paste bugs in the implementation of condition operators.

by Dan Kegel

Hans wrote: > [http://www.winehq.org/pipermail/wine-cvs/2006-June/023395.html] > Fix some copy/paste bugs in the implementation of condition operators. Congratulations on getting your patch into cvs! How far does this go towards fixing America's Army (http://bugs.winehq.org/show_bug.cgi?id=5139)? Also, are you still working on a conformance test for this, or did you stop once you found the obvious problem? - Dan -- Wine for Windows ISVs: http://kegel.com/wine/isv

June 5, 2006