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

Re: commctrl.c
by Dmitry Timoshkov Jan. 4, 2004

Jan. 4, 2004

"Ge van Geldorp" <ge(a)gse.nl> wrote: > Changelog: > Don't destroy heap during unload, as other DLLs which haven't unloaded > yet may still depend on it (DPA* callers) The patch is wrong. A more correct way to fix this is to simply use process heap in DPA (and MRU) APIs. Perhaps even go further and completely remove any use of the private comctl32 heap. -- Dmitry.

1 0

winebrowser winelib application
by Chris Morgan Jan. 3, 2004

Jan. 3, 2004

Alexandre wanted winebrowser implemented as a winelib application and also to be more easily configured. Here is the winebrowser winelib application. It uses a registry key(I'm not sure if this is the correct path for the key since I didn't see any other config keys in the registry) and creates a key with the defaults if no key exists. Thanks, Chris

1 0

WWN #203
by Tom Jan. 3, 2004

Jan. 3, 2004

Bein' A Playa In Da Hood :-) Tom

1 0

Winetest progress bar
by Ferenc Wagner Jan. 3, 2004

Jan. 3, 2004

Hi, I put together a feedback window for winetest. The code is somewhat inside-out to make it less intrusive, and the dialog is ugly. Where can one find a dialog editor? Anyway: 1. If compiled with Winelib, the dialog stays on screen after the main thread finishes with the tests; under Windows, it disappears at once. 2. I am not sure what to do with the console which pops up under Windows. Under Wine it comes and goes. 3. When the cross-compiled version run under Wine the GUI thread throws an exception at the very end. It seems to come from the statusbar's WM_PAINT. I am clueless. 4. How can I convert the icons into ASCII to put them into the resource script? 5. Do we actually need textual output at all? Comments are welcome. Find the programs/winetest directory enclosed. A cross-compiled binary is also available at <http://afavant.elte.hu/~wferi/wine>. Feri.

5 4

Re: #3 - shell32/systray.c
by Mike Hearn Jan. 3, 2004

Jan. 3, 2004

Hi Steven, I have a pretty big patch against the system tray code, and it's going to get bigger. Hopefully in the next few days I will get time to properly reverse engineer (if it's not already documented) the interaction between shell32 and explorer, so we can implement this using a separate wineshell executable. Is there anything you need from us for ReactOS? If the message protocol is documented I guess you guys can just implement server support in your explorer for it, am I right? thanks -mike On Fri, 2004-01-02 at 15:37, Steven Edwards wrote: > When playing around with a app that uses the systray under ReactOS I > noticed that the comment in Wine is out of date. > > Changelog: > Update the notes in shell32 on how WINE uses the Systray under KDE. > > > > __________________________________ > Do you Yahoo!? > Find out what made the Top Yahoo! Searches of 2003 > http://search.yahoo.com/top2003

3 4

Re: Winex cvs
by David Hammerton Jan. 3, 2004

Jan. 3, 2004

Hi Peter, I'm guessing that you are probably using the sourceforge cvs - which it looks like we accidentally imported rewind into. That would explain why there is no d3d8 / d3d9. I'll remove the rewind import from sourceforge in a tick. Out of curiosity, where did you go that directed you to sourceforge? Is it some place that we have not updated? I suggest you check out www.transgaming.com and www.trasngaming.org (the later hosts CVS) if you wish to get the CVS version of WineX. Also, many people on this list would probably prefer it if you emailed the WineX-Devel list (hosted at www.transgaming.org) in the future. David -- David Hammerton WineX developer TransGaming Technologies Bus: +1 416 979 9900 x329 Fax: +1 416 979 9908 david(a)transgaming.com http://www.transgaming.com *Let the Games Begin* > Message: 1 > From: Peter Hartshorn <peter(a)dimtech.com.au> > Reply-To: peter(a)dimtech.com.au > To: wine-devel(a)winehq.org > Subject: Winex cvs > Date: Sun, 4 Jan 2004 00:57:26 +1100 > > I know that this is off topic, but I decided to see how the winex cvs > compared > to wine cvs. I done a checkout of winex from sourceforge.net and I > noticed > that the directories containing the d3d8 and 9 code had been removed > from > cvs. This prevented all of my games (gta3) from running under winex.

2 1

Direct3D8 - OpenGL header problem
by Thomas Brix Larsen Jan. 3, 2004

Jan. 3, 2004

Hi list, just upgraded to 2.6.0 and the NVIDIA driver from minion.de and now I get this error when compiling wine: directx.c: In function `IDirect3D8Impl_GetDeviceCaps': directx.c:639: `GL_MAX_VERTEX_UNITS_ARB' undeclared (first use in this function) My X11/include/GL/ headers date, 2001-2002. Greetings, --Thomas _________________ My worst enemy gave me a copy of Windows...

1 0

Re: Lostwages
by Jakob Eriksson Jan. 3, 2004

Jan. 3, 2004

Andreas Mohr wrote: > > >>4)Tell users of slow connections to use z9, as they probably have more processor >>power than bandwidth. >> >> >People should NOT use -z9 (we've been through this before), since it places >an abnormally sane (normally insane? :) burden on the CVS server. > > Isn't there a bug with some CVS clients or servers with the use of ANY -z but 0? /Jakob

4 4

Re: ntdll / kernel32: #40
by Alexandre Julliard Jan. 3, 2004

Jan. 3, 2004

Eric Pouech <pouech-eric(a)wanadoo.fr> writes: > This patch allows to use the UNIX code page inside of ntdll. > The full change log: > - moved code page & NLS resources from kernel32 to ntdll > - moved locale initialisation from kernel32 to ntdll > - created unix code page handling in ntdll > - made use of this unix cp for the initial environment creation (in PEB) I don't think I agree with that. IMO the locale stuff should remain in kernel32. We can simply set the unix codepage in ntdll the same way we set the other codepages. -- Alexandre Julliard julliard(a)winehq.com

2 2

Re: PATCH: Fix DLL constructors on OpenBSD
by wiml＠underhill.hhhh.org Jan. 3, 2004

Jan. 3, 2004

Alexandre Julliard writes: > The dll init routine needs to be in the .init section in order to be > called first, Isn't that what attribute((constructor)) does? It places a call to the routine in the .so's initialization section, whatever that section is, so that the routine gets invoked during dlopen(). As far as I know, it's equivalent to the asm() sections it replaces. For example, see the code emitted by BuildDebugFile() in spec32.c ... > attribute((constructor)) is not good enough. I'm perplexed. What is it that attribute((constructor)) does not do? Perhaps it has a different effect on OBSD than on other systems? How can I test whether it, or whatever asm code I replace it with, is doing the right thing? > Why doesn't it work on OpenBSD? Is the section name different? AFAICT, OpenBSD uses a section named .ctors containing function pointers, rather than a section containing 'call' opcodes. At least, that's what attribute((constructor)) emits, and looking through the dlfcn and C runtime sources I don't see any other initialization hooks being called. There *is* a section named .init, but any code placed there will be linked after the C function __init() in crtbeginS.c, and will not be executed because that C function returns normally. But the only thing that __init() does is invoke the functions pointed to by .ctors, and add a hook to make sure that the .dtors are called. Wim.

2 1