"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.
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
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.
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
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.
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...
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
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
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.
