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

Re: getuname: add stub implementation [try 4]

by Dmitry Timoshkov

"Vitaly Lipatov" <lav(a)etersoft.ru> wrote: > Add WINE_PREATTACH and correct numer of params for GetUName > Try4: Export functions by name (@), fix warning in FIXME > > Changelog > add minimal implementation for getuname dll and GetUName function Just curious, what application besides charmap.exe uses getuname.dll? -- Dmitry.

June 10, 2006

Re: awwww

by Dan Kegel

On 6/10/06, Dan Kegel <dank(a)kegel.com> wrote: > If you want to see the bugs I consider high priority, > have a look at http://wiki.winehq.org/DanKegel > My top five app list is ... I forgot to mention: I also consider any installer bug a high priority bug. Installers Should Just Work. - Dan

June 10, 2006

kernel32.VerSetConditionMask present

by Vitaly Lipatov

VerSetConditionMask function is introduced in kernel32 science Windows 2000. Some broken applications check VerSetConditionMask present via GetProcAddress for check version of running Windows. What is the preferable method to disable export VerSetConditionMask from kernel32 when we have win98 version? -- Vitaly Lipatov, ALT Linux Team Russia, Saint-Petersburg, www.etersoft.ru

June 10, 2006

Re: awwww

by Dan Kegel

On 6/9/06, James Hawkins <truiken(a)gmail.com> wrote: > > If you is didn't understand, lots of bugs & problems that you > > raise are not as critical as you think they are. > > I don't really agree, but assuming that were true, this is an open > source project. You work on things you want to work on, fix bugs you > want to fix. Bugs are bugs, and no matter how small or irrelevant > they are to you, we shouldn't ignore them, and if they are small, then > we should be fixing them quicker. I do lots of random testing (e.g. by using Firefox on Wine) to try to understand what it's like to really rely on Wine, and as a result, I generate lots of bug reports that might seem odd to the casual observer. It may have been hard to tell from my post, but I installed this tool on a lark, and my post was meant to be tongue-in-cheeck. The bug report is real; something's funky with MSI. The app is obviously low priority, but I thought it was better to file it rather than just laugh. If you want to see the bugs I consider high priority, have a look at http://wiki.winehq.org/DanKegel My top five app list is * Visual Basic 6 and Visual C++ 6 (to make it easier for Windows ISVs to debug their code on Wine) * SPSS11 and Keeptool-Hora (because Munich chose those as apps to test under Wine for their Limux linux desktop conversion project) * iSBEM (http://www.ncm.bre.co.uk; uses Access 2000; the UK gov't requires building contractors to use this software, and it would be great PR for the Wine community to get this working well, I think.) Now how do you feel about my priorities? - Dan -- Wine for Windows ISVs: http://kegel.com/wine/isv

June 10, 2006

Re: svrapi: add stub implementation [try 2]

by Robert Shearman

Vitaly Lipatov wrote: >+1 stub NetAccessAdd >+2 stub NetAccessCheck >+3 stub NetAccessDel >+4 stub NetAccessEnum >+5 stub NetAccessGetInfo >+6 stub NetAccessGetUserPerms >+7 stub NetAccessSetInfo >+8 stub NetConnectionEnum >+9 stub NetFileClose2 >+10 stub NetFileEnum >+11 stub NetSecurityGetInfo >+12 stub NetServerGetInfo >+13 stub NetSessionDel >+14 stub NetSessionEnum >+15 stub NetSessionGetInfo >+16 stub NetShareAdd >+17 stub NetShareDel >+18 stdcall NetShareEnum(str long ptr long ptr ptr) >+19 stub NetShareGetInfo >+20 stub NetShareSetInfo > > These should all be just exported by name (@) not also by ordinal judging by the fact that they are in alphabetical order. -- Rob Shearman

June 10, 2006

Re: DDraw: New ddraw lib

by Stefan Dösinger

Am Samstag, 10. Juni 2006 01:40 schrieb Jesse Allen: > On 6/9/06, Stefan Dösinger <stefandoesinger(a)gmx.at> wrote: > > Hi, > > > > > I just want to state, the patch is very helpful when you can't use > > > DGA. I just ran a test with Starcraft in multiplayer last night. Using > > > OpenGL is noticibly faster than non-DGA. So I hope that it will get > > > applied for 0.9.16. > > > > Did you run it with opengl and this patch, or with Rodericks ddraw patch? > > I ran it with your patch. I'm not familiar with Rodericks patch. And it worked with SURFACE_OPENGL? Wow, I wasn't aware of that :-) All ddraw games I tried (aow2, anno 1602, worms2) failed with opengl surfaces.

June 10, 2006

Re: WineD3D: Fog fixes

by H. Verbeet

On 09/06/06, Jesse Allen <the3dfxdude(a)gmail.com> wrote: > This patch doesn't work with the latest fglrx saying missing symbol > for glFogCoordf. Mesa is ok though. Indeed, the patch should add the proper definitions to wined3d_gl.h and use GL_EXTCALL().

June 10, 2006

Re: awwww

by James Hawkins

On 6/10/06, Vitaliy Margolen <wine-devel(a)kievinfo.com> wrote: > > Don't you forgetting something? That something is windows. Do you really think > that being able to install that would help anything at all? > I'm not Dan, but I can still answer: yes. There's obviously a bug in msi that is keeping this utility from installing. If the bug gets fixed, then that's one less bug for another installer to stumble over. As we've seen with several installers recently, one bug can affect many apps. You're missing the point about why he wants to run this app. > How about working game installers? > > How about some newer copy protection systems that Wine could support (instead of NONE)? > > How about keeping things from breaking in favor of extra new features? > I don't know if you've noticed, but Dan has been getting on to everyone about adding regression tests even for simple fixes (which is a good thing :) > How about making number of things not 100% perfect, but closer to what they should be > instead of chasing that perfection? > This really isn't about perfection...it doesn't run at all, so at least letting it install is getting closer to what it should be. > > PS: > If you is didn't understand, lots of bugs & problems that you raise are not as critical > as you think they are. At least of bigger number of people. > I don't really agree, but assuming that were true, this is an open source project. You work on things you want to work on, fix bugs you want to fix. Bugs are bugs, and no matter how small or irrelevant they are to you, we shouldn't ignore them, and if they are small, then we should be fixing them quicker. -- James Hawkins

June 10, 2006

Re: awwww

by Vitaliy Margolen

Friday, June 9, 2006, 10:56:43 PM, Dan Kegel wrote: > Hey, I wanted to see if my computer could run Vista, but: > $ ~/wine/programs/msiexec/msiexec /i VistaUpgradeAdvisor.msi > fixme:msi:MsiInstallProductW L"VistaUpgradeAdvisor.msi" (null) > err:msidb:load_string_table string table corrupt? > err:msidb:load_string_table string table load failed! (000218f3 != 000047ef) > Filed as http://bugs.winehq.org/show_bug.cgi?id=5395 Don't you forgetting something? That something is windows. Do you really think that being able to install that would help anything at all? How about working game installers? How about some newer copy protection systems that Wine could support (instead of NONE)? How about keeping things from breaking in favor of extra new features? How about making number of things not 100% perfect, but closer to what they should be instead of chasing that perfection? PS: If you is didn't understand, lots of bugs & problems that you raise are not as critical as you think they are. At least of bigger number of people. Vitaliy

June 10, 2006

awwww

by Dan Kegel

Hey, I wanted to see if my computer could run Vista, but: $ ~/wine/programs/msiexec/msiexec /i VistaUpgradeAdvisor.msi fixme:msi:MsiInstallProductW L"VistaUpgradeAdvisor.msi" (null) err:msidb:load_string_table string table corrupt? err:msidb:load_string_table string table load failed! (000218f3 != 000047ef) Filed as http://bugs.winehq.org/show_bug.cgi?id=5395

June 9, 2006

Re: setupapi.dll: partially implement SetupDiGetClassDevsExA

by Mike McCormack

Peter Beutner wrote: >> For me, the main problem is that there are ReactOS developers who >> think that examining Windows assembly to write ReactOS code is a >> proper way to do things. > I think the problem is that the way you describe is totally legal in > most countries. > In fact, afaik it is only in the USA where you have this explicit > distinction between clean("chinese wall") and "dirty" reverse engineering. > Which reminds me of a similiar thread on lkml about which country's laws > actually applies This is not simply a problem of what is legal and not in different countries. We don't want to be associated project that is perceived to be pushing the edge of what's legally (or even socially) acceptable. Doing so would encourage FUD about Wine and that's a good way to lose developers and users. Furthermore, by examining and recoding somebody else's work, you neither gain a good understanding of how it works, nor lay the foundation for somebody else to fix it without repeating what you did. Using test cases to determine the behaviour of Windows provides a way to verify both the code that's written today, and code that will be written a year later. It's not just legally better, it's easier to do, easier for others to understand, and gives us a way to verify our code. Mike

June 9, 2006

Re: Vertex Buffer Objects for WineD3D

by Jesse Allen

On 6/9/06, Stefan Dösinger <stefan(a)codeweavers.com> wrote: > > * Shader support: I'm afraid that the conversion code at this points breaks > shaders. I've tested with battlefield 1942. The vertex shaders in this game > don't work correctly yet, the hands of soldiers are missing and there are > some incorrect planes with odd colors. However, with this patch the hands are > drawn as apparently random vertices all over the screen. I think I'll need a > little help from the shader people for that. > I've been trying to figure out what is wrong with the shaders with SW Battlefront. They work fine in the menus when you first load the game, but once you start a match, they seem to break. It is quite visible with the loading text seen in these two screenshots I've taken (ignore the other parts, I had windows over top): ftp://resnet.dnip.net/ This is same text problem as in Battlefield 1942. The crosshair in battlefront is also messed up, as certain skybox textures. It has to do something with blending as well. Jesse

June 9, 2006

Re: DDraw: New ddraw lib

by Jesse Allen

On 6/9/06, Stefan Dösinger <stefandoesinger(a)gmx.at> wrote: > Hi, > > I just want to state, the patch is very helpful when you can't use > > DGA. I just ran a test with Starcraft in multiplayer last night. Using > > OpenGL is noticibly faster than non-DGA. So I hope that it will get > > applied for 0.9.16. > Did you run it with opengl and this patch, or with Rodericks ddraw patch? > > I ran it with your patch. I'm not familiar with Rodericks patch.

June 9, 2006

Re: WineD3D: Fog fixes

by Jesse Allen

On 6/9/06, Stefan Dösinger <stefan(a)codeweavers.com> wrote: > This patch corrects a few issues with fog on transformed vertices, and > non-pixel-non-vertex fog. > > If WINED3DRS_FOGENABLE is TRUE, but WINED3RS_FOGVERTEXMODE and > WINED3DRS_FOGTABLEMODE are D3DFOG_NONE, then, according to the msdn, the > alpha channel specular color vertex color contains a pre-calculated fog > value. The same applied to transformed vertices if Vertexfog is enabled. This > patch uses glFogCoord to pass it to GL if GL_EXT_fog_coord is supported, and > disables GL fog if it isn't to minimize rendering issues. > > This patch makes Swat3 and Battlezone 2 happy, and the fog in Prince of Persia > 3D looks more correct now. I hoped that patch might solve the disappearing > objects problem in Half-Life 2, but unfortunately it doesn't, this seems not > to be fog-related :-( > > ChangeLog: > Stefan Dösinger(for CodeWeavers): Fog fixes > > This patch doesn't work with the latest fglrx saying missing symbol for glFogCoordf. Mesa is ok though. Jesse

June 9, 2006

Re: DDraw: New ddraw lib

by Stefan Dösinger

Hi, > I just want to state, the patch is very helpful when you can't use > DGA. I just ran a test with Starcraft in multiplayer last night. Using > OpenGL is noticibly faster than non-DGA. So I hope that it will get > applied for 0.9.16. Did you run it with opengl and this patch, or with Rodericks ddraw patch?

June 9, 2006

Vertex Buffer Objects for WineD3D

by Stefan Dösinger

Hi, In the last days I've been working on using the OpenGL vertex buffer objects extension for IWineD3DVertexBuffer. The aims of this were: * Store geometry data in the hardware for more efficient rendering * Convert the colors and rhw values on upload and get rid of drawStridedSlow The result is in this diff, and it basically works, although not as good as I've hoped. It gives a nice performance boost to Battlefield 1942, and is an improvement for Half-Life 2, but it is not perfect yet. The main shortcomings are: * Shader support: I'm afraid that the conversion code at this points breaks shaders. I've tested with battlefield 1942. The vertex shaders in this game don't work correctly yet, the hands of soldiers are missing and there are some incorrect planes with odd colors. However, with this patch the hands are drawn as apparently random vertices all over the screen. I think I'll need a little help from the shader people for that. * The vertex conversion is slow, and it turned out that if the app Locks the Buffer every frame then drawStridedSlow is faster Converting + drawStridedSlow. Because of that VBOs and the conversion aren't used for vertex buffers in system memory and vbs with WINED3DUSAGE_DYNAMIC are not loaded into a vbo. * In Direct3D7 there is no way for the app to specify a range of vertices to be locked. Because of that DX7 apps are generally slower if they update the vertices regularily. To avoid that drawback there is no VBO created for DX7 apps if they have vertex data that needs conversion. The geometry in DX7 apps is usually quite simple, so DrawStridedSlow isn't a big performance hit in those apps. Stefan

June 9, 2006

winspool/tests: Tests for GetPrintProcessorDirectory (resend for current HEAD)

by Detlef Riekenberg

Am Freitag, den 02.06.2006, 00:11 +0200 schrieb Detlef Riekenberg: > Changelog: > - winspool/tests: Tests for GetPrintProcessorDirectory > Resend for current HEAD -- By By ... ... Detlef

June 9, 2006

Re: DDraw: New ddraw lib

by Jesse Allen

On 6/9/06, Stefan Dösinger <stefandoesinger(a)gmx.at> wrote: > This is a resend of my ddraw rewrite, with some modifications Alexandre asked > for. I removed the whitespace fixes from the files which are taken from the > old ddraw code(light.c, material.c, clipper.c, viewport.c, executebuffer.c, > ddcomimpl.h, ddraw_thunks, surface_thunks). There are no functional changes > compared to the old patch, except a small change to forward the SYSTEMMEM and > WRITEONLY flags for vertexbuffers to WineD3D. > > The other files which have the same name as in the old code(main.c, > vertexbuffer.c): Those are rewrites(file deleted and re-created), so I won't > get a useful diff for them, no matter what I do. > > ChangeLog: > Stefan Dösinger: Use WineD3D for DDraw > I just want to state, the patch is very helpful when you can't use DGA. I just ran a test with Starcraft in multiplayer last night. Using OpenGL is noticibly faster than non-DGA. So I hope that it will get applied for 0.9.16. Jesse

June 9, 2006

Re: gcc V4 problem ?

by Marcus Meissner

On Fri, Jun 09, 2006 at 08:35:14AM +0100, Nick Law wrote: > Hi Guys, > > Hopefully somebody can give me some pointers on this. One of our Wow > gamers is trying to install wine on his system and ./configure exits > with a problem about not being able to compile. It looks like a problem > with gcc but I can't really see what's causing it other than the > -Voption. Are there any known issues or extra flags when running wines > configure on a system with gcc version 4 ? > /usr/bin/ld: crt1.o: No such file: No such file or directory > collect2: ld returned 1 exit status He needs the glibc development package (glibc-devel called on some RPM systems). Ciao, Marcus

June 9, 2006

Re: appdb security

by Joris Huizer

Tobias Burnus wrote: > > Why don't you use mysql_escape_string(...)? > http://de.php.net/manual/en/function.mysql-escape-string.php > > Tobias The page says it's deprecated and mentions using mysql_real_escape_string instead (http://nl2.php.net/mysql_real_escape_string) HTH, Joris

June 9, 2006

Re: user: Added specific winproc functions for calling dialog procedures.

by James Hawkins

Hey Alexandre, As of the following commit: Commit: 397bf3c2b133fe36529efcc4c1906bac1aac2da8 URL: http://source.winehq.org/git/?p=wine.git;a=commit;h=397bf3c2b133fe36529efcc… Author: Alexandre Julliard <julliard at winehq.org> Date: Tue May 9 20:33:11 2006 +0200 user: Added specific winproc functions for calling dialog procedures. The VB/VC++ 6 installers crash pretty early in the setup sequence. Two things to keep in mind are that the installer works correctly if I set the win version to win98, or I revert the following part of the patch: @@ -447,14 +441,8 @@ LRESULT WINAPI DefDlgProcA( HWND hwnd, U SetWindowLongPtrW( hwnd, DWLP_MSGRESULT, 0 ); - if ((dlgproc = DEFDLG_GetDlgProc( hwnd ))) - { - /* Call dialog procedure */ - result = CallWindowProcA( dlgproc, hwnd, msg, wParam, lParam ); - /* 16 bit dlg procs only return BOOL16 */ - if( WINPROC_GetProcType( dlgproc ) == WIN_PROC_16 ) - result = LOWORD(result); - } + if ((dlgproc = DEFDLG_GetDlgProc( hwnd ))) /* Call dialog procedure */ + result = WINPROC_CallDlgProcA( dlgproc, hwnd, msg, wParam, lParam ); if (!result && IsWindow(hwnd)) { I've done a fair bit of digging around on this bug, and I've noticed some things that are probably obvious to you, but might help put light on the situation for others. The order of the calls before the patch is applied is: DefDlgProcA -> CallWindowProcA -> WINPROC_CallWndProc and after the patch is applied: DefDlgProcA -> WINPROC_CallDlgProcA -> WINPROC_CallWndProc I've added debug printf's in these functions to see when they're called and what certain pointers contain. With the patch applied and and win version set to win98, the debug output is the same: DefDlgProcA CallWindowProcA func: 0xffff0027 CallWindowProcA proc: 0x40a5e1ac WINPROC_CallWndProc proc: 0x403020 CallWindowProcA func: 0x41ea2020 CallWindowProcA handle_to_proc returned NULL WINPROC_CallWndProc proc: 0x41ea2020 WINPROC_CallWndProc proc: 0x41ea2020 CallWindowProcA func: 0x41ea2020 CallWindowProcA handle_to_proc returned NULL WINPROC_CallWndProc proc: 0x41ea2020 WINPROC_CallWndProc proc: 0x41ea2020 WINPROC_CallWndProc proc: 0x41ea2020 WINPROC_CallWndProc proc: 0x41ea2020 WINPROC_CallWndProc proc: 0x41ea2020 and the installer goes on as usual (we know this because of a richedit trace from the richedit control on the next install screen). Here is the debug output with the patch applied and version set to win2000: DefDlgProcA DefDlgProcA dlgproc: 0xffff0026 WINPROC_CallDlgProcA func: 0xffff0026 WINPROC_CallDlgProcA proc: 0x40a5e1f8 WINPROC_CallDlgProcA proc->thunk.proc: 0x412020 WINPROC_CallWndProc proc: 0x412020 wine: Unhandled page fault on read access to 0x00000000 at address 0x411799 (thread 0009), starting debugger... Any insight you can provide about this bug would be greatly appreciated. -- James Hawkins

June 9, 2006

Re: notepad patches (search/replace, etc)

by Anoni Moose

Let's try again... I apologize for the bad indentation. It's indented fine in emacs, which I use; however, when I use "diff -u file1 file2", it gives me the entire file as a patch. Therefore, I must use "diff -uwB". Emacs must be screwing it up... ChangeLog: * programs/notepad/main.c, programs/notepad/main.h, programs/notepad/dialog.c, programs/notepad/dialog.h, programs/notepad/notepad_res.h, programs/notepad/En.rc, programs/notepad/rsrc.rc: notepad: Add search, replace, goto line functionality. -- - Anoni Moose

June 9, 2006

Re: notepad patches (search/replace, etc)

by Anoni Moose

Thanks for the input... I guess I've got a lot of fixing up to do. So, all of the responses I have received, I guess mean that they need to be redone before being accepted? If they don't get a response like "Accepted", they're not accepted? Maybe my strategy of making a bunch of changes and sending them all at once wasn't too good of an idea. :) I'll work on them and re-submit later. On 6/8/06, Vitaliy Margolen <wine-devel(a)kievinfo.com> wrote: > > Thursday, June 8, 2006, 6:40:33 PM, Anoni Moose wrote: > > This is my first patch to an open source project... if anyone has any > comments/suggestions, please tell me. :) > > > These patches add full search, search next, replace, and goto line > functionality to notepad. Too bad I missed the 0.9.15 release! > > > Changelog: > > > * programs/notepad/main.c, programs/notepad/dialog.c, > > programs/notepad/main.h, programs/notepad/notepad_res.h, > > programs/notepad/dialog.h: > > notepad: Add/call functions to load/save globals settings (including > font info) to registry. > > -Added full Search/Search Next functionality. > > -Added full Replace functionality. > > -Added full Goto Line functionality. > > -Load/Save to registry whether we want to wrap long lines or not. > > > Please one patch per email. You should combine all of your changes into > one patch > if that's one logical change and can be applied by itself. Of course > resultant code > should compile and work. > > > @@ -638,6 +641,8 @@ > > Globals.hFont=CreateFontIndirect( &lf ); > > Globals.lfFont=lf; > > SendMessage( Globals.hEdit, WM_SETFONT, (WPARAM)Globals.hFont, > (LPARAM)TRUE ); > > + SETTINGS_SaveSettings(); > > + > Please respect indentation. Don't just copy&paste stuff all over the file. > > > VOID DIALOG_Search(VOID) > > { > > + > > + if (Globals.find.hwndOwner == NULL) { > > ZeroMemory(&Globals.find, sizeof(Globals.find)); > > + } > > Globals.find.lStructSize = sizeof(Globals.find); > > Globals.find.hwndOwner = Globals.hMainWnd; > Pretty much the same here: don't just insert stuff, indent it properly. > And please no extra blank lines nor needles curly brackets. > > > + if (Globals.replace.hwndOwner == NULL) { > > + ZeroMemory(&Globals.replace, sizeof(Globals.replace)); > > + } > Respect indentation and style of the file you changing. In this case > 4-spaces > not 2. > > > + Globals.hFindReplaceDlg = ReplaceText(&Globals.replace); > > + assert(Globals.hFindReplaceDlg != 0); > > +} > Please don't use assert. Do a proper error checking instead. > > > + if (result == -1) { /* text not found. */ > > + MessageBoxA(Globals.hEdit, "Cannot find text.", NULL, MB_OK | > MB_ICONINFORMATION); > > + } else { > You should put all the text into resource files. > > > +WCHAR *GrabWindowTextW(HWND hWnd, DWORD *nbytes) { > > + > > + static WCHAR *data = NULL; > > + DWORD _nbytes = 0; > > + > > + if (nbytes == NULL) nbytes = &_nbytes; > > + > > + *nbytes = (*nbytes == 0 ? GetWindowTextLengthW(hWnd) + 1 : > *nbytes); > > + data = HeapAlloc(GetProcessHeap(), 0, (*nbytes) * sizeof(WCHAR)); > > + GetWindowTextW(hWnd, data, (*nbytes)+1); > > + return data; > > +} > Why do you need static if you return allocated buffer? > nbytes is misleading - it should be nchars. > (*nbytes)+1 is incorrect. You allocated enough memory for *nbytes only. > > > +int SearchText(HWND hWnd, LPFINDREPLACE find, int pos); > Please use windows types so they would work right on 64-bit platforms. > > > + "^R", CMD_REPLACE > Native notepad has it as ctrl+H. > > Vitaliy Margolen > > > > -- - Anoni Moose

June 9, 2006

Re: Dogfood report: Firefox autoupdate works

by Dan Kegel

On 6/9/06, Saulius Krasuckas <saulius2(a)ar.fi.lt> wrote: > BTW, Dan, would you be so kind as to check Firefox for > ablility to validate Wine installation as Genuine Windows? Still fails with wine-0.9.15: dank(a)lappy:~/Desktop$ ~/wine/wine WGAPluginInstall.exe fixme:advapi:DecryptFileA "C:\\windows\\temp\\IXP003.TMP\\" 00000000 fixme:advapi:CheckTokenMembership ((nil) 0x7fd44950 0x7fb8fddc) stub! A dialog comes up saying "Installation information unavailable". - Dan

June 9, 2006

Re: setupapi.dll: partially implement SetupDiGetClassDevsExA

by Peter Beutner

Mike McCormack wrote: > > Peter Beutner wrote: > >> I thought they started auditing their code and removing any "dirty" >> parts? >> And according to their website this process is nearly done. > > Unfortunately, the fallout of their audit process has been that many > trusted developers left the project. > > For me, the main problem is that there are ReactOS developers who think > that examining Windows assembly to write ReactOS code is a proper way to > do things. I think the problem is that the way you describe is totally legal in most countries. In fact, afaik it is only in the USA where you have this explicit distinction between clean("chinese wall") and "dirty" reverse engineering. Which reminds me of a similiar thread on lkml about which country's laws actually applies here. hmm ... >> btw. using their code as documentation to implement something on wine >> should be safe nevertheless, shouldn't it? > > I'd avoid their code if I were you. ok, seems to be the easiest/cleanest solution ;)

June 9, 2006

Re: [WINED3D 2/9] Add the bulk of the GLSL string generation functions

by Jason Green

On 6/9/06, H. Verbeet <hverbeet(a)gmail.com> wrote: > Is making the distinction between rgba and xyzw really needed? xyzw / > rgba / stpq should be equivalent and the distinction is mostly for > readability if you know the variable type. However, since you can't > decided that purely based on whether something is a vertex shader or a > pixel shader, the way it's currently done might be misleading in some > cases. > That makes sense (and so does your comment about patch #9). Instead of rebuilding the patchset, though, I'll submit a small cleanup patch today as #10/9, as these patches aren't technically wrong. There's always a better way. ;-)

June 9, 2006

Re: Recording with "Lexia" (mci "open new")

by Peter Åstrand

On Thu, 8 Jun 2006, Peter Åstrand wrote: >>> 2) Any ideas why "open new" works, even though >>> MCIERR_MISSING_DEVICE_NAME is returned? >> >> because "open new alias capture" should create a new mci session of name >> capture (which is application defined), and mci supports the "auto" open >> feature, which is when accessing a not yet created device, it opens it. so, >> the fix to system.ini is wrong. what's missing is the support of the new >> keyword, as the FIXME in mci.c suggests. > > Are you referring to FIXME("'new': NIY as device name\n")? In that case, can I've managed to implement this now. Will send a patch to the wine-patches mailing list. Regards, -- Peter Åstrand ThinLinc Chief Developer Cendio http://www.cendio.se Teknikringen 3 583 30 Linköping Phone: +46-13-21 46 00

June 9, 2006

Re: Recording with "Lexia" (mci "open new")

by Damjan Jovanovic

> 3) Most importantly: Why is it necessary to add > CAPTURE to system.ini? > Perhaps the "alias" argument isn't correctly > handled? Yes wine's MCI is broken: the parsing of some formats of MCI commands is incorrect, one of the examples I clearly remember being: "open G: type cdaudio alias cd" and wine complains that it could not load driver for type G: (whereas the driver type is cdaudio, no?) and you have to add "G:=mcicda.dll" in system.ini __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com

June 9, 2006

Re: [WINED3D 9/9] Allow drawPrim to create and use the GLSL program

by H. Verbeet

Does this reset the currently used program to 0 when fixed function is supposed to be used again? I think we should just do glUseProgramObjectARB(programId), since when fixed function is supposed to be used the program id will be 0. That also mean you don't have to do an explicit glUseProgramObjectARB(0) at a later stage, which saves an extra shader switch, in particular if the same shader is used in the next DrawPrimitive call.

June 9, 2006

Re: [WINED3D 2/9] Add the bulk of the GLSL string generation functions

by H. Verbeet

Is making the distinction between rgba and xyzw really needed? xyzw / rgba / stpq should be equivalent and the distinction is mostly for readability if you know the variable type. However, since you can't decided that purely based on whether something is a vertex shader or a pixel shader, the way it's currently done might be misleading in some cases.

June 9, 2006

Re: Update the progress control while installing.

by Dmitry Timoshkov

"Mike McCormack" <mike(a)codeweavers.com> wrote: > --- a/dlls/msi/dialog.c > +++ b/dlls/msi/dialog.c > @@ -62,6 +62,8 @@ struct msi_control_tag > HICON hIcon; > LPWSTR tabnext; > HMODULE hDll; > + float progress_current; > + float progress_max; Is it really necessary to use float instead of long? -- Dmitry.

June 9, 2006

Re: notepad patches (search/replace, etc)

by Alexandre Julliard

Christoph Frick <frick(a)sc-networks.de> writes: > what is the difference between anonymous submissions, that we can spot > and which we don't? maybe you are a fake ;) Of course there's no real difference, but collaboration is based on trust, and it's hard to trust people who don't even want to give out their name. Obviously you can give me a false name, but I'll figure it out eventually, and then trust you even less than an anonymous submitter so there's really no point in trying to cheat. If you have good reasons for wanting to remain anonymous, please discuss it with me in private and we can arrange something; but otherwise please use your real name. -- Alexandre Julliard julliard(a)winehq.org

June 9, 2006

Re: notepad patches (search/replace, etc)

by Andreas Mohr

Hi, On Fri, Jun 09, 2006 at 10:52:58AM +0200, Christoph Frick wrote: > On Fri, Jun 09, 2006 at 10:08:11AM +0200, Andreas Mohr wrote: > > > Or, IOW, do we have any guidelines about "Anoni Moose" submissions to > > our project? Are they ok, not ok, ok? Loves me, loves me not, ... > > what is the difference between anonymous submissions, that we can spot > and which we don't? maybe you are a fake ;) Darn, I knew fully well that exactly this objection would arise... ;) Me, I've been created as an IRC bot happily typing away for about a decade without anyone noticing... Oh, that's not true in fact, people do know that I'm real, since someone has been showing up at Codeweavers and various wineconfs pretending to be me ;) So I guess it's fully a non-issue after all since the internet is a completely anonymous space anyway and patches can only be judged by their quality, not by their origin. Sorry for the noise! Andreas

June 9, 2006

Re: notepad patches (search/replace, etc)

by Christoph Frick

On Fri, Jun 09, 2006 at 10:08:11AM +0200, Andreas Mohr wrote: > Or, IOW, do we have any guidelines about "Anoni Moose" submissions to > our project? Are they ok, not ok, ok? Loves me, loves me not, ... what is the difference between anonymous submissions, that we can spot and which we don't? maybe you are a fake ;) -- cu

June 9, 2006

Re: Dogfood report: Firefox autoupdate works

by Saulius Krasuckas

* On Wed, 3 May 2006, Dan Kegel wrote: > Windows Firefox just happily updated itself under Wine to > 1.5.0.3. Nice that an uncommon code path worked fine. And how it does with 1.5.0.4 update? > Firefox is solid for my uses lately. BTW, Dan, would you be so kind as to check Firefox for ablility to validate Wine installation as Genuine Windows? Just some minutes ago I've tried to download "Windows Installer 3.0 Redistributable", and the page [*] required my client to begin Windows validation. As I have no Win32 FF installed (which is required for the 1st way, for validation plug-in to install), I've chosen 2nd way to do this: I ran some older GenuineCheck.exe under wine, it generated me some code and finally I was able to download the needed stuff :) So, maybe the plug-in would work in Wine also? Oh yes, as newest GenuineCheck.exe crashes, newest WGAPluginInstall.exe may fail also. For this reason I've put online older versions of both: [2] [1] http://www.microsoft.com/downloads/details.aspx?FamilyID=7b9ba261-7a9c-43e7… [2] http://193.219.43.130/~winetester/bin/win32/WindowsValidation/20060517/

June 9, 2006

Re: notepad: settings saving code

by Robert Shearman

Anoni Moose wrote: >/* This table is used to save all of the needed font settings in Notepad. > * It looks quite messy, when in fact it _hugely_ eases loading/setting of settings. Really. ;) > * It is layed out as follows: > * > * [n][0] == pointer to registry subkey name (WCHAR) > * [n][1] == type of registry entry > * [n][2] == pointer to buffer to store setting > * [n][3] == size of data returned > * [n][4] == default value to use if subkey was not found > * [n][5] == registry path to open (ANSI, not including root (HKEY_CURRENT_USER, etc)) > */ >DWORD settings_data[15][6] = { > { (DWORD)&heightW, REG_DWORD, (DWORD)&Globals.lfFont.lfHeight, > sizeof(REG_DWORD), -10, (DWORD)&FONT_SETTINGS_REG_PATH }, > > You should define a proper structure to put this data in rather than casting the values to DWORD (which won't work in 64-bit mode). -- Rob Shearman

June 9, 2006

Re: regedit: bug fixes/feature

by Robert Shearman

Anoni Moose wrote: > These patches save current node on click, and remove items before > opening keys, so if a node has no keys/is invalid, no keys show, which > can lead to problems. Changelog: > > * programs/regedit/main.c, programs/regedit/childwnd.c: > regedit: Save current node to registry on change; load again after > regedit is reopened. > -Don't UpdateWindow() in InitInstance() (unneeded, adds > flicker). > -Delete all items from listview before opening key, so if > key open fails, no items display. > This patch looks good, but I'm not sure about removing the UpdateWindow call. I think it is still necessary, although it might be better to move it to after the getting of the default path, which should remove the flicker. -- Rob Shearman

June 9, 2006

Re: notepad patches (search/replace, etc)

by Andreas Mohr

Hi, On Thu, Jun 08, 2006 at 08:40:33PM -0400, Anoni Moose wrote: > This is my first patch to an open source project... if anyone has any > comments/suggestions, please tell me. :) I can't help but say that your parents must have been giving you a rather "funny" name... Or, IOW, do we have any guidelines about "Anoni Moose" submissions to our project? Are they ok, not ok, ok? Loves me, loves me not, ... Anyway, thanks for a very nice collection of patches! Andreas Mohr

June 9, 2006

gcc V4 problem ?

by Nick Law

Hi Guys, Hopefully somebody can give me some pointers on this. One of our Wow gamers is trying to install wine on his system and ./configure exits with a problem about not being able to compile. It looks like a problem with gcc but I can't really see what's causing it other than the -Voption. Are there any known issues or extra flags when running wines configure on a system with gcc version 4 ? Here's the bit of the config.log the shows the problem $ ./configure ## --------- ## ## Platform. ## ## --------- ## hostname = sheky uname -m = i686 uname -r = 2.6.12-10-386 uname -s = Linux uname -v = #1 Fri Apr 28 13:13:44 UTC 2006 /usr/bin/uname -p = unknown /bin/uname -X = unknown /bin/arch = i686 /usr/bin/arch -k = unknown /usr/convex/getsysinfo = unknown /usr/bin/hostinfo = unknown /bin/machine = unknown /usr/bin/oslevel = unknown /bin/universe = unknown PATH: /usr/local/sbin PATH: /usr/local/bin PATH: /usr/sbin PATH: /usr/bin PATH: /sbin PATH: /bin PATH: /usr/X11R6/bin ## ----------- ## ## Core tests. ## ## ----------- ## configure:1875: checking build system type configure:1893: result: i686-pc-linux-gnulibc1 configure:1915: checking host system type configure:1930: result: i686-pc-linux-gnulibc1 configure:1984: checking whether make sets $(MAKE) configure:2005: result: yes configure:2062: checking for gcc configure:2089: result: gcc configure:2327: checking for C compiler version configure:2329: gcc --version >&5 gcc (GCC) 4.0.2 20050808 (prerelease) (Ubuntu 4.0.1-4ubuntu9) Copyright (C) 2005 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. configure:2332: $? = 0 configure:2334: gcc -v >&5 Using built-in specs. Target: i486-linux-gnu Configured with: ../src/configure -v --enable-languages=c,c++,java,f95,objc,ada,treelang --prefix=/usr --with-gxx-include-dir=/usr/include/c++/4.0.2 --enable-shared --with-system-zlib --libexecdir=/usr/lib --enable-nls --without-included-gettext --enable-threads=posix --program-suffix=-4.0 --enable-__cxa_atexit --enable-libstdcxx-allocator=mt --enable-clocale=gnu --enable-libstdcxx-debug --enable-java-gc=boehm --enable-java-awt=gtk --enable-gtk-cairo --with-java-home=/usr/lib/jvm/java-1.4.2-gcj-4.0-1.4.2.0/jre --enable-mpfr --disable-werror --enable-checking=release i486-linux-gnu Thread model: posix gcc version 4.0.2 20050808 (prerelease) (Ubuntu 4.0.1-4ubuntu9) configure:2337: $? = 0 configure:2339: gcc -V >&5 gcc: '-V' option must have argument configure:2342: $? = 1 configure:2382: checking for C compiler default output file name configure:2386: gcc conftest.c >&5 /usr/bin/ld: crt1.o: No such file: No such file or directory collect2: ld returned 1 exit status configure:2389: $? = 1 configure: failed program was: | /* confdefs.h. */ | #define PACKAGE_NAME "Wine" | #define PACKAGE_TARNAME "wine" | #define PACKAGE_VERSION "0.9.15" | #define PACKAGE_STRING "Wine 0.9.15" Regards Nick Law

June 9, 2006

Re: appdb security

by Christoph Frick

On Thu, Jun 08, 2006 at 06:44:15PM -0500, EA Durbin wrote: > function makeSafe( $var ) > { > $var = trim( addslashes( $var ) ); > return $var; > } > > > $clean['var1'] = makeSafe( $_REQUEST['var1'] ); > $clean['var2'] = makeSafe( $_REQUEST['var2'] ); sorry for only throwing things at you guys and not providing any code - but i am currently packed with work :/ why dont create a object, that wrapps the request and makes it "safe". then fixing the app is not more like sed action and you can handle stuff in future as you like: $_REQUEST[(['"][^'"]+['"])] -> Request::get(\1) -- cu

June 9, 2006

Re: regedit: Refresh also refresh registry keys in listview

by James Hawkins

On 6/8/06, Anoni Moose <moose.anoni(a)gmail.com> wrote: > These patches allow for refreshing of registry keys in listview, when > Refresh menu item is selected. > > Changelog: > > * programs/regedit/framewnd.c, programs/regedit/treeview.c: > regedit: Uncomment RefreshListView() call, comment TVM_SELECTITEM call, > to > let "Refresh" menu item/key also refresh registry values being > shown > in treeview. > One patch per email please. Same goes for all your other submissions. -- James Hawkins

June 8, 2006

Re: edit: Fix crashing, bugs

by James Hawkins

On 6/8/06, Anoni Moose <moose.anoni(a)gmail.com> wrote: > This patch fix an unhandled page fault with MS notepad and Wine Notepad when > loading/editing large files, and some other bugs shown in the Changelog: > > * dlls/user/edit.c: > user: Fixed unhandled page-fault when text length exceeded buffer size. > -Don't gradually continue to highlight text if mouse button is > held in and > it's position moves out of the edit window, and doesn't move while > outside. > -Scroll up/down if mouse is outside of window and moving up/down. > -If a button was clicked in a dialog, therefore setting the focus > to it, and then > an application sent a SETFOCUS message to an editbox, it would > keep the focus on > the button. > You need to submit one fix per patch, one patch per email. -- James Hawkins

June 8, 2006

Re: str*casecmpW functions

by Vitaliy Margolen

Thursday, June 8, 2006, 6:57:36 PM, Anoni Moose wrote: > This patch adds some functions for comparison of WCHAR strings, while ignoring case. Changelog: > * libs/unicode/string.c: > unicode: Added strcasecmpW, strncasecmpW functions. BTW what's wrong with strncmpiW? Vitaliy Margolen

June 8, 2006

Re: server: use getopt

by Mike McCormack

Anoni Moose wrote: > This patch let's the server code use getopt to parse arguments. + while ((optchr = getopt(argc, argv, "d:fhk:p:vw")) != -1 && + optind < argc) { /* 'Tis possible we might have a variable declaration... */ + + switch (optchr) { + case 'd': - if (isdigit(argv[i][2])) debug_level = atoi( argv[i] + 2 ); + if (isdigit(optarg[0])) debug_level = atoi( optarg ); else debug_level++; break; Using getopt() doesn't really gain us anything here. Also, changing the indent and brace style to suit yourself (especially in wineserver) isn't appreciated. Mike

June 8, 2006

Re: wcmd: some features/bug fixes

by Mike McCormack

Anoni Moose wrote: > * programs/wcmd/builtins.c, programs/wcmd/wcmdmain.c, > programs/wcmd/wcmd.h: > wcmd: Clear terminal screen using escape code. > -Fix infinite file-read loop with TYPE command. > -TITLE command use terminal escape code. > -Added FREEDISK command. Please send one patch per email. The patch should be standalone. + /* Clear the _terminal_ screen by giving the correct terminal escape code. */ + printf("%cc", 0x1B); You can't assume that you'll be using any sort of terminal here. If the backend is wineconsole or a non-xterm/vt100 terminal, then this won't work. You have to use the Win32 API. Mike

June 8, 2006

Re: str*casecmpW functions

by Mike McCormack

Anoni Moose wrote: > * libs/unicode/string.c: > unicode: Added strcasecmpW, strncasecmpW functions. You've added a dependency on user32.tolowerW, which cannot be linked from all the places that unicode.h is used. Mike

June 8, 2006

Re: notepad: settings saving code

by Mike McCormack

Anoni Moose wrote: > The following files allow saving and loading of notepad's settings to > the registry. No patch needed... new files. Changelog: Always send a patch, and make sure to create it from your wine/ directory so that the full path of the file that you're modifying is specified. These files won't be compiled unless you add something to the Makefile.in, and can't be used without some kind of change to the existing code. Mike

June 8, 2006

Re: notepad patches (search/replace, etc)

by Vitaliy Margolen

Thursday, June 8, 2006, 6:40:33 PM, Anoni Moose wrote: > This is my first patch to an open source project... if anyone has any comments/suggestions, please tell me. :) > These patches add full search, search next, replace, and goto line functionality to notepad. Too bad I missed the 0.9.15 release! > Changelog: > * programs/notepad/main.c, programs/notepad/dialog.c, > programs/notepad/main.h, programs/notepad/notepad_res.h, > programs/notepad/dialog.h: > notepad: Add/call functions to load/save globals settings (including font info) to registry. > -Added full Search/Search Next functionality. > -Added full Replace functionality. > -Added full Goto Line functionality. > -Load/Save to registry whether we want to wrap long lines or not. Please one patch per email. You should combine all of your changes into one patch if that's one logical change and can be applied by itself. Of course resultant code should compile and work. > @@ -638,6 +641,8 @@ > Globals.hFont=CreateFontIndirect( &lf ); > Globals.lfFont=lf; > SendMessage( Globals.hEdit, WM_SETFONT, (WPARAM)Globals.hFont, (LPARAM)TRUE ); > + SETTINGS_SaveSettings(); > + Please respect indentation. Don't just copy&paste stuff all over the file. > VOID DIALOG_Search(VOID) > { > + > + if (Globals.find.hwndOwner == NULL) { > ZeroMemory(&Globals.find, sizeof(Globals.find)); > + } > Globals.find.lStructSize = sizeof(Globals.find); > Globals.find.hwndOwner = Globals.hMainWnd; Pretty much the same here: don't just insert stuff, indent it properly. And please no extra blank lines nor needles curly brackets. > + if (Globals.replace.hwndOwner == NULL) { > + ZeroMemory(&Globals.replace, sizeof(Globals.replace)); > + } Respect indentation and style of the file you changing. In this case 4-spaces not 2. > + Globals.hFindReplaceDlg = ReplaceText(&Globals.replace); > + assert(Globals.hFindReplaceDlg != 0); > +} Please don't use assert. Do a proper error checking instead. > + if (result == -1) { /* text not found. */ > + MessageBoxA(Globals.hEdit, "Cannot find text.", NULL, MB_OK | MB_ICONINFORMATION); > + } else { You should put all the text into resource files. > +WCHAR *GrabWindowTextW(HWND hWnd, DWORD *nbytes) { > + > + static WCHAR *data = NULL; > + DWORD _nbytes = 0; > + > + if (nbytes == NULL) nbytes = &_nbytes; > + > + *nbytes = (*nbytes == 0 ? GetWindowTextLengthW(hWnd) + 1 : *nbytes); > + data = HeapAlloc(GetProcessHeap(), 0, (*nbytes) * sizeof(WCHAR)); > + GetWindowTextW(hWnd, data, (*nbytes)+1); > + return data; > +} Why do you need static if you return allocated buffer? nbytes is misleading - it should be nchars. (*nbytes)+1 is incorrect. You allocated enough memory for *nbytes only. > +int SearchText(HWND hWnd, LPFINDREPLACE find, int pos); Please use windows types so they would work right on 64-bit platforms. > + "^R", CMD_REPLACE Native notepad has it as ctrl+H. Vitaliy Margolen

June 8, 2006

Re: xlldrv/keyboard.c: Report of typos

by Joseph Garvin

Andrew Talbot wrote: > I guess, for now, if I want to edit a file that contains high-order > characters, I will need to change the encoding setting of the editor to one > that can accommodate the full character set. > > Thanks, > > -- Andy. > > > Why not submit a bug for Kate? It should detect the encoding automatically if Vim can. http://bugs.kde.org

June 8, 2006

Re: appdb security

by EA Durbin

>>Is there a reason why we don't do the if(empty()) check inside of >>makeSafe()? as in put the if(empty()) inside of the function itself, or pass if( empty (makeSafe( $_REQUEST['appId'] ) ) ) when we assign it? the reason I didn't put it in the makeSafe function was because we were testing to see if the variable was isset or empty and determining on the point of the application the result was either set to "" or 0, you could do it inside of the makeSafe() function but returning "" may not always be the desired results. you could call the empty() test while you were assigning it, I just always start out assigning all of the user input variables I'm going to use at the top of the page by passing them through makeSafe. function makeSafe( $var ) { $var = trim( addslashes( $var ) ); return $var; } $clean['var1'] = makeSafe( $_REQUEST['var1'] ); $clean['var2'] = makeSafe( $_REQUEST['var2'] ); then any subsequent test called upon the variables are ensured to be clean. if your desired output of makeSafe is to be "" if its empty then you could put the empty() test inside of makeSafe, but further down in the app we were testing for empty and returning 0.

June 8, 2006

Re: appdb security

by EA Durbin

It will be a large undertaking, but I'll help change this across the board. I'm going out of town for the next 2 days and won't be near my computer, but I can start on it when I get back. >From: Chris Morgan <cmorgan(a)alum.wpi.edu> >To: wine-devel(a)winehq.org, EA Durbin <ead1234(a)hotmail.com> >Subject: Re: appdb security >Date: Thu, 8 Jun 2006 16:40:55 -0400 > >Alright. I'm sold on having to check all user input. We should make this >input checking change across the board if you are up for it. > >$clean = array(); //array of filtered user input >+ >+$clean['catId'] = makeSafe( $_REQUEST['catId'] ); > > function admin_menu() > { >- if(isset($_REQUEST['catId'])) $catId=$_REQUEST['catId']; >- else $catId=""; >+ $clean['catId'] = makeSafe( $_REQUEST['catId'] ); >+ if ( empty($clean['catId']) ) >+ { >+ $clean['catId']=""; >+ } > > >Is there a reason why we don't do the if(empty()) check inside of >makeSafe()? > >Chris > > >On Thursday 08 June 2006 1:40 pm, EA Durbin wrote: > > I always use the method of filtering user input as described at the php > > security consortium. It makes it easier to track tainted user input vs > > filtered input. If all filtered variables are put in an array it makes >it > > easier to ensure you're using the non tainted variable. > > > > http://phpsec.org/projects/guide/1.html#1.4 > > > > Then PEAR::DB to query the mysql database as PEAR::DB handles the SQL > > filtering. > > > > >From: Jonathan Ernst <jonathan(a)ernstfamily.ch> > > >To: wine-devel(a)winehq.com > > >Subject: Re: appdb security > > >Date: Thu, 08 Jun 2006 18:12:20 +0200 > > > > > >Le jeudi 08 juin 2006 Ø£Â 11:42 -0400, Chris Morgan a Ø£ï¿œcrit : > > > > Can you come up with a non-destructive working example for the appdb > > > > website(appdb.winehq.org)? ;-) > > > > > > > > I ask because I thought we went through this some time ago but I >agree > > > > > >that > > > > > > > what you say looks like an open issue. > > > > > > > > Chris > > > > > >Lately I used the following snippet in all my webapps to secure them > > >against sql injection : > > > > > >http://php.net/mysql_real_escape_string under "Best practice". > > > > > ><?php > > >function smart_quote($value) > > >{ > > > // Stripslashes > > > if (get_magic_quotes_gpc()) { > > > $value = stripslashes($value); > > > } > > > // Protect it if it's not an integer > > > if (!is_numeric($value)) { > > > $value = "'" . mysql_real_escape_string($value) . "'"; > > > } > > > return $value; > > >} > > > > > >// Secure query > > >$sQuery = sprintf("SELECT * > > > FROM users > > > WHERE user=%s AND password=%s", > > > smart_quote($_POST['username']), > > > smart_quote($_POST['password'])); > > >mysql_query($query); > > >?> > > > > > >I think it is better than what we have now in AppDB (didn't check it > > >though). If nobody looks at it, I'll check the code after my master > > >thesis (in one month). > > > > > >Jonathan > > > > > > > > ><< signature.asc >>

June 8, 2006

Re: xlldrv/keyboard.c: Report of typos

by Andrew Talbot

James Hawkins wrote: > Can you give us some examples of possible typos? I think people will > be more inclined to look into the problem if they see a definite > problem pointed out. > I have worked out what is happening. Assuming the newsgroup system can render the characters properly, in Vim, a sample array looks like this, containing some accented characters: /*** Icelandic keyboard layout (setxkbmap is) */ static const char main_key_IS[MAIN_LEN][4] = { "°","1!","2\"","3#","4$","5%","6&","7/","8(","9)","0=","öÖ","-_", "qQ","wW","eE","rR","tT","yY","uU","iI","oO","pP","ðÐ","'?", "aA","sS","dD","fF","gG","hH","jJ","kK","lL","æÆ","´Ä","+*", "zZ","xX","cC","vV","bB","nN","mM",",;",".:","þÞ", "<>" }; I have the text editor I use - Kate - set to use utf8 encoding, which renders the same text thus: /*** Icelandic keyboard layout (setxkbmap is) */ static const char main_key_IS[MAIN_LEN][4] = { "","1!","2\"","3#","4$","5%","6&","7/","8(","9)","0=","�","-_", "qQ","wW","eE","rR","tT","yY","uU","iI","oO","pP","�","'?", "aA","sS","dD","fF","gG","hH","jJ","kK","lL","�","�,"+*", ^ missing double quote "zZ","xX","cC","vV","bB","nN","mM",",;",".:","�, "<>" }; If I save this file in my editor, I inadvertently corrupt it into this second form. I suppose further such accidents (most likely to affect English people, who do not generally use accented characters) would be prevented if the accented characters were replaced with hex escape sequences. The downside being that one would not be able to see what characters they were via a suitable editor, but that may be less important. I guess, for now, if I want to edit a file that contains high-order characters, I will need to change the encoding setting of the editor to one that can accommodate the full character set. Thanks, -- Andy.

June 8, 2006

Re: wined3d: GLSL Patch feedback requested

by Ivan Gyurdiev

+ * If a program for the given combination does not exist, create one, and store + * that data in both shader objects so we can delete all of the programs later. + * If it creates a program, it will link the given objects, too. Is this comment still relevant? > - Fix relative addressing (it was working correctly, then I lost some > stuff when my hard drive got corrupted, and now it's using R0 instead > of A0 as the address register for some reason) For 1.X shaders, the relative address token = 0 (a.k.a R0), and A0.x must be used instead. Another problem may be matrix instructions, which don't seem to set the reladdr token right now.

June 8, 2006

Re: xlldrv/keyboard.c: Report of typos

by James Hawkins

On 6/8/06, Andrew Talbot <Andrew.Talbot(a)talbotville.com> wrote: > I believe there are numerous typos in this file. Starting at line 310, there > seem to be several missing double quotes; they break compilation if > -Wwrite-strings is specified. I was going to assume the missing quotes to > be the only factor and fix things myself. But as there are some > non-printing characters in there that I don't understand, I thought I would > mention it here, instead, so that someone who knows about keyboard layouts > might fix these arrays properly. > Can you give us some examples of possible typos? I think people will be more inclined to look into the problem if they see a definite problem pointed out. -- James Hawkins

June 8, 2006

xlldrv/keyboard.c: Report of typos

by Andrew Talbot

I believe there are numerous typos in this file. Starting at line 310, there seem to be several missing double quotes; they break compilation if -Wwrite-strings is specified. I was going to assume the missing quotes to be the only factor and fix things myself. But as there are some non-printing characters in there that I don't understand, I thought I would mention it here, instead, so that someone who knows about keyboard layouts might fix these arrays properly. -- Andy.

June 8, 2006

Re: appdb security

by Chris Morgan

Alright. I'm sold on having to check all user input. We should make this input checking change across the board if you are up for it. $clean = array(); //array of filtered user input + +$clean['catId'] = makeSafe( $_REQUEST['catId'] ); function admin_menu() { - if(isset($_REQUEST['catId'])) $catId=$_REQUEST['catId']; - else $catId=""; + $clean['catId'] = makeSafe( $_REQUEST['catId'] ); + if ( empty($clean['catId']) ) + { + $clean['catId']=""; + } Is there a reason why we don't do the if(empty()) check inside of makeSafe()? Chris On Thursday 08 June 2006 1:40 pm, EA Durbin wrote: > I always use the method of filtering user input as described at the php > security consortium. It makes it easier to track tainted user input vs > filtered input. If all filtered variables are put in an array it makes it > easier to ensure you're using the non tainted variable. > > http://phpsec.org/projects/guide/1.html#1.4 > > Then PEAR::DB to query the mysql database as PEAR::DB handles the SQL > filtering. > > >From: Jonathan Ernst <jonathan(a)ernstfamily.ch> > >To: wine-devel(a)winehq.com > >Subject: Re: appdb security > >Date: Thu, 08 Jun 2006 18:12:20 +0200 > > > >Le jeudi 08 juin 2006 أ 11:42 -0400, Chris Morgan a أ�crit : > > > Can you come up with a non-destructive working example for the appdb > > > website(appdb.winehq.org)? ;-) > > > > > > I ask because I thought we went through this some time ago but I agree > > > >that > > > > > what you say looks like an open issue. > > > > > > Chris > > > >Lately I used the following snippet in all my webapps to secure them > >against sql injection : > > > >http://php.net/mysql_real_escape_string under "Best practice". > > > ><?php > >function smart_quote($value) > >{ > > // Stripslashes > > if (get_magic_quotes_gpc()) { > > $value = stripslashes($value); > > } > > // Protect it if it's not an integer > > if (!is_numeric($value)) { > > $value = "'" . mysql_real_escape_string($value) . "'"; > > } > > return $value; > >} > > > >// Secure query > >$sQuery = sprintf("SELECT * > > FROM users > > WHERE user=%s AND password=%s", > > smart_quote($_POST['username']), > > smart_quote($_POST['password'])); > >mysql_query($query); > >?> > > > >I think it is better than what we have now in AppDB (didn't check it > >though). If nobody looks at it, I'll check the code after my master > >thesis (in one month). > > > >Jonathan > > > > > ><< signature.asc >>

June 8, 2006

Re: Recording with "Lexia" (mci "open new")

by Peter Åstrand

> 1) I believe the mciwave.c patch below makes sense in any case, right? > >> Without it freed memory is used. > > I don't see why ? wmw->openParms.lpstrElementName and filename is a pointer to the same memory, due to this statement in WAVE_mciOpen: memcpy(&wmw->openParms, lpOpenParms, sizeof(MCI_WAVE_OPEN_PARMSA)); >> 2) Any ideas why "open new" works, even though >> MCIERR_MISSING_DEVICE_NAME is returned? > > because "open new alias capture" should create a new mci session of name > capture (which is application defined), and mci supports the "auto" open > feature, which is when accessing a not yet created device, it opens it. so, > the fix to system.ini is wrong. what's missing is the support of the new > keyword, as the FIXME in mci.c suggests. Are you referring to FIXME("'new': NIY as device name\n")? In that case, can you roughly describe what needs to be done? Or, perhaps you have a plan for fixing this yourself? :) Kind regards, -- Peter Åstrand ThinLinc Chief Developer Cendio http://www.cendio.se Teknikringen 3 583 30 Linköping Phone: +46-13-21 46 00

June 8, 2006

Re: Prospects of an OpenAL audio driver...

by Eric Pouech

Nick Burns wrote: >> 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. it's not an openal point. it's whether you can open, in two steps (from the windows point of view) the device in playback mode, then in record mode (keeping the playback mode opened) >> >> >>> >>> 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. >> > - For recording (1.1 only) : start capturing -- poll (get data -- if > there) -- stop recording > > Hmm... Is there a way I can request some docs (or is the source code + > msdn the doc)? basically, look on MSDN at the dsound interfaces, and the way it's done on OSS >> 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). > > 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... my point is linking to a 3D effect library for low level audio portability *IS* overkill as if someone suggests that for plotting a dot on a screen (and only that) you'd need opengl A+

June 8, 2006

Re: Recording with "Lexia" (mci "open new")

by Eric Pouech

1) I believe the mciwave.c patch below makes sense in any case, right? > Without it freed memory is used. I don't see why ? > > 2) Any ideas why "open new" works, even though > MCIERR_MISSING_DEVICE_NAME is returned? because "open new alias capture" should create a new mci session of name capture (which is application defined), and mci supports the "auto" open feature, which is when accessing a not yet created device, it opens it. so, the fix to system.ini is wrong. what's missing is the support of the new keyword, as the FIXME in mci.c suggests. A+

June 8, 2006

Re: Feedback requested for Mac OSX x86 stack patch

by Nick Burns

>From: Robert Shearman <rob(a)codeweavers.com> >Subject: Re: Feedback requested for Mac OSX x86 stack patch >Date: Thu, 08 Jun 2006 10:29:11 +0100 > >Nick Burns wrote: > >>I tried using winapi_check, winapi_test, winapi_... >>They all seemed to give me some odd perl errors (missing defs/funcs in >>config.pm that WERE there and were also in setup.pm) >>So... I stupidly went thru and made the relevant files work by copying and >>pasting the functions and changing def imports to setup.pm (what a pain >>that was -- as i dont know perl) >>I am guessing this should just WORK... >> >>It seems like it would be a good idea to go thru the msvcrt functions and >>label the exports as >>WINAPIV (or __cdecl) -- im not sure what the desired convention is. > > >WINAPIV is purely for vararg functions and might not match the calling >conventions of msvcrt on other platforms. You should label them with CDECL >instead, as Alexandre suggested. Ok if thats the correct solution -- some one (either me or someone else) should patch msvcrt to have have its exported functions as CDECL (which I now believe means that its an EXTERNAL EXPORTED function) I do not want the force attrib on internal functions for no good reason... The patch as it stands is heavy handed.. and needs to be narrowed correctly -- __stdcall/__cdecl could be internal maybe sometimes?. >-- >Rob Shearman - Nick

June 8, 2006

Re: Feedback requested for Mac OSX x86 stack patch -- #2

by Nick Burns

>From: Robert Shearman <rob(a)codeweavers.com> >Subject: Re: Feedback requested for Mac OSX x86 stack patch -- #2 >Date: Thu, 08 Jun 2006 10:36:31 +0100 > >Nick Burns wrote: > >>diff -u -p -r1.114 ChangeLog >>--- ChangeLog 24 May 2006 18:09:06 -0000 1.114 >>+++ ChangeLog 8 Jun 2006 07:06:10 -0000 >>@@ -1,3 +1,8 @@ >>+2006-06-08 Nick Burns <adger44(a)hotmail.com> >>+ >>+ * include/windef.h: >>+ If on Mac OSX (x86) use force_align_arg_pointer to fix the stack >>on entry to Wine. >>+ >> 2006-05-24 Alexandre Julliard <julliard(a)winehq.org> >> * dlls/usp10/tests/usp10.c: > > >You don't need to patch ChangeLog; it is update each release from GIT >history. Just include the text you want in the change log in the email you >send the patch with. Got ya no changelog dealies -- was unsure about that part... >>Index: include/windef.h >>=================================================================== >>RCS file: /home/wine/wine/include/windef.h,v >>retrieving revision 1.103 >>diff -u -p -r1.103 windef.h >>--- include/windef.h 5 Jun 2006 12:29:21 -0000 1.103 >>+++ include/windef.h 8 Jun 2006 05:14:30 -0000 >>@@ -52,7 +52,12 @@ extern "C" { >> #ifndef __stdcall >> # ifdef __i386__ >> # ifdef __GNUC__ >>-# define __stdcall __attribute__((__stdcall__)) >>+# ifdef __APPLE__ >>+ /* Mac OSX uses 16-byte aligned stack and not a 4-byte one -- so we >>must realign on entry */ > > >Shouldn't this be #if defined __APPLE__ && defined __i386__? Isnt .. # ifdef __i386__ # ifdef __GNUC__ # ifdef __APPLE__ ... the same? (should it be more clear?) >>+# define __stdcall __attribute__((__stdcall__)) >>__attribute((force_align_arg_pointer)) >>+# else >>+# define __stdcall __attribute__((__stdcall__)) >>+# endif >> # elif defined(_MSC_VER) >> /* Nothing needs to be done. __stdcall already exists */ >> # else > > >-- >Rob Shearman - Nick

June 8, 2006

Re: Feedback requested on an OpenAL audio driver patch -- #2

by Nick Burns

Got ya will remove that when I send to the wine patch list >From: "James Hawkins" <truiken(a)gmail.com> >Subject: Re: Feedback requested on an OpenAL audio driver patch -- #2 >Date: Thu, 8 Jun 2006 10:03:19 -0700 > >On 6/8/06, Nick Burns <adger44(a)hotmail.com> wrote: >>Ok I fixed up my OpenAL driver as per the suggestions (thanks much) >> >>I am not sure how to use or test pkg-config (does that exist on Mac OSX?) >> >>The differences with the OpenAL driver patch... >>1. It has a perty ChangeLog diff > >You're not supposed to change ChangeLog; it's generated automatically. > >-- >James Hawkins - Nick

June 8, 2006

Re: wined3d: GLSL Patch feedback requested

by Nick Burns

That looks very impressive (good progress). I would have to look at the actual GLSL produced by this. The actual translation points look good. >From: "Jason Green" <jave27(a)gmail.com> >Date: Thu, 8 Jun 2006 11:54:04 -0400 > >By the way, here's a comparison screenshot of Civ4 from before my hard >drive failed, and this is without having texturing on pixel shaders >entirely working. Using GLSL (working completely for vertex shaders >2.0, at least the instructions that Civilization 4 used): > >http://cmhousing.net/wine/civ4_glsl.png > >compared to: > >http://cmhousing.net/wine/civ4_ingame2.png >and >http://cmhousing.net/wine/civ4_3.png > >with current git and using regular ARB shaders. > >So, we at least know that this is going to help. :-) > > >On 6/8/06, Jason Green <jave27(a)gmail.com> wrote: >>The current cumulative patch is located here: >> >>http://cmhousing.net/wine/glsl_cumul.diff >> >>(This includes the recently submitted "Split constant loading out of >>drawPrim()" patch, which hasn't been applied to git yet) >> >>Before submitting, I plan to fix the following things: >> >>- Fix relative addressing (it was working correctly, then I lost some >>stuff when my hard drive got corrupted, and now it's using R0 instead >>of A0 as the address register for some reason) >>- Switch the shader_reg_maps.constantsF[] to a CHAR array instead of a >>BOOL array (maybe even a bitmap(?)) >> >> >>This whole patchset should be a no-op for normal users, unless they >>have the UseGLSL registry key enabled. Here's a list of the >>changelogs that this cumulative patch entails, somewhat in the order >>that I'll be sending them: >> >> >>[already sent] Move constant loading out of DrawPrimDrawStrided() >>- DrawPrim is just too big of a function. This separates the passing >>of constants to the shader into new functions. >>- Fixes an off-by-one error when loading vertex declaration constants >>(should be <, not <=) >>- Adds a function for GLSL loading of constants (aka Uniforms) >>- Adds a GLSL program variable to the stateblock and sets it to 0 (a >>future patch will actually create this program) >> >>Add GLSL helper functions to device.c >>- Adds functions to attach & detach shader objects, create and delete >>programs, and maintain the list of programs. >>- Adds a list of GLSL shader programs to the device which is >>initialized on Init3D(), and deleted on Release() >> >>Add the bulk of the GLSL string generation functions >>- Add a new file glsl_shader.c which contains almost every GLSL >>specific function we'll need >>- Move print_glsl_info() into glsl_shader.c >>- Move the shader_reg_maps struct info into the private header, and >>make it part of SHADER_OPCODE_ARG. >>- Create a new shared ps/vs register map for float constants (future >>patch will make ARB programs use this, too) >>- This is a big patch, but none of the new functions in glsl_shader.c >>are being called yet. This just sets them up. >> >>Unified float constant register mapping between ARB pixel and vertex >>shaders. >>- Got rid of the separate constant maps. >> - Side effect of this is that the map is a bit larger for pixel >>shaders than it needs to be. >> - Will make this dynamic in a future patch. >> >>Added more declarations to GLSL in generate_glsl_declarations() >>- Declare more variable names for GLSL programs. >>- Correct output name for pixel shaders (gl_FragColor instead of >>glFragColor) >> >>Map pixel shader instructions to GLSL generating functions. >>- Also, delete the GLSL program when the refcount hits 0 >> >>Map vertex shader instructions to GLSL generating functions. >>- Also, delete the GLSL program when the refcount hits 0 >> >>Allow drawPrim to create and use the GLSL program >>- Now that we can fully create a GLSL program, this patch lets us >>actually use it. >> >> >>I would have submitted these all separate for review, but I have some >>janitorial git cleanup to do first to get all of this in the right >>order. - Nick

June 8, 2006

Re: appdb security

by Tobias Burnus

Hi, Jonathan Ernst schrieb: > Le jeudi 08 juin 2006 à 11:42 -0400, Chris Morgan a écrit : >> Can you come up with a non-destructive working example for the appdb >> website(appdb.winehq.org)? ;-) >> >> I ask because I thought we went through this some time ago but I agree that >> what you say looks like an open issue. >> >> Chris > > > Lately I used the following snippet in all my webapps to secure them > against sql injection : [...] Why don't you use mysql_escape_string(...)? http://de.php.net/manual/en/function.mysql-escape-string.php Tobias

June 8, 2006

Re: appdb security

by EA Durbin

I always use the method of filtering user input as described at the php security consortium. It makes it easier to track tainted user input vs filtered input. If all filtered variables are put in an array it makes it easier to ensure you're using the non tainted variable. http://phpsec.org/projects/guide/1.html#1.4 Then PEAR::DB to query the mysql database as PEAR::DB handles the SQL filtering. >From: Jonathan Ernst <jonathan(a)ernstfamily.ch> >To: wine-devel(a)winehq.com >Subject: Re: appdb security >Date: Thu, 08 Jun 2006 18:12:20 +0200 > >Le jeudi 08 juin 2006 à 11:42 -0400, Chris Morgan a écrit : > > Can you come up with a non-destructive working example for the appdb > > website(appdb.winehq.org)? ;-) > > > > I ask because I thought we went through this some time ago but I agree >that > > what you say looks like an open issue. > > > > Chris > > >Lately I used the following snippet in all my webapps to secure them >against sql injection : > >http://php.net/mysql_real_escape_string under "Best practice". > ><?php >function smart_quote($value) >{ > // Stripslashes > if (get_magic_quotes_gpc()) { > $value = stripslashes($value); > } > // Protect it if it's not an integer > if (!is_numeric($value)) { > $value = "'" . mysql_real_escape_string($value) . "'"; > } > return $value; >} > >// Secure query >$sQuery = sprintf("SELECT * > FROM users > WHERE user=%s AND password=%s", > smart_quote($_POST['username']), > smart_quote($_POST['password'])); >mysql_query($query); >?> > >I think it is better than what we have now in AppDB (didn't check it >though). If nobody looks at it, I'll check the code after my master >thesis (in one month). > >Jonathan ><< signature.asc >> >

June 8, 2006

Re: Feedback requested on an OpenAL audio driver patch -- #2

by James Hawkins

On 6/8/06, Nick Burns <adger44(a)hotmail.com> wrote: > Ok I fixed up my OpenAL driver as per the suggestions (thanks much) > > I am not sure how to use or test pkg-config (does that exist on Mac OSX?) > > The differences with the OpenAL driver patch... > 1. It has a perty ChangeLog diff You're not supposed to change ChangeLog; it's generated automatically. -- James Hawkins

June 8, 2006

Re: setupapi.dll: partially implement SetupDiGetClassDevsExA

by Mike McCormack

Peter Beutner wrote: > I thought they started auditing their code and removing any "dirty" parts? > And according to their website this process is nearly done. Unfortunately, the fallout of their audit process has been that many trusted developers left the project. For me, the main problem is that there are ReactOS developers who think that examining Windows assembly to write ReactOS code is a proper way to do things. > btw. using their code as documentation to implement something on wine > should be safe nevertheless, shouldn't it? I'd avoid their code if I were you. > hm I thought direct code sharing wasn't even possible before because of > the different licenses(GPL<->LGPL)? If the same people "came up with" the code in question, the license isn't relevant. IMO, the only legitimate thing to use would be their test cases, and there's only a few of those as far as I can tell. Mike

June 8, 2006

Re: setupapi.dll: partially implement SetupDiGetClassDevsExA

by Dmitry Timoshkov

"Peter Beutner" <p.beutner(a)gmx.net> wrote: >> Don't be suprised if your patch isn't accepted. ReactOS is considered a >> dirty reverse engineering project by many, and Alexandre has rejected >> patches using their code before. > I thought they started auditing their code and removing any "dirty" parts? At least for me their "auditing" mostly looks like a way to show to the outside world that they are considering to avoid dirty practices when they actually didn't change anything except public claims. > And according to their website this process is nearly done. What they want people should think about their project has nothing to do with real state of affairs. > btw. using their code as documentation to implement something on wine > should be safe nevertheless, shouldn't it? Not really IMO, nobody can hide their history, and all the things about attempts to compile stolen Windows sources and disassembling practices. -- Dmitry.

June 8, 2006

Re: appdb security

by Jonathan Ernst

Le jeudi 08 juin 2006 à 11:42 -0400, Chris Morgan a écrit : > Can you come up with a non-destructive working example for the appdb > website(appdb.winehq.org)? ;-) > > I ask because I thought we went through this some time ago but I agree that > what you say looks like an open issue. > > Chris Lately I used the following snippet in all my webapps to secure them against sql injection : http://php.net/mysql_real_escape_string under "Best practice". <?php function smart_quote($value) { // Stripslashes if (get_magic_quotes_gpc()) { $value = stripslashes($value); } // Protect it if it's not an integer if (!is_numeric($value)) { $value = "'" . mysql_real_escape_string($value) . "'"; } return $value; } // Secure query $sQuery = sprintf("SELECT * FROM users WHERE user=%s AND password=%s", smart_quote($_POST['username']), smart_quote($_POST['password'])); mysql_query($query); ?> I think it is better than what we have now in AppDB (didn't check it though). If nobody looks at it, I'll check the code after my master thesis (in one month). Jonathan

June 8, 2006

Re: setupapi.dll: partially implement SetupDiGetClassDevsExA

by Peter Beutner

Mike McCormack wrote: > Christian Gmeiner wrote: >> Partially implement SetupDiGetClassDevsExA. This patch bases on >> reactos setupapi.dll. > > Don't be suprised if your patch isn't accepted. ReactOS is considered a > dirty reverse engineering project by many, and Alexandre has rejected > patches using their code before. I thought they started auditing their code and removing any "dirty" parts? And according to their website this process is nearly done. btw. using their code as documentation to implement something on wine should be safe nevertheless, shouldn't it? > The fact that some developers work both on tinykrnl (a self-admitted > 'dirty' reverse engineering effort) and ReactOS at the same time should > be enough to show you that they're walking close to, or maybe over the > fine line. > > Please don't post ReactOS code to wine-patches again. hm I thought direct code sharing wasn't even possible before because of the different licenses(GPL<->LGPL)?

June 8, 2006

Re: Linux noob

by Molle Bestefich

Kuba Ober wrote: > Molle Bestefich wrote: > > Kuba Ober wrote: > > > > 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. > > > > Please insert relevant context when quoting. You're obviously > > misrepresenting what I said, turning it into something completely > > else, and then answering it. > > I don't know what did I misquote. That's the only thing relevant to my reply > that you said in that mail, and the previous paragraph from Mike didn't add > much as far as I can tell. Here: + I'm annoyed that .wine is inaccessible through KDE and Gnome apps. + + Not through the file manager, but often in various applications. I never said that any arbitrary KDE or Gnome app would fail, which is what is implied by only quoting / replying to the first line. > > That serves no purpose (other than annoying me). > > Sorry to have been annoying :( Well, sorry back at ya, thought you were doing it on purpose. Don't be sorry, probably my fault for inserting too many linefeeds or something, anyway. Never mind :-).

June 8, 2006

Re: appdb security

by Christoph Frick

On Thu, Jun 08, 2006 at 11:42:09AM -0400, Chris Morgan wrote: > Can you come up with a non-destructive working example for the appdb > website(appdb.winehq.org)? ;-) no ;P > I ask because I thought we went through this some time ago but I agree > that what you say looks like an open issue. if the magic quote thingy is turned on, then my code below wont do any harm (as the ' from the user input is turned into \'). well but there are other ways to inject code (e.g. encode the ' in some other way). at least a intval($_REQUEST['appId']) would be step in the right direction. > > > appId='"$_REQUEST['appId']."';"; > > with appId="' or 1=1;'"? -- cu

June 8, 2006

Re: wined3d: GLSL Patch feedback requested

by Jason Green

By the way, here's a comparison screenshot of Civ4 from before my hard drive failed, and this is without having texturing on pixel shaders entirely working. Using GLSL (working completely for vertex shaders 2.0, at least the instructions that Civilization 4 used): http://cmhousing.net/wine/civ4_glsl.png compared to: http://cmhousing.net/wine/civ4_ingame2.png and http://cmhousing.net/wine/civ4_3.png with current git and using regular ARB shaders. So, we at least know that this is going to help. :-) On 6/8/06, Jason Green <jave27(a)gmail.com> wrote: > The current cumulative patch is located here: > > http://cmhousing.net/wine/glsl_cumul.diff > > (This includes the recently submitted "Split constant loading out of > drawPrim()" patch, which hasn't been applied to git yet) > > Before submitting, I plan to fix the following things: > > - Fix relative addressing (it was working correctly, then I lost some > stuff when my hard drive got corrupted, and now it's using R0 instead > of A0 as the address register for some reason) > - Switch the shader_reg_maps.constantsF[] to a CHAR array instead of a > BOOL array (maybe even a bitmap(?)) > > > This whole patchset should be a no-op for normal users, unless they > have the UseGLSL registry key enabled. Here's a list of the > changelogs that this cumulative patch entails, somewhat in the order > that I'll be sending them: > > > [already sent] Move constant loading out of DrawPrimDrawStrided() > - DrawPrim is just too big of a function. This separates the passing > of constants to the shader into new functions. > - Fixes an off-by-one error when loading vertex declaration constants > (should be <, not <=) > - Adds a function for GLSL loading of constants (aka Uniforms) > - Adds a GLSL program variable to the stateblock and sets it to 0 (a > future patch will actually create this program) > > Add GLSL helper functions to device.c > - Adds functions to attach & detach shader objects, create and delete > programs, and maintain the list of programs. > - Adds a list of GLSL shader programs to the device which is > initialized on Init3D(), and deleted on Release() > > Add the bulk of the GLSL string generation functions > - Add a new file glsl_shader.c which contains almost every GLSL > specific function we'll need > - Move print_glsl_info() into glsl_shader.c > - Move the shader_reg_maps struct info into the private header, and > make it part of SHADER_OPCODE_ARG. > - Create a new shared ps/vs register map for float constants (future > patch will make ARB programs use this, too) > - This is a big patch, but none of the new functions in glsl_shader.c > are being called yet. This just sets them up. > > Unified float constant register mapping between ARB pixel and vertex shaders. > - Got rid of the separate constant maps. > - Side effect of this is that the map is a bit larger for pixel > shaders than it needs to be. > - Will make this dynamic in a future patch. > > Added more declarations to GLSL in generate_glsl_declarations() > - Declare more variable names for GLSL programs. > - Correct output name for pixel shaders (gl_FragColor instead of glFragColor) > > Map pixel shader instructions to GLSL generating functions. > - Also, delete the GLSL program when the refcount hits 0 > > Map vertex shader instructions to GLSL generating functions. > - Also, delete the GLSL program when the refcount hits 0 > > Allow drawPrim to create and use the GLSL program > - Now that we can fully create a GLSL program, this patch lets us > actually use it. > > > I would have submitted these all separate for review, but I have some > janitorial git cleanup to do first to get all of this in the right > order. >

June 8, 2006

Re: appdb security

by Chris Morgan

Can you come up with a non-destructive working example for the appdb website(appdb.winehq.org)? ;-) I ask because I thought we went through this some time ago but I agree that what you say looks like an open issue. Chris On Thursday 08 June 2006 11:35 am, Christoph Frick wrote: > On Thu, Jun 08, 2006 at 11:25:08AM -0400, Chris Morgan wrote: > > $sQuery = "Select versionId from appVersion where > > appId='"$_REQUEST['appId']."';"; > > > > Who's '' around $_REQUEST should prevent the string from being > > interpreted as anything but a single value passed as the value of appId. > > with appId="' or 1=1;'"?

June 8, 2006

wined3d: GLSL Patch feedback requested

by Jason Green

The current cumulative patch is located here: http://cmhousing.net/wine/glsl_cumul.diff (This includes the recently submitted "Split constant loading out of drawPrim()" patch, which hasn't been applied to git yet) Before submitting, I plan to fix the following things: - Fix relative addressing (it was working correctly, then I lost some stuff when my hard drive got corrupted, and now it's using R0 instead of A0 as the address register for some reason) - Switch the shader_reg_maps.constantsF[] to a CHAR array instead of a BOOL array (maybe even a bitmap(?)) This whole patchset should be a no-op for normal users, unless they have the UseGLSL registry key enabled. Here's a list of the changelogs that this cumulative patch entails, somewhat in the order that I'll be sending them: [already sent] Move constant loading out of DrawPrimDrawStrided() - DrawPrim is just too big of a function. This separates the passing of constants to the shader into new functions. - Fixes an off-by-one error when loading vertex declaration constants (should be <, not <=) - Adds a function for GLSL loading of constants (aka Uniforms) - Adds a GLSL program variable to the stateblock and sets it to 0 (a future patch will actually create this program) Add GLSL helper functions to device.c - Adds functions to attach & detach shader objects, create and delete programs, and maintain the list of programs. - Adds a list of GLSL shader programs to the device which is initialized on Init3D(), and deleted on Release() Add the bulk of the GLSL string generation functions - Add a new file glsl_shader.c which contains almost every GLSL specific function we'll need - Move print_glsl_info() into glsl_shader.c - Move the shader_reg_maps struct info into the private header, and make it part of SHADER_OPCODE_ARG. - Create a new shared ps/vs register map for float constants (future patch will make ARB programs use this, too) - This is a big patch, but none of the new functions in glsl_shader.c are being called yet. This just sets them up. Unified float constant register mapping between ARB pixel and vertex shaders. - Got rid of the separate constant maps. - Side effect of this is that the map is a bit larger for pixel shaders than it needs to be. - Will make this dynamic in a future patch. Added more declarations to GLSL in generate_glsl_declarations() - Declare more variable names for GLSL programs. - Correct output name for pixel shaders (gl_FragColor instead of glFragColor) Map pixel shader instructions to GLSL generating functions. - Also, delete the GLSL program when the refcount hits 0 Map vertex shader instructions to GLSL generating functions. - Also, delete the GLSL program when the refcount hits 0 Allow drawPrim to create and use the GLSL program - Now that we can fully create a GLSL program, this patch lets us actually use it. I would have submitted these all separate for review, but I have some janitorial git cleanup to do first to get all of this in the right order.

June 8, 2006

Re: appdb security

by Christoph Frick

On Thu, Jun 08, 2006 at 11:25:08AM -0400, Chris Morgan wrote: > $sQuery = "Select versionId from appVersion where > appId='"$_REQUEST['appId']."';"; > > Who's '' around $_REQUEST should prevent the string from being interpreted as > anything but a single value passed as the value of appId. with appId="' or 1=1;'"? -- cu

June 8, 2006

Re: Linux noob

by Kuba Ober

On Thursday 08 June 2006 09:02, Molle Bestefich wrote: > Kuba Ober wrote: > > > 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. > > Please insert relevant context when quoting. You're obviously > misrepresenting what I said, turning it into something completely > else, and then answering it. I don't know what did I misquote. That's the only thing relevant to my reply that you said in that mail, and the previous paragraph from Mike didn't add much as far as I can tell. > That serves no purpose (other than annoying me). Sorry to have been annoying :( > > > 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. > > Apparently, I am Er, I fail to see why some apps being broken is wine's problem. Directories with a dot preprended to their name are ubiquitous and it's fairly common to have to access them every once in a while. In all my years of using KDE-based RH/FC/Centos systems, I only had a *single* problem related to dot-directories. Specifically, it was the win4lin taking all dot-directories to be hidden, without a way of disabling that. I ended up patching the darn thing to fix that. I needed to unhide things so that either MS or Boland make build would go through. Later on I just switched to using wine for the builds -- it was faster that way as well, and I could fully automate things with my aegis repository. > AFAIR, I even had a crash in one app. Did you report it on their bugzilla/whatever? How is that wine's fault? > > > It's not wine's fault per se that those apps lack a "show hidden > > > folders" option > > Never said so. That wasn't me saying the >>> quoted thing either ;) > > I.e. no big deal. > > Right, slightly annoying but no big deal, as is often the case in open > source. ;) Cheers, Kuba

June 8, 2006

Recording with "Lexia" (mci "open new")

by Peter Åstrand

Hi, I've patched Wine to make recordings work in "Lexia" (http://www.lexia.just.nu/, currently down). When I started out, recordings didn't work, and I was getting traces like: trace:mci:mciSendStringW (L"open new type waveaudio alias capture", 0x7db2ebc8, 128, (nil)) fixme:mci:mciSendStringW 'new': NIY as device name trace:mci:mciSendStringW (L"set capture time format milliseconds bitspersample 16 samplespersec 22050 channels 1 bytespersec 44100 alignment 4", 0x7db92fa8, 128, (nil)) trace:mci:mciSendStringW (L"open capture wait", (nil), 0, (nil)) trace:mci:MCI_LoadMciDriver wDevID=0001 fixme:mci:MCI_LoadMciDriver Couldn't load driver for type L"CAPTURE". If you don't have a windows installation accessible from Wine, you perhaps forgot to create a [mci] section in system.ini trace:mci:mciSendStringW (L"record capture", 0x7db2ebc8, 128, (nil)) trace:mci:mciSendStringW (L"open capture wait", (nil), 0, (nil)) trace:mci:MCI_LoadMciDriver wDevID=0001 fixme:mci:MCI_LoadMciDriver Couldn't load driver for type L"CAPTURE". If you don't have a windows installation accessible from Wine, you perhaps forgot to create a [mci] section in system.ini I created the patch below, but eventually, it turned out that it's sufficient to add this to system.ini: [mci] CAPTURE=mciwave.dll In other words: With this change, recordings works despite mciSendStringW returning MCIERR_MISSING_DEVICE_NAME. Strange but true. To summarize: 1) I believe the mciwave.c patch below makes sense in any case, right? Without it freed memory is used. 2) Any ideas why "open new" works, even though MCIERR_MISSING_DEVICE_NAME is returned? 3) Most importantly: Why is it necessary to add CAPTURE to system.ini? Perhaps the "alias" argument isn't correctly handled? The patch: Index: dlls/winmm/mci.c =================================================================== RCS file: /home/wine/wine/dlls/winmm/mci.c,v retrieving revision 1.69 diff -u -r1.69 mci.c --- dlls/winmm/mci.c 23 May 2006 12:48:57 -0000 1.69 +++ dlls/winmm/mci.c 8 Jun 2006 12:53:43 -0000 @@ -1283,10 +1283,9 @@ /* case dev == 'new' has to be handled */ if (!strcmpW(dev, wszNew)) { - FIXME("'new': NIY as device name\n"); - dwRet = MCIERR_MISSING_DEVICE_NAME; - goto errCleanUp; - } + /* FIXME: Use temp file name. Remove after use. */ + dev = MCI_strdupAtoW("mcitemp.wav"); + } /* otherwise, try to grab devType from open */ if (!strcmpW(verb, wszOpen)) { Index: dlls/mciwave/mciwave.c =================================================================== RCS file: /home/wine/wine/dlls/mciwave/mciwave.c,v retrieving revision 1.2 diff -u -r1.2 mciwave.c --- dlls/mciwave/mciwave.c 23 May 2006 12:48:10 -0000 1.2 +++ dlls/mciwave/mciwave.c 8 Jun 2006 12:53:43 -0000 @@ -409,18 +409,19 @@ fn = HeapAlloc(GetProcessHeap(), 0, (lstrlenW(filename) + 1) * sizeof(WCHAR)); if (!fn) return MCIERR_OUT_OF_MEMORY; strcpyW(fn, filename); + /* Note: Frees filename as well */ HeapFree(GetProcessHeap(), 0, (void*)wmw->openParms.lpstrElementName); wmw->openParms.lpstrElementName = fn; - if (strlenW(filename) > 0) { + if (strlenW(fn) > 0) { /* FIXME : what should be done if wmw->hFile is already != 0, or the driver is playin' */ - TRACE("MCI_OPEN_ELEMENT %s!\n", debugstr_w(filename)); + TRACE("MCI_OPEN_ELEMENT %s!\n", debugstr_w(fn)); - wmw->hFile = mmioOpenW((LPWSTR)filename, NULL, + wmw->hFile = mmioOpenW((LPWSTR)fn, NULL, MMIO_ALLOCBUF | MMIO_DENYWRITE | MMIO_READ); if (wmw->hFile == 0) { - WARN("can't find file=%s!\n", debugstr_w(filename)); + WARN("can't find file=%s!\n", debugstr_w(fn)); dwRet = MCIERR_FILE_NOT_FOUND; } else Regards, -- Peter Åstrand ThinLinc Chief Developer Cendio http://www.cendio.se Teknikringen 3 583 30 Linköping Phone: +46-13-21 46 00

June 8, 2006

Re: [MAPI32 2/3] interface IProfAdmin & its 12 methods, function MAPIAdminProfiles implemented

by Alexandre Julliard

argentum(a)office.etersoft.ru writes: > +/************************************************************************** > + * IProfAdmin_GetLastError > + * > + * PARAMS > + * hResult [I] HRESULT data type containing the error value > + * generated in the previous method call. > + * lppMAPIError [O] Pointer to a pointer to the MAPIERROR structure > + * containing version, component, and context information > + * for the error. The lppMAPIError parameter can be set > + * to NULL if there is no MAPIERROR structure to return. > + * ulFlags [I] Bitmask of flags that controls the type of the string > + * pointed to by lpszProfileName. The following flag can be set: > + * 0 The strings in the structure returned in the pointer parameter > + * are in ANSI format > + * MAPI_UNICODE The structure's strings are in Unicode format. > + * RETURNS > + * S_OK The call succeeded and has returned the expected value or values. > + * MAPI_E_BAD_CHARWIDTH Either the MAPI_UNICODE flag was set and the implementation > + * does not support Unicode, or MAPI_UNICODE was not set and the > + * implementation only supports Unicode. > + */ Copying text from MSDN is not acceptable. If you are going to write documentation you have to do it in your own words, without looking at MSDN. -- Alexandre Julliard julliard(a)winehq.org

June 8, 2006

Re: setupapi.dll: partially implement SetupDiGetClassDevsExA

by Mike McCormack

Christian Gmeiner wrote: > Partially implement SetupDiGetClassDevsExA. This patch bases on reactos > setupapi.dll. Don't be suprised if your patch isn't accepted. ReactOS is considered a dirty reverse engineering project by many, and Alexandre has rejected patches using their code before. The fact that some developers work both on tinykrnl (a self-admitted 'dirty' reverse engineering effort) and ReactOS at the same time should be enough to show you that they're walking close to, or maybe over the fine line. Please don't post ReactOS code to wine-patches again. Mike

June 8, 2006

Re: configure: Fix test for ability to link with ICU libraries.

by Alexandre Julliard

Scott Bambrough <scottb(a)xandros.com> writes: > @@ -603,8 +603,8 @@ if test "$ac_cv_header_unicode_ubidi_h" > then > saved_libs="$LIBS" > ICU_LIB_DIR="${ICU_LIB_DIR-/usr/lib}" > - ICUUC_LIB="${ICUUC_LIB-$ICU_LIB_DIR/libsicuuc.a}" > - ICUDATA_LIB="${ICUDATA_LIB-$ICU_LIB_DIR/libsicudata.a}" > + ICUUC_LIB="${ICUUC_LIB-$ICU_LIB_DIR/libicuuc.a}" > + ICUDATA_LIB="${ICUDATA_LIB-$ICU_LIB_DIR/libicudata.a}" The libraries have different names on different setups, that's why there are environment variables you can set. If you want a better fix you need to make configure probe for the various names. -- Alexandre Julliard julliard(a)winehq.org

June 8, 2006

Re: Linux noob

by Molle Bestefich

Kuba Ober wrote: > > 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. Please insert relevant context when quoting. You're obviously misrepresenting what I said, turning it into something completely else, and then answering it. That serves no purpose (other than annoying me). > > 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. Apparently, I am. AFAIR, I even had a crash in one app. > > It's not wine's fault per se that those apps lack a "show hidden > > folders" option Never said so. > KDE applications hopefully use KDE's open/save dialog, and there it's a matter > of pressing F8 to hide/unhide hidden files. Nice. > I.e. no big deal. Right, slightly annoying but no big deal, as is often the case in open source.

June 8, 2006

Re: Feedback requested for Mac OSX x86 stack patch -- #2

by Robert Shearman

Nick Burns wrote: > diff -u -p -r1.114 ChangeLog > --- ChangeLog 24 May 2006 18:09:06 -0000 1.114 > +++ ChangeLog 8 Jun 2006 07:06:10 -0000 > @@ -1,3 +1,8 @@ > +2006-06-08 Nick Burns <adger44(a)hotmail.com> > + > + * include/windef.h: > + If on Mac OSX (x86) use force_align_arg_pointer to fix the > stack on entry to Wine. > + > 2006-05-24 Alexandre Julliard <julliard(a)winehq.org> > > * dlls/usp10/tests/usp10.c: You don't need to patch ChangeLog; it is update each release from GIT history. Just include the text you want in the change log in the email you send the patch with. > Index: include/windef.h > =================================================================== > RCS file: /home/wine/wine/include/windef.h,v > retrieving revision 1.103 > diff -u -p -r1.103 windef.h > --- include/windef.h 5 Jun 2006 12:29:21 -0000 1.103 > +++ include/windef.h 8 Jun 2006 05:14:30 -0000 > @@ -52,7 +52,12 @@ extern "C" { > #ifndef __stdcall > # ifdef __i386__ > # ifdef __GNUC__ > -# define __stdcall __attribute__((__stdcall__)) > +# ifdef __APPLE__ > + /* Mac OSX uses 16-byte aligned stack and not a 4-byte one -- so > we must realign on entry */ Shouldn't this be #if defined __APPLE__ && defined __i386__? > +# define __stdcall __attribute__((__stdcall__)) > __attribute((force_align_arg_pointer)) > +# else > +# define __stdcall __attribute__((__stdcall__)) > +# endif > # elif defined(_MSC_VER) > /* Nothing needs to be done. __stdcall already exists */ > # else -- Rob Shearman

June 8, 2006

Re: Feedback requested for Mac OSX x86 stack patch

by Robert Shearman

Nick Burns wrote: > I tried using winapi_check, winapi_test, winapi_... > They all seemed to give me some odd perl errors (missing defs/funcs in > config.pm that WERE there and were also in setup.pm) > So... I stupidly went thru and made the relevant files work by copying > and pasting the functions and changing def imports to setup.pm (what a > pain that was -- as i dont know perl) > I am guessing this should just WORK... > > It seems like it would be a good idea to go thru the msvcrt functions > and label the exports as > WINAPIV (or __cdecl) -- im not sure what the desired convention is. WINAPIV is purely for vararg functions and might not match the calling conventions of msvcrt on other platforms. You should label them with CDECL instead, as Alexandre suggested. -- Rob Shearman

June 8, 2006

RE: Feedback requested on an OpenAL audio driver patch -- #2

by Nick Burns

(the elusive attachment) It helps when I hit the attach button (sorry) - Nick

June 8, 2006

Feedback requested for Mac OSX x86 stack patch -- #2

by Nick Burns

Ok I have fixed up my Mac OSX stack patch a bit as per the feedback -- thanks much This only patches windef.h There still needs to be some solution for msvcrt AND any other api entry points that are not denoted with __stdcall or __cdecl or WINAPI or WINAPIV.... This means that Morrowwind (uses msvcrt:pow just cause) will crash on OSX atm (bad alignment) - Nick

June 8, 2006

Feedback requested on an OpenAL audio driver patch -- #2

by Nick Burns

Ok I fixed up my OpenAL driver as per the suggestions (thanks much) I am not sure how to use or test pkg-config (does that exist on Mac OSX?) The differences with the OpenAL driver patch... 1. It has a perty ChangeLog diff 2. configure.ac now checks for AL/al.h (which is where OpenAL should be) 3. dlls/Makefile.in should patch correctly now (I did not hand edit it this time -- still crossing fingers) 4. FIXME's -> ERR's for the legit OpenAL errs 5. alcCloseDevice in OpenAL 1.0 (no return value) in 1.1 it returns a boolean -- .: I dont check the boolean anymore -- meaning this error is now slient - Nick

June 8, 2006

Re: Feedback requested on an OpenAL audio driver patch

by Marcus Meissner

On Wed, Jun 07, 2006 at 09:36:35PM -0700, Nick Burns wrote: > >From: Leon Freitag <leon_fraitak(a)mail.ru> > >Date: Wed, 7 Jun 2006 12:09:36 +0200 > > > >P.S. Isn't it better to use pkg-config to check where the libs are located > >anyway? > >Leon > > Is there an example of this? Yes, see the libxml2 checks. Ciao, Marcus

June 8, 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 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. Ok makes sense... (I didnt notice the spec file before) > > 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. I tried using winapi_check, winapi_test, winapi_... They all seemed to give me some odd perl errors (missing defs/funcs in config.pm that WERE there and were also in setup.pm) So... I stupidly went thru and made the relevant files work by copying and pasting the functions and changing def imports to setup.pm (what a pain that was -- as i dont know perl) I am guessing this should just WORK... It seems like it would be a good idea to go thru the msvcrt functions and label the exports as WINAPIV (or __cdecl) -- im not sure what the desired convention is. >-- >Alexandre Julliard >julliard(a)winehq.org - Nick

June 8, 2006

Re: Feedback requested for Mac OSX x86 stack patch

by Nick Burns

>From: Alexandre Julliard <julliard(a)winehq.org> >Date: Wed, 07 Jun 2006 11:40:42 +0200 > >"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. Ok I will reform my patch to be ... extra inclusive... I will modify cdecl and stdcall to use stack realignment I will not have any modifications to msvcrt (at least not yet) I will leave the redefinitions alone for the time being... >-- >Alexandre Julliard >julliard(a)winehq.org - Nick

June 7, 2006

Re: Feedback requested on an OpenAL audio driver patch

by Nick Burns

>From: Leon Freitag <leon_fraitak(a)mail.ru> >Date: Wed, 7 Jun 2006 12:07:32 +0200 > > > 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. Whoops typo -- al/al.h is wrong -- it should be AL/al.h (fixed in next patch) >Also patching dlls/makefile.in fails. Had to patch it manually. This is probably cause I hand edited the patch diff... I will redo this in the next patch. (fixed in next patch) >Leon - Nick

June 7, 2006

Re: Feedback requested on an OpenAL audio driver patch

by Nick Burns

>From: Leon Freitag <leon_fraitak(a)mail.ru> >Date: Wed, 7 Jun 2006 12:09:36 +0200 > >P.S. Isn't it better to use pkg-config to check where the libs are located >anyway? >Leon Is there an example of this? - Nick

June 7, 2006

Re: Feedback requested on an OpenAL audio driver patch

by Nick Burns

>From: Leon Freitag <leon_fraitak(a)mail.ru> >Date: Wed, 7 Jun 2006 15:54:49 +0200 > >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) Grr -- OpenAL 1.0 spec does not return anything there (Thanks good catch) This means I cannot check errors on device closing... (fixed will e in next patch) >2) It'd be better to convert ALC errors from FIXMEs to ERRs. Will do -- I was just used to FIXME... Hehe at first (as I was implementing) they were fixme for real! Now they are openal failures. (fixed will be in next patch) >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. It should do a -lopenal -- looking at configure.ac 'if test "$ac_cv_header_al_al_h" = "yes" then dnl OpenAL framework AC_SUBST(OPENAL,"-lopenal") fi' Makefile.in 'EXTRALIBS = $(LIBUUID) @OPENAL@' Could be related to 4... (should work in next patch due to fix in 4) >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. Whoops -- its SUPPOSED to be AL/al.h -- I typoed! (fixed in configure.ac -- will be sending new patch) >Leon Thanks for the feedback! -- all the way from Russia - Nick

June 7, 2006

Re: Feedback requested on an OpenAL audio driver patch

by Nick Burns

>From: Robert Reif <reif(a)earthlink.net> >Date: Wed, 07 Jun 2006 20:55:58 -0400 > >Nick Burns wrote: > >> >>It seemed to work well for GTA3, Tribes2 and FlatOut(requires a binary >>patch to run) (dsound) -- and for SndRec32 (win/wout) >>(Games and ...App... tested under Mac OSX x86 -- Mac Book Pro) > >How do the winmm and dsound regression tests work when run in the >interactive mode? > I did not know these tests existed -- cool... So I ran dsound_test and winmm_test (interactive mode?) on the command line There are some failures -- but no crashing Some games like Carmageddon2 are unhappy with openal atm. - Nick

June 7, 2006

Re: [KERNEL 1/2] changed test for function FindFirstFileA to find dosdevices

by Vitaliy Margolen

Wednesday, June 7, 2006, 9:03:43 AM, Konstantin Petrov wrote: > changed test for function FindFirstFileA to find dosdevices. > As function FindFirstFile must accept such paths as > "c:\\windows\\win.ini" > "c:\\NUL", > "c:\\COM1", > "c:\\LPT1", > "c:\\LPT9", > "c:\\COM9", > "c:\\CON", > "c:\\AUX", > "c:\\PRN" > and mustn't accept paths: > "\\\\.\\CON", > "c:\\COM0", > "", > "c:\\LPT0", That's because you have only one serial and one parallel port. The special name is the special name. It's different how win9x and winNT handles them. Which system have you ran these tests on? Vitaliy Margolen

June 7, 2006

Re: Feedback requested on an OpenAL audio driver patch

by Robert Reif

Nick Burns wrote: > > It seemed to work well for GTA3, Tribes2 and FlatOut(requires a binary > patch to run) (dsound) -- and for SndRec32 (win/wout) > (Games and ...App... tested under Mac OSX x86 -- Mac Book Pro) How do the winmm and dsound regression tests work when run in the interactive mode?

June 7, 2006

Re: Yet another round of redundand NULL checks before HeapFree (found by Smatch).

by Michael Stefaniuc

Please disregard this patch as a false positive crept in. Michael Stefaniuc wrote: > hopefully this should be the last round of redundand NULL checks before > HeapFree removals. I know, famous last words. But this time i have > extended the redundant_null_check.pl Smatch script to find all non-null > variables from arbitrary complex if-expressions and check that any of > them dosn't get HeapFree'd on the truth path. > diff --git a/dlls/msacm32/driver.c b/dlls/msacm32/driver.c > index e537bc4..bec3526 100644 > --- a/dlls/msacm32/driver.c > +++ b/dlls/msacm32/driver.c > @@ -587,7 +587,7 @@ MMRESULT WINAPI acmDriverOpen(PHACMDRIVE > return MMSYSERR_NOERROR; > gotError: > WARN("failed: ret = %08x\n", ret); > - if (pad && !pad->hDrvr) > + if (!pad->hDrvr) nice NULL pointer dereference. > HeapFree(MSACM_hHeap, 0, pad); > return ret; > } 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

Re: shell32: Write-strings warning fix

by Andrew Talbot

Andrew Talbot wrote: > Robert Shearman wrote: >> 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. > > A MENUITEMINFOA's dwTypeData is currently declared as writeable (LPSTR); > what it is initialised from will not affect that. Sorry. On reflection, I see that my thinking was faulty: I now realise that the structure member points to the initialising or assigning string - rather than getting a copy of the data from it - so the writeability of the latter does matter. -- Andy.

June 7, 2006

Re: shell32: Write-strings warning fix

by Andrew Talbot

Robert Shearman wrote: > 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. A MENUITEMINFOA's dwTypeData is currently declared as writeable (LPSTR); what it is initialised from will not affect that, but initialising it from a non-const array does prevent a write-strings warning. So, assuming that one eventual aim is to add -Wwrite-strings and -Wcast-qual to the make flags, string variables that can be constified should be, and ones that cannot (for example, because they must conform to the SDK) need to be initialised from non-const sources, to reduce compiler noise. I consider this variable to be constrained to remain writeable by compatibility issues; otherwise, the best solution would be to declare it to be of type LPCSTR. > It is therefore better to cast it from a "const char *" > into a "char *" A statement like char *s = (char *) "string"; would raise a cast-qual warning, when that flag gets turned on. > or to make it a non-static array at the top of the > function. > My assumption, in declaring such a string-variable static, is that, for functions that get called repeatedly, microseconds will be saved on the second and each subsequent invocation, since the local variable will not suffer repeated assignments of an invariant value. (Big deal? Maybe, but harmless.) However, I think it is irrelevant to the issue in hand. -- Andy.

June 7, 2006

Re: Linux noob

by Andreas Mohr

On Wed, Jun 07, 2006 at 11:17:12AM -0400, Kuba Ober wrote: > 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 Andreas Mohr

June 7, 2006