January 2005 - Wine-Devel - list.winehq.org

Re: Minor wine-devel DCOM corrections
by Dan Kegel Jan. 11, 2005

Jan. 11, 2005

Rob Shearman wrote: > We have a number of marshaling tests in our test framework at the moment > (in wine/dlls/ole32/tests/marshal.c). It is hard to do anything > cross-process (or cross-machine!) because of the way the test framework > is done. Mike did suggest using environment variables to hack around > those limitations, but so far that hasn't turned into any code from > either of us. Hey, that's not a bad idea. You could set an environment variable, then rerun the same program with the same arguments, and your test could sense the environment variable and run the 2nd process's test role. Is there a generic win32 way to run yourself again with the same arguments? If not, it'd probably only take a little tweaking of include/wine/test.h to set one up... - Dan -- Trying to get a job as a c++ developer? See http://kegel.com/academy/getting-hired.html

2 1

Re: Correction to COINIT_MULTITHREADED test
by Paul Vriens Jan. 11, 2005

Jan. 11, 2005

On Mon, 2005-01-10 at 21:20, Bill Medland wrote: > Bill Medland (billmedland(a)mercuryspeed.com) > Correct testing for multithreaded > (as spotted by Paul Vriens; fix suggested by Robert Shearman) > Hi Bill, it wasn't the check that was way over my head. The thing is, that with this code change we walk a new path in COM_CreateApartment. I don't know what the result is but in CoInitializeEx we do: 545 if (!(apt = COM_CurrentInfo()->apt)) 546 { 547 apt = COM_CreateApartment(dwCoInit); 548 if (!apt) return E_OUTOFMEMORY; 549 } and apparently that leaves us with a E_OUTOFMEMORY all the time. Which means that we will not come to the part: 559 COM_CurrentInfo()->inits++; and that leads to errors as: trace:ole:CoInitializeEx ((nil), 4) trace:ole:COM_CreateApartment thread 0xd is entering the multithreaded apartment trace:ole:CoInitializeEx ((nil), 2) err:ole:CoInitializeEx Attempt to change threading model of this apartment from 0x0 to 0x2 which also shows that the check is wrong. When CoInitializeEx is called with COINIT_DISABLE_OLE1DDE it shouldn't go in. What MSDN also says is: Any combination of values from the COINIT enumeration can be used, except that the COINIT_APARTMENTTHREADED and COINIT_MULTITHREADED flags cannot both be set. So should that be accounted for as well? Cheers, Paul.

1 0

comctl32.dll and commctrl.dll
by Dripple Jan. 11, 2005

Jan. 11, 2005

Hi all, I'm a newbie in wine using and wine developpement. I just need information about comctl32.dll and commctrl.dll. I'm trying to have this app (http://appdb.winehq.org/appview.php?appId=1485&versionId=2451) working. In fact, it works. But only using native comctl32.dll, which requires native commctrl.dll. Can anybody explain me what's missing in buitlin comctl32.dll and/or commctrl.dll ? Is it planned to fix commctrl.dll, to avoid piracy ? Thanks. Dripple

5 7

Re: advpack: add two missing stubs
by Robert Reif Jan. 11, 2005

Jan. 11, 2005

Rob Shearman wrote: > > I think you forgot to include the tests. > > Rob > Past my bed time. diff -u -N wine.cvs/dlls/advpack/tests/advpack.c wine/dlls/advpack/tests/advpack.c --- wine.cvs/dlls/advpack/tests/advpack.c 1969-12-31 19:00:00.000000000 -0500 +++ wine/dlls/advpack/tests/advpack.c 2005-01-10 22:54:50.000000000 -0500 @@ -0,0 +1,66 @@ +/* + * Unit tests for advpack.dll + * + * Copyright (c) 2005 Robert Reif + * + * This library is free software; you can redistribute it and/or + * modify it under the terms of the GNU Lesser General Public + * License as published by the Free Software Foundation; either + * version 2.1 of the License, or (at your option) any later version. + * + * This library is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU + * Lesser General Public License for more details. + * + * You should have received a copy of the GNU Lesser General Public + * License along with this library; if not, write to the Free Software + * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA + */ + +#define NONAMELESSSTRUCT +#define NONAMELESSUNION +#include <windows.h> + +#include "wine/test.h" +#include "advpub.h" + +static void version_test() +{ + HRESULT hr; + DWORD major, minor; + + major = minor = 0; + hr = GetVersionFromFile("kernel32.dll", &major, &minor, FALSE); + ok (hr == S_OK, "GetVersionFromFileEx(kernel32.dll) failed, returned " + "0x%08lx\n", hr); + + trace("kernel32.dll Language ID: 0x%08lx, Codepage ID: 0x%08lx\n", + major, minor); + + major = minor = 0; + hr = GetVersionFromFile("kernel32.dll", &major, &minor, TRUE); + ok (hr == S_OK, "GetVersionFromFileEx(kernel32.dll) failed, returned " + "0x%08lx\n", hr); + + trace("kernel32.dll version: %d.%d.%d.%d\n", HIWORD(major), LOWORD(major), + HIWORD(minor), LOWORD(minor)); +} + +static void admin_test() +{ + BOOL res; + DWORD reserved; + + res = IsNTAdmin(0, &reserved); + ok (res == TRUE || res == FALSE, "IsNTAdmin returned: 0x%08x\n", res); + + trace("IsNTAdmin = %s\n", res == TRUE ? "TRUE" : res == FALSE ? "FALSE" : + "???"); +} + +START_TEST(advpack) +{ + version_test(); + admin_test(); +} diff -u -N wine.cvs/dlls/advpack/tests/.cvsignore wine/dlls/advpack/tests/.cvsignore --- wine.cvs/dlls/advpack/tests/.cvsignore 1969-12-31 19:00:00.000000000 -0500 +++ wine/dlls/advpack/tests/.cvsignore 2005-01-10 21:17:35.000000000 -0500 @@ -0,0 +1,3 @@ +Makefile +advpack.ok +testlist.c diff -u -N wine.cvs/dlls/advpack/tests/Makefile.in wine/dlls/advpack/tests/Makefile.in --- wine.cvs/dlls/advpack/tests/Makefile.in 1969-12-31 19:00:00.000000000 -0500 +++ wine/dlls/advpack/tests/Makefile.in 2005-01-10 21:07:22.000000000 -0500 @@ -0,0 +1,13 @@ +TOPSRCDIR = @top_srcdir@ +TOPOBJDIR = ../../.. +SRCDIR = @srcdir@ +VPATH = @srcdir@ +TESTDLL = advpack.dll +IMPORTS = advpack user32 kernel32 version + +CTESTS = \ + advpack.c + +(a)MAKE_TEST_RULES@ + +### Dependencies:

1 0

Re: [LOSTWAGES] Add regedit janitorial project
by Michael Stefaniuc Jan. 10, 2005

Jan. 10, 2005

Mike McCormack wrote: > > ChangeLog: > * Add regedit janitorial project > > ------------------------------------------------------------------------ > > > Janitorial Projects > > Any self respecting project has a Janitorial project (e.g. Kernel > Janitor's List <http://janitor.kernelnewbies.org>), and it's high time > that we have one too. What is there to clean up? Well, lots of things! :) > > > Regedit fixes > > Regedit lacks a few features. We need to improve regedit to: > > * Allow display and editting of binary (REG_BINARY) values. > * Allow display and editting of multi-string (REG_SZ_MULTI) values. > * Import registry files regerated by Windows 2000 regedit Are you sure this is a janitorial project? It sounds to me more like a normal development work and not janitorial. It would better fit into "tasks" or the "todo" lists. bye michael -- Michael Stefaniuc Tel.: +49-711-96437-199 System Administration Fax.: +49-711-96437-111 Red Hat GmbH Email: mstefani(a)redhat.com Hauptstaetterstr. 58 http://www.redhat.de/ D-70178 Stuttgart

4 4

Fwd: Foobar2000 audio player Regression
by Nick Hornback Jan. 10, 2005

Jan. 10, 2005

I originally posted this to the -users list, but I was contacted by Robbert Xerox, who had the exact same issue, and thus far nobody has replyed in the users list, so maybe it will get more attention here. > Foobar2000 worked virtually perfectly in the 20041019 > release (aside from some comctrl32 repainting issues > -- which native comctrl32.dll fixed), but in 20041201 > it is completely unuseable. Two major problems: > 1) The toolbars are completely gone. They are sort-of > displayed when they get activity via mouse-press or > whatever, but they do not repaint correctly at all. > See this screenshot for details: > http://img20.exs.cx/my.php?loc=img20&image=w1ifoobar.gif > 2) It takes 100% cpu. In the 20041021 release, it > hovered around 5% cpu (on my athlon 64 3200+), which > was excellent because that beat most native linux > audio players. > The console log is as follows (no errors or warnings): > fixme:hook:NotifyWinEvent (32780,0x10026,-4,1)-stub! > fixme:hook:NotifyWinEvent (32780,0x10026,-4,1)-stub! > fixme:hook:NotifyWinEvent (32780,0x10026,-4,2)-stub! > fixme:hook:NotifyWinEvent (32772,0x1002a,-4,0)-stub! > fixme:hook:NotifyWinEvent (32772,0x1002c,-4,0)-stub! > fixme:win:SetWindowTextA cannot set text "" of other > process window (nil) > Does anyone know what is going on here? I have since found out that if you use a the builtin comctrl32.dll, none of the window repaints at all. In previous wine releases, using the builtin comctrl32.dll would just create minor glitches (ex. the status bar wouldn't update). __________________________________ Do you Yahoo!? Yahoo! Mail - Helps protect you from nasty viruses. http://promotions.yahoo.com/new_mail

4 6

RtlQueryRegistryValues implementation, probably not prefect but makes safedisc happy
by Ivan Leo Puoti Jan. 10, 2005

Jan. 10, 2005

I've attempted to implement RtlQueryRegistryValues() This code is probably buggy, as I haven't tested it much, but it makes safedisc happy. If it's OK I'll send a patch to add it to ntdll, ntoskrnl will then forward calls. comments/corrections/thoughts welcome. Ivan.

1 0

Warnings left when compiling on GNU/Linux
by Gerald Pfeifer Jan. 10, 2005

Jan. 10, 2005

When compiling on SUSE LINUX 9.2 using GCC 3.3.5 the following are the only warnings I'm getting for current Wine CVS: metafile.c:395: warning: `test_mf_PatternBrush' defined but not used rtlstr.c:552: warning: `test_RtlUpcaseUnicodeChar' defined but not used rtlstr.c:578: warning: `test_RtlUpcaseUnicodeString' defined but not used rtlstr.c:629: warning: `test_RtlDowncaseUnicodeString' defined but not used hlp2sgml.c:219: warning: `%x' yields only last 2 digits of year in some locales On FreeBSD 4.10 using GCC 3.3.4 I am also seeing the following one: fd.c:572: warning: right shift count >= width of type fd.c:574: warning: right shift count >= width of type Any chance we could get rid of these? :-) Gerald

5 5

ole32 : wrong check in compobj.c
by Paul Vriens Jan. 10, 2005

Jan. 10, 2005

Hi, while looking through the code I saw: if (model & COINIT_MULTITHREADED) this will never work as COINIT_MULTITHREADED = 0. The attached patch fixes the 3 occurrences of a check against COINIT_*. This patch however makes the COM_CreateApartment in compobj.c: 545 if (!(apt = COM_CurrentInfo()->apt)) 546 { 547 apt = COM_CreateApartment(dwCoInit); 548 if (!apt) return E_OUTOFMEMORY; 549 } return E_OUTOFMEMORY, always (?). And that makes sure that we have a mismatch between CoInitialize and CoUninitialize. So there's definitely something else wrong as well. Any idea ? Cheers, Paul.

3 4

Re: Minor wine-devel DCOM corrections
by Mike Hearn Jan. 10, 2005

Jan. 10, 2005

On Mon, 10 Jan 2005 10:56:30 -0800, Bill Medland wrote: > Bill Medland (billmedland(a)mercuryspeed.com) > Minor typo correction and term expansion changes Bill, if that document was helpful I'll write some more docs for you.

3 3

Use Interlocked* functions
by Joris Huizer Jan. 10, 2005

Jan. 10, 2005

To see how far we are, I tried grepping to get This->refs stuff grep -r -n -e 'TRACE(.*This->ref)' * grep -r -n "++(This->ref)" * grep -r -n -- "--(This->ref)" * I hope there are a lot of false positives there :-/ regards, Joris

5 7

Re: ntdll / kernel32 : #52 (take #2)
by Alexandre Julliard Jan. 10, 2005

Jan. 10, 2005

Eric Pouech <pouech-eric(a)wanadoo.fr> writes: > +/****************************************************************** > + * NtAddAtom (NTDLL.@) > + */ > +NTSTATUS WINAPI NtAddAtom( const WCHAR* name, ULONG name_len, ATOM* atom ) > +{ > + return RtlAddAtomToAtomTable( get_global_table(), name, atom ); > +} You can't do that, if the name is a counted string you cannot ignore the length and assume it is null-terminated. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: Give a more informative error when a DLL fails to initialize
by Mike Hearn Jan. 10, 2005

Jan. 10, 2005

Hi Alexandre, This patch was missed, does it no longer apply? Also is it OK to just put the changelog as the first line of the email like that? thanks -mike On Wed, 22 Dec 2004 18:19:47 +0000, Mike Hearn wrote: > Give a more informative error when a DLL fails to initialize > --- dlls/ntdll/loader.c (revision 3) > +++ dlls/ntdll/loader.c (local) > @@ -893,9 +893,14 @@ static NTSTATUS process_attach( WINE_MOD > WINE_MODREF *prev = current_modref; > current_modref = wm; > if (MODULE_InitDLL( wm, DLL_PROCESS_ATTACH, lpReserved )) > + { > wm->ldr.Flags |= LDR_PROCESS_ATTACHED; > + } > else > + { > + ERR("Initialization of %s failed\n", debugstr_w(wm->ldr.BaseDllName.Buffer)); > status = STATUS_DLL_INIT_FAILED; > + } > current_modref = prev; > }

3 4

Re: WININET: implement InternetTime{From,To}SystemTime{A,W} (#2)
by Dmitry Timoshkov Jan. 10, 2005

Jan. 10, 2005

"Hans Leidekker" <hans(a)it.vu.nl> wrote: > Changelog: > Implement and test InternetTime{From,To}SystemTime{A,W}. If you could also make the attached tests pass (applied over your tests) that would be great. The tests show that strings should be parsed a bit smarter and comparisons should be case insensitive. -- Dmitry.

1 0

Re: Janitorial : Use Compiler Warnings ( -Wmissing-declarations ) ( #1 )
by Alexandre Julliard Jan. 10, 2005

Jan. 10, 2005

Rémi Assailly <remi.assailly(a)free.fr> writes: > --- include/wine/library.h 2005-01-07 19:41:26.000000000 +0100 > +++ include/wine/library.h 2005-01-07 19:49:41.389057824 +0100 > @@ -42,6 +42,7 @@ > extern void *wine_dlopen( const char *filename, int flag, char *error, int errorsize ); > extern void *wine_dlsym( void *handle, const char *symbol, char *error, int errorsize ); > extern int wine_dlclose( void *handle, char *error, int errorsize ); > +extern void __wine_dll_register( const IMAGE_NT_HEADERS *header, const char *filename ); Functions starting with '__wine' are internal only and must not be declared in the public headers if it can be avoided. -- Alexandre Julliard julliard(a)winehq.org

2 2

Switching to winecfg
by Crestez Leonard Jan. 10, 2005

Jan. 10, 2005

As winecfg gets better and better I think it's time to consider making it actually change the config file. I made a patch for it, but it's a work in progress, and not ready for general use. I don't expect you to commit it, so I sent it here for discussion. I don't think that this needs a complex migration process, all we need to do is save the wine config registry to $WINEPREFIX/config. If people want their config file back, wine can skip saving the configuration if it wasn't modified. This will allow comments to persist in the config file. Anyway, regedit is better than editing a config file. In writing this patch I came across some strange stuff in server/registry.c. What's the point of all the save level stuff? current_level is only set once to 1, on initialization, and save_level depends on whether registry branches should be saved only when modified (can anyone think of a reason to disable that feature?). Can't the KEY_DIRTY bit be used instead of this level stuff? Also update_level seems to be dead code, not called from anywhere. Please tell me what you think about the patch. -- Crestez Leonard <cleonard(a)go.ro>

2 1

Re: WININET: implement InternetTime{From,To}SystemTime{A,W} (#2)
by Alexandre Julliard Jan. 10, 2005

Jan. 10, 2005

Hans Leidekker <hans(a)it.vu.nl> writes: > +/*********************************************************************** > + * InternetTimeFromSystemTimeW (WININET.@) > + * > + * NOTES > + * This is not an illegal W->A crosscall since internet dates are ASCII strings. It would still be much cleaner to have the A function call the W one. -- Alexandre Julliard julliard(a)winehq.org

1 0

typelib2.c problems
by Gerald Pfeifer Jan. 10, 2005

Jan. 10, 2005

The following change to dlls/oleaut32/typelib2.c revision 1.32 date: 2005/01/09 17:32:17; author: julliard; state: Exp; lines: +14 -14 Paul Vriens <Paul.Vriens(a)xs4all.nl> - use Interlocked* functions in AddRef and Release. - store the result of the Interlocked functions and use only this. causes the following warnings on SUSE LINUX 9.2 and FreeBSD: typelib2.c:3012: warning: passing arg 1 of `InterlockedIncrement' from incompatible pointer type typelib2.c:3027: warning: passing arg 1 of `InterlockedDecrement' from incompatible pointer type Would you mind fixing this? Gerald

1 0

dcom95.exe removed from sf.net
by Jeremy Newman Jan. 10, 2005

Jan. 10, 2005

Somebody removed dcom95.exe from sf.net. Was there a reason for that? We really need to keep that file mirrored. It's an essential file for many programs to run under wine. I've re-added the file as a hidden file for the moment. It won't show up in the download list, but we can still link to it.

8 18

Re: German language files
by Mike McCormack Jan. 10, 2005

Jan. 10, 2005

Thanks for the translations, however please read: http://www.winehq.org/site/sending_patches You should send patches, not zip files. Diff against the current WineHQ CVS, not ReactOS. Diff new files against /dev/null. eg. diff /dev/null dlls/shell32/shell32_De.rc Your changes are unlikely to be accepted as they are. There's only one person processing WineHQ patches. If you keep the submissions uniform it reduces his workload. Mike Klemens Friedl wrote:> > Please add the files to the wine directory. Thanks! > > > Klemens Friedl <frik85>

1 0

Re: USER32: result of ScrollBar functions review (4th try)
by Alexandre Julliard Jan. 9, 2005

Jan. 9, 2005

Vitaly Lipatov <lav(a)etersoft.ru> writes: > @@ -1728,12 +1821,15 @@ > SCROLLINFO info; > > TRACE("hwnd=%p nBar=%d min=%d max=%d, bRedraw=%d\n", hwnd, nBar, minVal, maxVal, bRedraw); > - > + > info.cbSize = sizeof(info); > info.fMask = SIF_RANGE; > info.nMin = minVal; > info.nMax = maxVal; > SetScrollInfo( hwnd, nBar, &info, bRedraw ); > + if (nBar == SB_CTL) > + FIXME("needs to send SMB_SETRANGE when SB_CTL\n"); > + //return SendMessageW(hwnd, SBM_SETRANGE, (WPARAM)0, (LPARAM)0); > return TRUE; There's no reason to add a FIXME, calling SetScrollInfo is perfectly fine and it's what Windows does too, we even have a test for it. Also please send separate changes as separate patches, especially when you are renaming functions which causes a lot of changes all over and makes it hard to see what else is changing. -- Alexandre Julliard julliard(a)winehq.org

2 2

Wine(server) priority inversion on CK kernel mailing list
by Andreas Mohr Jan. 9, 2005

Jan. 9, 2005

Hi, I'm following CK kernel development, and the mailing list had the following posting: ---------- Message: 19 Date: Fri, 07 Jan 2005 23:16:14 +1100 From: Con Kolivas <kernel(a)kolivas.org> Subject: Re: [ck] wine is bloody slow with 2.6.10-ck2 To: Michal ?erav?k <michalz(a)olomouc.com> Cc: CK Kernel <ck(a)vds.kolivas.org> Message-ID: <41DE7D8E.8090102(a)kolivas.org> Content-Type: text/plain; charset="iso-8859-2" Michal ?erav?k wrote: > Hi, > > I have been running photoshop under wine > with 2.6.8.1-ck9 and 2.6.9 and it was good. > Is there any workaround for 2.6.10-ckx and wine > to get normal speed? > It's the same with prelink and without. Nice your wineserver +19. If that's not enough, just run wine at +19. Wineserver gets into a silly priority inversion scenario with the main wine threads. Cheers, Con ---------- Note that Con indicated several times that Wine is a very "special" piece of software, it has wildly differing gaming behaviour (threading behaviour) than native Linux games. For those of you who don't know what priority inversion is (I'll try to explain it, but I'm sure my explanation sucks ;): one (high priority) thread is waiting on a lock, and in order to keep this high priority, another thread owning that lock gets more CPU to get that lock released. Problem is that that thread should have a lower priority, but since the high priority thread always has to wait on the lock, the low priority thread effectively has a much higher priority. These could just be the usual known slow wineserver communication effects at work here, but I wanted to make sure you know about these issues on the CK list. Andreas Mohr

3 3

Re: [winegcc] Include .so files when calling winebuild
by Alexandre Julliard Jan. 9, 2005

Jan. 9, 2005

Peter Berg Larsen <pebl(a)math.ku.dk> writes: > Changelog: > Currently when compiling a program, winegcc calls winebuild > to solve .def references. But winegcc drops .so files, > so any new .def symbols in a .so causes a unresolved symbol at > link time. This patch adds .so files to the files to winebuild. I'm not sure I follow you, if your .so files have been built correctly they shouldn't contain undefined references to Windows APIs. Could you please show an example of the situation that causes a problem? -- Alexandre Julliard julliard(a)winehq.org

2 1

another build problem on current cvs
by Joris Huizer Jan. 9, 2005

Jan. 9, 2005

Hello, For the past week or so, building from cvs on a debian/stable system w/ alsa installed (using a custom kernel Linux debian 2.4.18.041216) breaks on alsa-specific code in wine; I attached the log; note that I did a `cvs update -dPA` and `make distclean` so this can't be any problem with the source I have Any ideas? Maybe you can point me to a place where I can read how to fix this properly (I never worked on alsa-specific code before...) or something like that regards, Joris

4 7

Directx 9
by Ann and Jason Edmeades Jan. 8, 2005

Jan. 8, 2005

Hiya, FYI I've spent the last couple of months putting together a directx 8 level support into wined3d and calling it from d3d9 such that I can also change d3d8 easily to use the new code. This is mostly complete other than the texture support and the shader support plus moving some functions / stubs into the common code. If you have any directx 8/9 questions feel free to email me directly, put questions on wine-devel or perhaps even the wined3d (very, very quiet - http://www.bbrox.org/mailman/listinfo/wine-d3d) mailing list (Lionel's). You really are welcome, and I'll try to answer any questions I can. I wouldn't spent too much time trying to move existing functionality between d3d8 to wined3d unless you really want to as I am trying to get this move completed asap. I really don't want to discourage any d3d assistance, its just I know where I am and what I have left to do. I have generally been doing a patch and getting it committed both due to lack to time, but also to avoid potential rework of multiple patches. I really hope to get most of the non-shader support done quite quickly once the 20 patch goes in (Christmas and FarCry got in the way, and I had some teething problems with the render target support which delayed it!). Next will be the texture support and that should be quick as it is relatively trivial to move across. >As soon as I'm happy with how wine's and directX work >I can stop duplicating what you've done and start >moving onto a more co-operative development... Sounds good - one thing wine has suffered from is a lack of people doing the directx support! Note that Raphael (copied on this note) has some outstanding patches he has put off while I do the move to support hardware vertex buffers so the drawstridedslow case is driven less frequently, but that's the only outstanding work I know about. > or moving DirectX8 over to using WineD3d. I have a version locally where I have changed d3d8 up to about patch 13. I can send it to you if it helps - Unfortunately I think the swap to wined3d will have to be one big patch, I don't think there is a way to move d3d8 over slowly, as you have to move the state block code in one go, the resource8 subclasses in one go etc... >I've merged all the creation surface code into a >single createSurface function that is called with >different parameters/flags to create a backbuffer, >PlainOffscreenSurface or rendertarget etc... Sounds fine - The problem I had with the latest patch was purely being able to add the support for getfrontbuffer etc which needed to return d3d8 or d3d9 objects, but the initial crates being done in the wined3d layer. A single callback sounds useful, as I know I'll have to do something similar for stencildepth surfaces (nothing else is created purely from the wined3d layer, so I don't think others need the same). FWIW I do the same, ie find demos on the web with source code, and then try to get them working. That's how most of the d3d8 support came about as it's a lot easier making a demo work than finding why there's a small amount of corruption for a particular game. I wouldn't claim to be a directx nor opengl expert - its all been a learning experience as I go! Maybe we should collect some useful test program links! If there's any d3d8/9 programmers out there, there's definitely a fun project to do to produce test programs for wine. They cant be automated (I think!) but it would be useful to be able to visually see the effect differences of all the render states, the texture states, prove the shader support works in both hw and sw vertex and pixel code etc etc. Jason

1 0

Re: [LostWages] Resurrection of the AddRef and Release code cleanup.
by James Hawkins Jan. 8, 2005

Jan. 8, 2005

On Sat, 08 Jan 2005 16:00:38 +0100, Paul Vriens <Paul.Vriens(a)xs4all.nl> wrote: > Hi, > > this Project was apparently not finished. > > Changelog: > make the AddRef and Release code cleanup active again. > > Cheers, > > Paul Vriens > It would be nice to add back in the two other workers (me and Joris). -- James Hawkins

1 0

Re: [dx9-20] RenderTarget support
by Oliver Stieber Jan. 8, 2005

Jan. 8, 2005

--- Ann and Jason Edmeades <us(a)the-edmeades.demon.co.uk> wrote: > This clears out the next blocking part of the d3d9 / > wined3d support and has > been a real pain to implement. I think I've got it > right now, and it adds > support for render targets but more importantly the > beginnings of a front > and back buffer which lots of the code relied upon. > > Unfortunately I couldn't get this next step any > smaller than the patch > attached.... > > Major areas still to go - textures and pixel / > vertex shader support. I'm > moving onto the textures next... > > Changelog > > Add render target support, and ensure there is a > front and back buffer > created during device creation > > Jason > > Hi, I've just done more-or-less exactly the same this weekend with a couple of differences. I've merged all the creation surface code into a single createSurface function that is called with different parameters/flags to create a backbuffer, PlainOffscreenSurface or rendertarget etc... This should mean that you only require one call-back function for CreateDevice in WineD3D. I'll merge your patch with what I've got and see how it goes. As soon as I'm happy with how wine's and directX work I can stop duplicating what you've done and start moving onto a more co-operative development, or moving DirectX8 over to using WineD3d. So far I can run Pirates! and a few of the demos from http://www.codesampler.com/dx9src.htm, but without textures. Pirates uses DirectX 9c but doesn't do anything too fancy and runs without crashing so it seems good for testing. Many of the demos at http://www.codesampler.com/dx9src.htm have OpenGL versions and since I don't know OpenGL or DirectX (but can hack a good Dos demo) it seemed a good place to start. ___________________________________________________________ ALL-NEW Yahoo! Messenger - all new features - even more fun! http://uk.messenger.yahoo.com

1 0

directX 9.
by Oliver Stieber Jan. 8, 2005

Jan. 8, 2005

Hi, I've been having a look at DirectX 9 over the weekend as a bit of a learning excersize. So far I've managed to get enough implemented in d3d9 to run Pirates! [without textured polygons] and have stated moving everything over to wined3d so that the textures will work. Unfortunatly I've become stuck assigning a DirectX 9 parent to a surface created in wined3d. Can anybody help? ___________________________________________________________ ALL-NEW Yahoo! Messenger - all new features - even more fun! http://uk.messenger.yahoo.com

1 0

Re: Native unix style paths in wine common dialogs
by Dimitrie O. Paun Jan. 8, 2005

Jan. 8, 2005

On Tue, Jan 04, 2005 at 11:22:00AM -0500, Dan Notestein wrote: > This patch allows winelib to be conditionally compiled with > USE_NATIVE_UNIX_PATHS macro. Enabling this will cause > the common dialogs to display using unix paths instead of drive > letters. This would be much better as a registry setting, not a compile time option. -- Dimi.

3 5

Re: windows/clipboard.c: Get rid of W->A calls
by Dmitry Timoshkov Jan. 8, 2005

Jan. 8, 2005

"Jacek Caban" <jack(a)itma.pwr.wroc.pl> wrote: > @@ -310,15 +335,24 @@ static void intern_atoms(void) > names = HeapAlloc( GetProcessHeap(), 0, count * sizeof(*names) ); > atoms = HeapAlloc( GetProcessHeap(), 0, count * sizeof(*atoms) ); > > - for (format = ClipFormats, i = 0; format; format = format->NextFormat) > - if (!format->drvData) names[i++] = format->Name; > + for (format = ClipFormats, i = 0; format; format = format->NextFormat) { > + if (!format->drvData) { > + len = WideCharToMultiByte(CP_ACP, 0, format->Name, -1, NULL, -1, 0, 0); > + names[i] = HeapAlloc(GetProcessHeap(), 0, len*sizeof(WCHAR)); > + WideCharToMultiByte(CP_ACP, 0, format->Name, -1, names[i++], len, 0, 0); You have to use CP_UNIXCP to convert unicode strings in order to pass them to the X11/unix system (here and everywhere else). -- Dmitry.

1 0

Re: windows/winproc.c: Get rid of HEAP_strdupWtoA calls
by Dmitry Timoshkov Jan. 8, 2005

Jan. 8, 2005

"Jacek Caban" <jack(a)itma.pwr.wroc.pl> wrote: > @@ -1010,9 +1009,15 @@ static INT WINPROC_MapMsg32WTo32A( HWND > case LB_DIR: > case LB_ADDFILE: > case EM_REPLACESEL: > - if(!*plparam) return 0; > - *plparam = (LPARAM)HEAP_strdupWtoA( GetProcessHeap(), 0, (LPCWSTR)*plparam ); > - return (*plparam ? 1 : -1); > + if(*plparam) { > + LPSTR buf; > + int len = WideCharToMultiByte(CP_ACP, 0, (LPWSTR)*plparam, -1, NULL, 0, 0, 0); > + buf = HeapAlloc(GetProcessHeap(), 0, len*sizeof(CHAR)); > + WideCharToMultiByte(CP_ACP, 0, (LPWSTR)*plparam, -1, buf, len, 0, 0); > + *plparam = (LPARAM)buf; > + return 1; > + } > + return 0; It would be helpful to keep the test in the case of a buffer allocation failure here and everywhere else (and perhaps add the missing tests). -- Dmitry.

1 0

Re: USER32: GetScrollBarInfo
by Alexandre Julliard Jan. 8, 2005

Jan. 8, 2005

Vitaly Lipatov <lav(a)etersoft.ru> writes: > --- scroll.c 8 Dec 2004 18:06:15 -0000 1.3 > +++ dlls/user/scroll.c 4 Jan 2005 14:27:08 -0000 > @@ -27,7 +27,7 @@ > * the specification mentioned above. > * If you discover missing features, or bugs, please note them below. > * > - * TODO: > + * TODO: needs check follow realized functions: > * - GetScrollBarInfo > * - SBM_GETSCROLLBARINFO > * - SCROLLBARINFO > @@ -1424,10 +1461,12 @@ > case SBM_GETSCROLLINFO: > return SCROLL_GetScrollInfo(hwnd, SB_CTL, (SCROLLINFO *)lParam); > > + case SBM_GETSCROLLBARINFO: > + return GetScrollBarInfo(hwnd, SB_CTL, (SCROLLBARINFO *)lParam); You have to do that the other way around, GetScrollBarInfo should send a SBM_GETSCROLLBARINFO message, similar to what GetScrollInfo does. -- Alexandre Julliard julliard(a)winehq.org

2 1

Re: wine/ include/Makefile.in dlls/user/user32.spe ... (CVS compile fix)
by Mike McCormack Jan. 8, 2005

Jan. 8, 2005

This patch adds GetScrollBarInfo to user32.spec, but adds no implementation... Here's a temporary fix for those wondering why the CVS won't compile until the rest of Vitaly's scrollbar patch is committed. Mike Alexandre Julliard wrote: > ChangeSet ID: 15265 > CVSROOT: /opt/cvs-commit > Module name: wine > Changes by: julliard(a)wine.codeweavers.com 2005/01/07 11:15:30 > > Modified files: > include : Makefile.in > dlls/user : user32.spec misc.c > Added files: > include : winnls32.h > > Log message: > Diego Pettenò <flameeyes(a)users.berlios.de> > Added stub implementation for WINNLS* functions. > > Patch: http://cvs.winehq.org/patch.py?id=15265 > > Old revision New revision Changes Path > 1.151 1.152 +1 -0 wine/include/Makefile.in > 1.92 1.93 +4 -4 wine/dlls/user/user32.spec > 1.19 1.20 +34 -3 wine/dlls/user/misc.c > Added 1.1 +0 -0 wine/include/winnls32.h ? dlls/user/timer.c ? dlls/user/tests/child.c ? dlls/user/tests/child.ok ? dlls/user/tests/timer.c ? dlls/user/tests/timer.ok Index: dlls/user/painting.c =================================================================== RCS file: /home/wine/wine/dlls/user/painting.c,v retrieving revision 1.16 diff -u -r1.16 painting.c --- dlls/user/painting.c 4 Jan 2005 12:11:09 -0000 1.16 +++ dlls/user/painting.c 8 Jan 2005 02:53:48 -0000 @@ -570,3 +570,10 @@ } return ret; } + +BOOL WINAPI SetLayeredWindowAttributes(HWND hwnd, COLORREF crKey, + BYTE bAlpha, DWORD dwFlags) +{ + FIXME("%p %08lx %02x %08lx\n", hwnd, crKey, bAlpha, dwFlags); + return TRUE; +} Index: dlls/user/user32.spec =================================================================== RCS file: /home/wine/wine/dlls/user/user32.spec,v retrieving revision 1.93 diff -u -r1.93 user32.spec --- dlls/user/user32.spec 7 Jan 2005 17:15:30 -0000 1.93 +++ dlls/user/user32.spec 8 Jan 2005 02:53:49 -0000 @@ -294,7 +294,7 @@ @ stdcall GetPropA(long str) @ stdcall GetPropW(long wstr) @ stdcall GetQueueStatus(long) -@ stdcall GetScrollBarInfo(long long ptr) +#@ stdcall GetScrollBarInfo(long long ptr) @ stdcall GetScrollInfo(long long ptr) @ stdcall GetScrollPos(long long) @ stdcall GetScrollRange(long long ptr ptr) @@ -521,6 +521,7 @@ @ stdcall SetInternalWindowPos(long long ptr ptr) @ stdcall SetKeyboardState(ptr) @ stdcall SetLastErrorEx(long long) +@ stdcall SetLayeredWindowAttributes(long long long long) @ stdcall SetLogonNotifyWindow(long long) @ stdcall SetMenu(long long) @ stdcall SetMenuContextHelpId(long long) Index: dlls/user/tests/win.c =================================================================== RCS file: /home/wine/wine/dlls/user/tests/win.c,v retrieving revision 1.39 diff -u -r1.39 win.c --- dlls/user/tests/win.c 27 Dec 2004 17:26:37 -0000 1.39 +++ dlls/user/tests/win.c 8 Jan 2005 02:53:49 -0000 @@ -2114,6 +2114,82 @@ ok( !ret, "message %04x available\n", msg.message); } +static void test_child_window() +{ + WNDCLASSA cls,child_cls; + char className[] = "parentclass"; /* To make sure className >= 0x10000 */ + char winName[] = "parent window"; + char childclassName[] = "childclass"; /* To make sure className >= 0x10000 */ + char childwinName[] = "child window"; + HWND hWnd, hChild; + HINSTANCE hInstance = GetModuleHandleA( NULL ); + + cls.style = CS_HREDRAW | CS_VREDRAW | CS_GLOBALCLASS; + cls.lpfnWndProc = DefWindowProcA; + cls.cbClsExtra = 0; + cls.cbWndExtra = 0; + cls.hInstance = 0; + cls.hIcon = LoadIconA (0, (LPSTR)IDI_APPLICATION); + cls.hCursor = LoadCursorA (0, (LPSTR)IDC_ARROW); + cls.hbrBackground = GetStockObject (WHITE_BRUSH); + cls.lpszMenuName = 0; + cls.lpszClassName = className; + + ok (RegisterClassA (&cls), "unable to register class") ; + + hWnd = CreateWindowA (className, winName, + WS_OVERLAPPEDWINDOW , + CW_USEDEFAULT, CW_USEDEFAULT, 300, 300, 0, + 0, + hInstance, 0); + + ok(hWnd != 0, "Couldn't create parent window"); + + child_cls.style = CS_HREDRAW | CS_VREDRAW | CS_GLOBALCLASS; + child_cls.lpfnWndProc = DefWindowProcA; + child_cls.cbClsExtra = 0; + child_cls.cbWndExtra = 0; + child_cls.hInstance = 0; + child_cls.hIcon = LoadIconA (0, (LPSTR)IDI_APPLICATION); + child_cls.hCursor = LoadCursorA (0, (LPSTR)IDC_ARROW); + child_cls.hbrBackground = GetStockObject (GRAY_BRUSH); + child_cls.lpszMenuName = 0; + child_cls.lpszClassName = childclassName; + + ok (RegisterClassA (&child_cls) , "unable to register child class"); + + /* NOTE: WS_POPUP should override WS_CHILD */ + + hChild = CreateWindowExA ( + 0, childclassName, childwinName, + WS_POPUP | WS_CHILD | WS_CLIPCHILDREN, + 50, 50, 50, 100, hWnd, + 0, hInstance, 0); + + ok(hChild != 0, "Couldn't create child window"); + + ok(!SetActiveWindow(hChild), + "Can activate without parent window"); + + ok(GetAncestor(hChild, GA_PARENT) == GetDesktopWindow(), + "ancestor is not the desktop window"); + + ShowWindow (hWnd, SW_SHOW); + UpdateWindow (hWnd); + + ok(SetActiveWindow(hChild) != 0, + "Can't activate window with parent active"); + + ShowWindow (hChild, SW_SHOW); + UpdateWindow (hChild); + + ok(SetActiveWindow(hChild) != 0, + "Can't activate window with parent active"); + + DestroyWindow(hChild); + DestroyWindow(hWnd); +} + static void test_mouse_input(HWND hwnd) { RECT rc; @@ -2179,6 +2255,8 @@ START_TEST(win) { + test_child_window(); + pGetAncestor = (void *)GetProcAddress( GetModuleHandleA("user32.dll"), "GetAncestor" ); pGetWindowInfo = (void *)GetProcAddress( GetModuleHandleA("user32.dll"), "GetWindowInfo" );

1 0

Re: wineloader: call wineprefixcreate with explicit WINEPREFIX
by Tobias Burnus Jan. 7, 2005

Jan. 7, 2005

Hello, Crestez Leonard wrote: > +if [ -z $WINEPREFIX ] > +then While my bash accepts this, Tru64 UNIX's POSIX shell does not. Please use "$WINEPREFIX" instead. Tobias

2 1

Re: MSVCRT: Re-implement *printf
by Juan Lang Jan. 7, 2005

Jan. 7, 2005

Style point: (*pointer).whatever is written a bit more easily as pointer->whatever. That'd make your new patch a good bit more readable. --Juan __________________________________ Do you Yahoo!? Yahoo! Mail - Helps protect you from nasty viruses. http://promotions.yahoo.com/new_mail

4 3

re: Announcing security hardened kernels for testing
by Mike Hearn Jan. 7, 2005

Jan. 7, 2005

Hi, Thanks for the great info. I'll CC this to wine-devel as I think it's of general interest, I hope you don't mind. For context, PaX is a set of security patches for Linux which lock down the system in a similar manner to exec-shield and SELinux. I say similar manner, because PaX seems to go further than these systems do - in fact from what I've read it seems to be the 'gold standard' in security patches. I'll quote the whole email and reply inline. This thread started on ubuntu-devel after one Ubuntu developer said they were experimenting with PaX, and I asked what the differences were between it and exec- shield (with which the community seems to have more experience) and why it was chosen. So I was pointed towards this thread: http://lists.debian.org/debian-devel/2003/11/msg00206.html in which the PaX author and Ingo Molnar who did exec-shield discuss the differences. On Wed, 2005-01-05 at 13:37 +0100, pageexec(a)freemail.hu wrote: > Hello, > > just ran across this thread on the ubuntu-devel list and have > a few observations: > > 1. PaX cares about backwards compatibility as much as it cares about > security, the best compromise we could make is that one can mark > executables to be exempt from PaX enforcements (and you should > have known about this as we'd talked about PaX+wine last year...). OK. I don't remember this thread I'm afraid but I do recall that you can exempt particular programs from PaX, so if a distribution wanted to integrate that it'd have to mark Wine as exempt by default. Presumably if WineHQ/CodeWeavers were to ship binary packages we'd have to do the same to work on such a distribution. But it's just an ELF flag right? > 2. as of the 20041201 snapshot of wine, it needs to be exempt from > at least ASLR [1], because it still makes some invalid assumptions > about the address space: > > - the highest mapping in the address space may not be the stack, > nor is the highest mapping (be that the stack or something > else) supposed to extend to the end of the userland address > space. the end result of this assumption is that some piece > of code in the preloader enters an infinite loop requesting > (but never getting) anon mappings above TASK_SIZE (0xc0000000 > typically). excerpt from an strace: > > mmap2(0xbffe0000, 262144, PROT_NONE, MAP_PRIVATE|MAP_ANONYMOUS|MAP_NORESERVE, -1, 0) = 0x77ec0000 > munmap(0x77ec0000, 262144) = 0 > mmap2(0xbffe0000, 131072, PROT_NONE, MAP_PRIVATE|MAP_ANONYMOUS|MAP_NORESERVE, -1, 0) = 0xbffe0000 > mmap2(0xc0000000, 131072, PROT_NONE, MAP_PRIVATE|MAP_ANONYMOUS|MAP_NORESERVE, -1, 0) = 0x77ee0000 > munmap(0x77ee0000, 131072) = 0 > mmap2(0xc0000000, 65536, PROT_NONE, MAP_PRIVATE|MAP_ANONYMOUS|MAP_NORESERVE, -1, 0) = 0x77ef0000 > munmap(0x77ef0000, 65536) = 0 > > the last lines then repeat indefinitely as the kernel would > never give out the request address, even with MAP_FIXED. We do this because some Windows programs and DLLs cannot cope with getting pointers >2gig, so we need to ensure that the kernel does not give us mappings above this point. The only way to do this currently is to do an iterative reservation to map as much of this address space as possible which is what you're seeing here. > - the above mentioned infinite loop also highlighted another bad > assumption wine makes: mmap() without MAP_FIXED but with a non-0 > hint is under no obligation to observe the hint and give you a > mapping at that address, under PaX it doesn't do so explicitly. > excerpt from an strace: > > mmap2(0x81000000, 1034813440, PROT_NONE, MAP_PRIVATE|MAP_ANONYMOUS|MAP_NORESERVE, -1, 0) = 0x3a420000 > munmap(0x3a420000, 1034813440) = 0 > mmap2(0x81000000, 517406720, PROT_NONE, MAP_PRIVATE|MAP_ANONYMOUS|MAP_NORESERVE, -1, 0) = 0x81000000 > mmap2(0x9fd70000, 517406720, PROT_NONE, MAP_PRIVATE|MAP_ANONYMOUS|MAP_NORESERVE, -1, 0) = 0x59190000 > munmap(0x59190000, 517406720) = 0 > mmap2(0x9fd70000, 258670592, PROT_NONE, MAP_PRIVATE|MAP_ANONYMOUS|MAP_NORESERVE, -1, 0) = 0x9fd70000 > > as you can see, wine insists on an address until it gets it, > without using MAP_FIXED. We have no choice in the matter, I think we can't use MAP_FIXED as that'd risk blowing away any mappings already made above the 2gig boundary. Actually this code was originally written to support the 4G/4G VM patch that was put into Fedora for a while (it's gone now). > 3. there's at least /usr/lib/wine/ntdll.dll.so which is marked with > an executable PT_GNU_STACK program header, suggesting that it > needs an executable stack (or there's some build problem). Last time I looked documentation on exactly what triggers this flag is scarce or non-existant. I remember asking Ingo if inline assembly still generated it and the answer back then was no, but I have no idea why gcc has decided it's needed now. If you look at ntdll in the sources: http://source.winehq.org/source/dlls/ntdll/ It's fairly harmless, there is some assembly in there but I don't remember seeing any code which assumed an executable stack. > this > alone would make wine fail under a PaX kernel as PT_GNU_STACK is > completely ignored there (because it's the wrong solution for the > wrong problem), nor is it allowed to generate code at runtime > (this applies to apps on which PaX is enforced of course, one can > always disable these on a per-executable basis). I'm afraid Wine cannot operate in an environment that doesn't allow us to map pages as executable and fill them with generated code. This technique is: a) Used by some Windows programs b) Used by the Wine DLL loader c) Required to implement DCOM universal interface proxies So if PaX denies this as a matter of course then it will never work. Having read the thread with Ingo I must say I agree with him that runtime code generation is a legitimate technique and not a bug. > i also have memories from about a year ago that kernel32.so had > some executable code snippets (some thunking code?) in .data or > some other otherwise non-executable area, that of course wouldn't > (and didn't) work under PaX either. back then Alexandre Julliard > suggested that this wasn't easy to rewrite (by also making the > now static code text reloc free) - has this been done since then? I don't think so, but I don't remember this thread either. > i also have strace excerpts that show how wine wanted to create > writable and executable memory, suggesting that it still wants to > generate code at runtime and this is how it fails under PaX (which > prevents runtime code generation by default): > > mmap2(NULL, 1179648, PROT_NONE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7fee0000 > munmap(0x7fff0000, 65536) = 0 > mprotect(0x7fee0000, 65536, PROT_READ|PROT_WRITE|PROT_EXEC) = -1 EACCES (Permission denied) > munmap(0x7fee0000, 1114112) = 0 > write(2, "wine: failed to create the proce"..., 40wine: failed to create the process heap > ) = 40 > > on a sidenote, XP SP2 makes the default heap non-executable as > well, so if the above is the result of wanting to be compatible > with Windows, you may want to rethink it for the future. I'm not sure why it is, but yes I expect it's because some programs rely on it. Service Pack 2 may well make the default process heap NX but it also has a huge infrastructure in place to deal with backwards compatibility concerns, including a large database of badly behaved apps, user-accessible GUIs to disable the protections and I believe it also has code to catch NX faults (on hardware that supports that) and ask the user if they wish to disable the protections for that application. > 4. it would be nice if wine-preloader and wine-pthread had a configurable > base address, the current default makes them impossible to use > under the faster non-executable method of PaX/i386 (which halves > the userland address space, [2]). They have to be fixed otherwise the kernel may place them in the middle of a reserved area which would cause initialisation to fail. This cannot be changed. > so, right now wine can't run with a randomized address space, i have > yet to test if it can get away without generating code at runtime > and/or having writable/executable memory. It can't and I don't see any way to make it able to operate under such conditions in future. Is there a way to brand the binaries as excluded from PaX at build time without a special tool? If not would you be willing to submit a build system patch to detect the branding tool on PaX systems and use it on the relevant binaries automatically? thanks -mike

4 8

Re: winecfg fixes, now with actual patch
by Mike Hearn Jan. 7, 2005

Jan. 7, 2005

Crestez and I talked about this patch on #winehackers, and there are a few things that need to be changed (let's ignore the formatting changes here): - There was code to avoid a crash when the desktop value read from the registry doesn't have an x in it for some reason (yes this does happen) but this patch deletes it - mode_to_label is for translated, UI strings, not for stuff to be put in the registry. It does say this in a comment but I can appreciate that it looks at first glance like pointlessly duplicated code. We should fix this, especially as right now winecfgs translation support is weak. But for now the replacement of a case statement with a mode_to_label call is incorrect. thanks -mike On Fri, 07 Jan 2005 16:44:11 +0200, Crestez Leonard wrote: > This patch makes a bunch of small winecfg fixes. Since most of them are > just a few lines in length I don't think it's worth splitting them. > > Sorry for forgetting the attachment. > > Changelog: > winecfg: fix add application (memory error) > winecfg: fix apply button lighting up in audio tab > winecfg: fix video tab(crash when checking desktop, apply button not > lighting up > winecfg: fix apply button in libraries tab, fix memory leak in > parse_override, remove horrible abuse of macros in set_dllmode

1 0

Re: [winegcc] Include .so files when calling winebuild
by Dimitrie O. Paun Jan. 7, 2005

Jan. 7, 2005

On Wed, Jan 05, 2005 at 01:58:45PM +0100, Peter Berg Larsen wrote: > +void strarray_set(strarray* arr, int index, const char* str) > +{ > + if (index >= arr->maximum) > + { > + arr->maximum = index+10; > + arr->base = xrealloc(arr->base, sizeof(*(arr->base)) * arr->maximum); > + memset(&(arr->base[arr->size]),0,sizeof(*(arr->base)) * (arr->maximum - arr->size)); > + } > + arr->base[index] = str; > + if (arr->size <= index) > + arr->size = index+1; > +} Do we really need this strarray_set() function? Even if you do, it should _not_ shorten the array. -- Dimi.

2 3

tools/widl/write_msft.c warnings
by Gerald Pfeifer Jan. 7, 2005

Jan. 7, 2005

The addition of tools/widl/write_msft.c added the following four warnings, basically doubling the number of warnings we are getting with GCC 3.4. write_msft.c:582: warning: `ctl2_alloc_importinfo' defined but not used write_msft.c:620: warning: `ctl2_alloc_importfile' defined but not used write_msft.c:918: warning: `ctl2_find_nth_reference' defined but not used write_msft.c:1382: warning: `set_help_file_name' defined but not used Would you mind looking into this? Gerald

1 0

Re: [AppDB] remove even more unused functions
by Tony Lambregts Jan. 7, 2005

Jan. 7, 2005

Jonathan Ernst wrote: > This patch removes unused functions from include/util.php > > Changelog: > - remove unused functions in include/util.php > > Files changed: > - include/util.php I believe you got carried away... two of those functions are used by make_bugzilla_version_list(): openbugzilladb() and closebugzilladb() values() is used in qclass.php which is used in stdquery.php which is used by query_appbyvendor.php, pn_buttons.php, appversion,php and a few others. If those files are not used then we should remove them first.

1 0

MSVCRT printf functions
by Aneurin Price Jan. 7, 2005

Jan. 7, 2005

I've gone over this patch again, fixed any bugs I could find, and tried to address the points made regarding readability. Hopefully the coding style should now be much improved, so could anyone who knows about such things give it a look over? If there's not too much of a problem there I'll fix up any points made and submit to wine-patches with the appropriate notes. I am still a little unsure about a couple of points; ones I can remember off the top of my head: probably insufficient attribution for code derived from file.c, since I have no idea who wrote the functions I used (these are specified in the copyright notice for printf.c, BTW). It's also pretty big; I presume it's okay to have this much in one file, but maybe not. Either way it can't be broken down into smaller patches since it's one big change. Thanks, Aneurin Price

2 1

Re: MSVCRT printf functions
by Juan Lang Jan. 6, 2005

Jan. 6, 2005

Hi Aneurin, some style comments on your patch: +<<<<<<< file.c +======= This shouldn't be in your patch. +typedef struct +{ + int flags; + unsigned int width; + __int64 precision; + const MSVCRT_wchar_t *input; + MSVCRT_wchar_t *output; + int HeapAlloced; + union + { + int intIn; + double doubleIn; + }; +} PRINTF_SPECIFIER; The HeapAlloced flag shouldn't be upper-cased. A BOOL may make more sense too. +PRINTF_SPECIFIER integertostringw(va_list *args, MSVCRT_wchar_t digits[], PRINTF_SPECIFIER specifier) This calling convention is a little strange. It's more typical in C not to return "large" things on the stack, but to use pointers instead. Since you use the specifier in the following way: + specifier = charprocessw(va_arg(*args, int),specifier); you may want to make the specifier an in/out parameter passed by pointer instead, e.g. void integertostringw(va_list *args, MSVCRT_wchar_t digits[], PRINTF_SPECIFIER *specifier) The calls would then look like: + charprocessw(va_arg(*args, int),&specifier); Finally, your internal functions should be made static. --Juan __________________________________ Do you Yahoo!? All your favorites on one personal page � Try My Yahoo! http://my.yahoo.com

1 0

RC file translation via winehq?
by Mike McCormack Jan. 6, 2005

Jan. 6, 2005

Hey All you web programmers out there! How hard to you think it would be to rig up a web page for people to do translations for wine on? Have a web page (translate.winehq.org?) into which we feed in all the .rc files and maybe even parts of WineHQ, and show the translations for each language and bits that are missing ... then accumulate all the bits of translation somehow so they can be sumbitted back to wine-patches. I think there's plenty of people who'd do translation work for us if they didn't have to bother learning about how to submit patches or understand how .rc files work. Mike

7 8

questions for safedisc implementation (AJ pleas read)
by Ivan Leo Puoti Jan. 6, 2005

Jan. 6, 2005

Chances are I'll be quite busy during the next week, but Laurent Pinchart, the guy who originally reverse engineered safedisc, asked a few questions on IRC about implementing support for the native safedisc driver, feedback, particularly from AJ, would be very appreciated, here is the IRC log. peter_pan is Laurent. < peter_pan> I'm trying to figure out how to implement "kernel services" in wine. a kernel service is a device driver which is loaded by StartService and runs in kernel space. the driver has a DriverEntry entry point, which, unlike regular services, seem to return immediately after registering callbacks. this might not always be the case though 23:41 < peter_pan> after DriverEntry returns, the process started by StartService currently exits. how should I handle calls to the callbacks registered by IoCreateDevice inside DriverEntry ? should they run in the calling process space, the wine server space or the service process space ? 23:41 < peter_pan> in the first case, I have to map the kernel service in all wine processes space, as the service can make use of global data (in windows the kernel service only exists once inside the kernel) 23:41 < peter_pan> in the third case, I will have to find a way to keep the service process alive (in a stopped state) after DriverEntry returns, and use wineserver and ptrace to call the callbacks from the user processes. this will imply inter process communication and inter process synchronization. or maybe I could just use IPC and keep the kernel space process waiting on a pipe or something. this wouldn't work for a kernel service which doesn't return from DriverEntry immediately, but I don't know if those exist. 23:41 < peter_pan> does anyone have any thought to share ? 23:47 <@Thunderbird> hi 23:47 <@Thunderbird> guess it needs to happen in wineserver 23:47 <@Thunderbird> better ask julliard about it 23:47 <@Thunderbird> if he is still awake 23:48 < peter_pan> he's been idling for 1 hour and 45 minutes 23:49 < peter_pan> are you there alexandre ? 23:50 <@Thunderbird> td might be online too .. 23:51 * TD is gone to a film, like NOW 23:51 <@TD> bye .... 23:51 < peter_pan> no luck either 23:51 < peter_pan> lol 23:52 <@Thunderbird> isn't there some function in wineserver that runs all the time? 23:53 < peter_pan> my opinion is that DriverEntry should be called in a separate process like it is now, as it can block, and that IoCreateDevice should map the image in the wineserver process space and update the callback table. the problem is that the changes to data sections made in DriverEntry must be somehow shared with wineserver. 23:55 < peter_pan> StartService will have to be modified to handle kernel services. it uses CreateProcess now, which calls DriverEntry (the entry point) with wrong parameters. we would need a way to mark a process as being a kernel process or a user process 23:57 <@Thunderbird> I guess that is good but I'm not qualified enough to say something about that 23:58 < peter_pan> using wineserver to host the driver callbacks would serialize the calls, which might not be a good thing to do. in windows, syscalls are executed in kernel space, but in the context of the calling process. it might be a good idea to do that here too. is the windows kernel interruptible ? can a process call a driver function while another process sleeps in the same functions, or while another process executes inside that function on another CPU ? 23:59 <@Thunderbird> how is this stuff handled in reactos? 23:59 < peter_pan> I have no idea 23:59 < peter_pan> maybe I should ask them

2 1

Re: WPP: Fixed 'out of tree' compilation
by Alexandre Julliard Jan. 6, 2005

Jan. 6, 2005

Jacek Caban <jack(a)itma.pwr.wroc.pl> writes: > --- libs/wpp/ppy.y 1 May 2003 03:16:21 -0000 1.1 > +++ libs/wpp/ppy.y 30 Dec 2004 10:11:39 -0000 > @@ -537,7 +537,10 @@ static int boolean(cval_t *v) > static marg_t *new_marg(char *str, def_arg_t type) > { > marg_t *ma = pp_xmalloc(sizeof(marg_t)); > - ma->arg = str; > + if(str) > + ma->arg = pp_xstrdup(str); > + else > + ma->arg = NULL; > ma->type = type; > ma->nnl = 0; > return ma; > @@ -569,7 +572,7 @@ static mtext_t *new_mtext(char *str, int > if(str == NULL) > mt->subst.argidx = idx; > else > - mt->subst.text = str; > + mt->subst.text = pp_xstrdup(str); AFAICS the string is already duplicated everywhere these functions are called, so you are adding a memory leak here. Does this patch really make a difference in the behavior? -- Alexandre Julliard julliard(a)winehq.org

3 4

DCOM roadmap
by Mike Hearn Jan. 6, 2005

Jan. 6, 2005

I thought I'd post an update on where Rob and I are up to, and where we're going. This is the plan that I have in my head, Rob may want to do things in a slightly different order etc so don't be surprised if we change some stuff around as a result of this email. We're currently reworking, extending and in some cases rewriting the code Marcus wrote originally to work more like native DCOM does. This means that new features and major improvements are *not* going to happen for a while, because before we can extend our support for DCOM we have to migrate to the same architecture that Microsoft use internally. This has several benefits: 1) It saves us design work, because MS already did it 2) It's the only way to be wire compatible in the long run 3) It means the documentation (like Essential COM etc) is already written Getting to a more native-style architecture has already been started, but won't be finished for a while. Here are the steps we need to take, the ones marked with a * are already done, - means they are still to do. - Replace the wine_marshal_id structure with [STD]OBJREF. This is necessary because the Microsoft internal interfaces like IOXIDResolver and IRemoteActivation operate in terms of OBJREFs. An OBJREF is a marshalled interface pointer, so by using the same structure we're able to be wire-compatible with MS. * Switch apartments to be identified by OXIDs * Refactor and extend the stub manager, identified by OIDs * Refactor and extend the proxy manager - Make all system interface proxies support aggregation - Identify interface stubs by IPID not IID - Do a search and replace of wine_marshal_id with STDOBJREF - Alexandre has stated that he won't allow any more midl generated code in WineHQ. Enhance widl until it can generate raw RPC marshallers for at least IRemUnknown. - Generate unique names for the pipes we currently use in communication and pull the right name from the OBJREF DUALSTRINGARRAY. In real DCOM this contains the RPC string binding for the OXID Resolver endpoint. This should be the first enhanced feature, as at this point you can run two apps at once that happen to marshal the same interface, and they won't interfere. - Implement IRemUnknown, using custom marshalling for now. Use this to nail distributed refcounting, at the moment we have a bunch of bad hacks for that. - Flip DCOM on top of the RPC transport layer, replacing the current named pipe based IRpcChannelBuffer implementation. Not necessarily using NDR marshalling at this point, though we may find it's necessary (?) - Rework RPC dispatch to be more Windows-like, so call re-entrancy works. - Implement RPC thread affinity. This will fix the InstallShield painting problems ... yes it's a long way off :( - Begin rewriting/moving the typelib marshaller to rpcrt4 and to use NDR (in Windows this is done by generating MOPs at runtime from the type data) .... this point is so far off I don't really care about it .... I probably forgot some items as well. But as you can see we only just begun. Also remember that Rob may want to modify it and also we may change direction at any point to make stuff we want internally work (like native MSIv2 ...) thanks -mike

1 0

[Fwd: Re: video4linux - wine]
by MediaHost (TM) Jan. 6, 2005

Jan. 6, 2005

I'm forwarding this correspondence to wine-devel, in case it interests other developer / users.... -------- Original Message -------- Subject: Re: video4linux - wine Date: Wed, 5 Jan 2005 22:52:33 +0100 From: Jasper van Veghel <vanveghel(a)home.nl> To: MediaHost (TM) <webmaster(a)startcom.org> References: <20050105193015.GA14955(a)Skye.mill1.nb.home.nl> <41DC68AF.2060405(a)startcom.org> Well, sure, a lot of the infrastructure is there already; it seems to me that we'll have to implement several Quartz interfaces / filters and the approriate DLL for VFW to work with DirectX. I'm not quite sure which one to base it on, though; there are quite a lot that deal with VFW, multi-media and stream captur- ing; a lot of abstraction is handled in Quartz (including qcap and amstream), but for the raw video stuff it seems to me that these are the ones where it's really at (and consequently, what we'll have to base the stuff in Quartz on) winmm.dll msvfw32.dll msvideo.dll avicap32.dll As for the devenum stuff, I've had to modify createdevenum.c to include the CLSID for VideoInputDeviceCategory and have it create the corresponding registry entries in CreateSpecialCategories, for which I've extended the stub of avicap32 a bit to actually return a device (a static string, nothing special) - the corresponding filter either references Quartz's VideoRenderer as the DShow or the VfwCapture one .. I've been having more luck with VideoRenderer (MSN 6.2 seemed to respond quite well to that), but native devenum seems to go for the other one. Perhaps they're related in some way (AFAIK there's no implementation of VfwCapture in wine; there is, however, one of VideoRenderer .. perhaps Vfw- Capture captures from the stream and VideoRenderer renders it and provides info about it through IAMStreamConfig (which is a part of VideoRenderer) - anyway, I'm sure this is all well documented and everything on MSDN, but as I said, I've never worked with DirectX before I started looking into this (wouldn't have expected it to be related to it even) Anyway, it would be nice to make some headway with this, and if you have some sample code or even a small application to test this out with (one that indeed uses this DirectX stuff) then I'd be glad to dive back into it :-) Would indeed be nice to return something useful to Wine. Jasper MediaHost (TM) wrote: > Maybe we can start the same procedure with a simpler application. Any > ideas? Of course I would be interested first, what you implemented at > devenum. So I'm not a wine developer (specially not the windows part of > it) I can give it a try and maybe we can return something useful into > wine..... > > Jasper van Veghel wrote: > > >Rob Shearman wrote: > > > > > >>Mike McCormack wrote: > >> > >> > >> > >>>There's currently no support, but you could add it via the Still Image > >>>(STI) API. It's meant for scanners and webcams. There's probably a > >>>way to add VFW (Video For Windows drivers) too. > >>> > >>>I have written an IDL file for IStillImage, which I haven't gotten > >>>round to submitting as yet. I've attached it incase you're > >>>interested... I think it still needs some fixing up. > >>> > >>>Mike > >>> > >>> > >>>MediaHost (TM) wrote: > >>> > >>> > >>> > >>>>Question: Is there support for video4linux devices with wine? Is > >>>>there some support for webcams? What are the settings (config)? I > >>>>couldn't find anything useful on google concerning this issue.... > >>>> > >>>> > >>You're probably much better off implementing a DirectShow -> V4L filter, > >>especially if you want to capture movies or sound. > >> > >>Rob > >> > >> > >> > > > >I've recently been looking into VFW with Wine, and though I certainly am no > >expert at the Windows API concerning this (first time I really looked into > >DX), > >nor Wine for that matter, I was able to get a bit further from where I > >started, > >so allow me to share my experiences with you. > > > >As an application to test this stuff with I went for MSN 6.2, though > >certainly > >not the best application for this, it seemed neat to finally have Webcam > >support > >on MSN - I eventually got some of it working with a load of native DLLs, > >some > >hacking on the SSL stuff (I ended up simply setting useSSL = false, the > >applica- > >tion was sending plain-text over an SSL socket, which wasn't working; this > >fixed > >things, or at least for this application ;-)) and adding some undocumented > >flag > >to InternetSetOption (optionId = 87) - anyway, it seems that MSN is using > >some- > >thing along the lines of the following webcam class I found using Google - > >indeed, using a DirectShow filter: > > > >http://www.jolash.com/projects/other_projects/webcam/WebCam.h > > > >For things to start working under Wine I used the following native DLLs, > >which > >I also registered with regsvr32 (for CLSIDs etc.) > > > >COMCTL32.DLL > >urlmon.dll > >CRYPT32.DLL MSOSS.DLL > >oleaut32.dll ole32.dll rpcrt4.dll > >MSVCRT.DLL > >shlwapi.dll shdocvw.dll > >MLANG.DLL > >qcap.dll amstream.dll > > > >Though I'm not sure if amstream is needed. Don't know what qcap does as I > >only > >managed to get to a point where something in qcap was called which was then > >being forwarded to Quartz (IAMStreamConfig, for which I added a bunch of > >stubs > >and semi-stubs (filled in some bogus information for > >VIDEO_STREAM_CONFIG_CAPS, > >VIDEOINFOHEADER and AM_MEDIA_TYPE) > > > >It turned out that, at least MSN, and this webcam class too, uses devenum > >to > >find the video input devices (CLSID_VideoInputDeviceCategory), for which > >I've > >added the proper code to CreateSpecialCategories and hence > >CreateClassEnumerator > >(it also seems that the windows DLL of devenum always recreates the dynamic > >registery entries whereas Wine only seems to add them once and then never > >again, > >that is, once they're in the registry they stay there (hence if a new > >audio card > >gets added to the system ..)) The Windows DLL seemed to be using avicap32 > >to > >collect information on the available video input devices, so I've simply > >had > >capGetDriverDescription return some string with a fictional video driver > >(this > >also makes it possible to use a native devenum.dll) Next up is Quartz, > >which > >seemed to want IAMStreamConfig (collecting information on the video stream > >(res, > >depth, sps, ..) for starters, but I never got around to implementing > >enough of > >that for the program to accept it and move on, so that's where I got > >stuck. It > >may also have had something to do with MSN wanting an IKsPin which isn't > >imple- > >mented (which is why native quartz may have failed, when trying to > >approach the > >kernel in some way) Here's a small scenario of what I observed working > >with both > >native and hacked up DLLs ;-) > > > >DEVENUM - Read all VideoInputDeviceRenderer's (from CLSID) > >DEVENUM - BindToObject() --> VfwCapture > >QCAP - BindToClass --> Quartz(VideoRenderer) > >QUARTZ - VideoRenderer_create > >QUARTZ - [FAIL] InputPin_QueryInterface (IKsPin) > >QUARTS - VideoRenderer_QueryInterface (IAMStreamConfig) > > > >Anyway, the 'patches' I wrote are probably not worth much as the whole > >under- > >taking was more of a little endeavor trying to see how far I go (MSN > >actually > >managed to sign in, by the way, but kept crashing a few seconds after that > >(the > >webcam stuff can be accessed without signing in though, there's a preview > >option > >in one of the menus), but perhaps this brief explanation of my steps will > >prove > >useful for someone wanting to implement this aspect of VFW :-) Perhaps > >someone > >could build a control from the class I mentioned earlier which can then be > >used > >for testing (through the webpage that refers to it says it's missing some > >code; > >but at least it's a starting point) > > > >Jasper > > > > > > -- > Regards > > Signer: Eddy Nigg > Company: StartCom Linux at www.startcom.org <http://www.startcom.org/> > MediaHost^(TM) at www.mediahost.org > <http://www.mediahost.org/> > Skype: startcom <callto://startcom/> > Phone: +1.213.341.0390 > -- Regards Signer: Eddy Nigg Company: StartCom Linux at www.startcom.org <http://www.startcom.org/> MediaHost^(TM) at www.mediahost.org <http://www.mediahost.org/> Skype: startcom <callto://startcom/> Phone: +1.213.341.0390

1 0

bi-arch on an amd64
by Gabriel de Perthuis Jan. 6, 2005

Jan. 6, 2005

Hello, I'm trying to get wine cross compiled for my distrib, a 64-bit ubuntu. I'm using: a gcc-3.4 bi-arch toolchain (gcc built with --enable-multilib); the wine-20041201 tarball; this configure command (CC is ccache gcc-3.4): AS="as --32" CC="$CC -m32" CXX="$CXX -m32" ./configure --x-libraries=/usr/X11R6/lib32 note: with AS the same as CC, it gets stuck with dlls/ntdll/relay32.s -> relay32.o these two patches : sed -i s/SYS_sigaction/SYS_rt_sigaction/g dlls/ntdll/signal_i386.c replacing ld with ld -m elf_i386 in the ld_cmd definition in tools/winebuild/main.c With all this, I can get it to build! The problem is, it doesn't run; wine stops with this unhelpful message: wine: could not exec \uffff\uffffmU\uffff\uffffmUp/bin/wine-pthread (special characters inside) So, I am interested in past experiences (versions used and patches): I think wine, as most applications if need be, can be built in 32-bit mode and used by amd64 distros. It would be nice if these fixes were sent back to CVS to save people headaches; I also would like to know where I can go from here, to debug the binaries I finally got.

2 4

Re: Re: [AppDB] Fix to allow creating of new accounts (urgent)
by Chris Morgan Jan. 6, 2005

Jan. 6, 2005

You can CC me on the mail as well to keep the load on Jeremy down. Chris > > From: Mike McCormack <mike(a)codeweavers.com> > Date: 2005/01/06 Thu AM 12:19:45 EST > To: tony_lambregts(a)telusplanet.net > CC: wine-devel(a)winehq.com, burnus(a)gmx.de > Subject: Re: [AppDB] Fix to allow creating of new accounts (urgent) > > > Please send mail about security problems with winehq directly to > jnewman(a)codeweavers.com rather than advertising on public mailing lists > first :) > > Mike > > tony_lambregts(a)telusplanet.net wrote: > > > I admit it I am an idiot for not knowing what to do to fix security flaws. > >

1 0

Re: [AppDB] Fix to allow creating of new accounts (urgent)
by Tobias Burnus Jan. 6, 2005

Jan. 6, 2005

Hello, > $result = mysql_query("INSERT INTO user_list VALUES ( NOW(), 0, ". > "'$username', password('$password'), ". > - "'$realname', '$email', NOW(), 0, 0)"); > + "'$realname', '$email', NOW(), 0, 0, '$CVSrelease')"); Shouldn't one use "'".mysql_escape_string($username)."','" etc.? Or is it ensured elsewhere that no unwanted characters are in the string? ( ' is escaped in PHP, isn't it?) Tobias

4 5