On October 14, 2003 03:11 pm, Jason Filby wrote:
> I agree that forking should be avoided at all costs. Of course it
> will be unavoidable for lower level DLLs such as user32.
You are right, ReactOS will probably need it's own ntdll, and
maybe kernel. But for user32 and gdi32, I am hoping you ca
Robert Reif <[EMAIL PROTECTED]> writes:
> Adds support for wave driver name query to alsa and oss and wave tests.
> Adds SetVolume implementation to alsa.
You should use the standard Unicode functions like MultiByteToWideChar
(probably with CP_UNIXCP) to convert the device names.
--
Alexandre J
Michael Sauer <[EMAIL PROTECTED]> writes:
> The +relay traces are different most runs (depends on my load or
> how many printf's i put into wine source to find interesting places).
> Anyhow, there's one analogy between all the traces: the last function
> thread No'9 calls and does not return is al
> > err:ntdll:RtlpWaitForCriticalSection section 0x40969e80
> > "../../objects/gdiobj.c: GDI_level" wait timed out in thread 0009, blocked
> > by 0015, retrying (60 sec)
> > err:ntdll:RtlpWaitForCriticalSection section 0x40f227a0 "x11drv_main.c:
> > X11DRV_CritSection" wait timed out in thread 0015
Hi all
I agree that forking should be avoided at all costs. Of course it
will be unavoidable for lower level DLLs such as user32. I'm getting
the tail end of this discussion so someone please fill me in if I'm
missing some big issues. The big deal with be source control
differences between the two
Mike McCormack wrote:
I have some code for the mailslot implementation, but it's weekend
work for me. It would be pretty easy to wrap the test in a
todo_wine{} but we already know that none of the tests will pass, so
it won't prove much.
I think I'll just wait until I have an implementation
Rein Klazes <[EMAIL PROTECTED]> writes:
> The wine.conf man page says that in Snoop Include/Exclude specifiying
> .* includes the whole dll.
> This does not work: you have to specify without the ".*", at
> least that is the code.
>
> What should be corrected code or documentation?
The code actu
Michael Sauer <[EMAIL PROTECTED]> writes:
> I got this from running Panzer General 3 (which you can get for free at
> http://www.the-underdogs.org):
>
> err:ntdll:RtlpWaitForCriticalSection section 0x40969e80
> "../../objects/gdiobj.c: GDI_level" wait timed out in thread 0009, blocked
> by 0015, r
I got this from running Panzer General 3 (which you can get for free at
http://www.the-underdogs.org):
err:ntdll:RtlpWaitForCriticalSection section 0x40969e80
"../../objects/gdiobj.c: GDI_level" wait timed out in thread 0009, blocked
by 0015, retrying (60 sec)
err:ntdll:RtlpWaitForCriticalSection
On Thu, 16 Oct 2003, Mike McCormack wrote:
[...]
> I have some code for the mailslot implementation, but it's weekend work
> for me. It would be pretty easy to wrap the test in a todo_wine{} but
> we already know that none of the tests will pass, so it won't prove much.
>
> I think I'll just wait
Hi,
The wine.conf man page says that in Snoop Include/Exclude specifiying
.* includes the whole dll.
This does not work: you have to specify without the ".*", at
least that is the code.
What should be corrected code or documentation?
My guess it is the doc, here is the coorection.
Changelog:
Hi Robert,
It's probably easier to just go with the link file reader first, but it
will have some limitations:
1) you won't be able to get stuff in the shell namespace (eg. desktop
icons, Control panel stuff)
2) you'll have to hardcode the location of the start menu (you can
change the locati
Dimitrie O. Paun wrote:
Why not include it as a todo_wine{} in the tree? (if you are far away
with your mailslot impl, if not, I guess it can wait for it).
I have some code for the mailslot implementation, but it's weekend work
for me. It would be pretty easy to wrap the test in a todo_wine{} bu
Le mar 14/10/2003 à 13:05, Martin Troester a écrit :
> Hi,
>
> is there a reason that the for the Wine .dll.so libraries are not
> contained in the Wine Debian packages, especially libwine-dev? I mean,
> if I develop Winelib applications, I am going to need them anyway...
That's more a policy of
Hi,
is there a reason that the for the Wine .dll.so libraries are not
contained in the Wine Debian packages, especially libwine-dev? I mean,
if I develop Winelib applications, I am going to need them anyway...
Thanks for your help.
Regards,
Martin
On October 10, 2003 01:48 pm, Alexandre Julliard wrote:
> Geoff Thorpe <[EMAIL PROTECTED]> writes:
> > But if mailman can't do it, there would still be other ways to
> > organise this, only they would be uglier and trickier. Do we actually
> > know yet if someone at winehq will "let this happen"? A
On October 13, 2003 04:20 pm, Alex Pasadyn wrote:
> I think there are two separate problems that are being addressed, and it
> makes sense to have and document two stages of configuration. Step one
> doesn't ask too many questions (really just whether you want to use an
> existing "C" drive or not
We still have 72 HeapReAlloc() entries to validate:
./dlls/kernel/toolhelp.c:notifys=(struct notify*)HeapReAlloc(
GetProcessHeap(), 0, notifys,
./dlls/kernel/toolhelp.c:notifys=(struct notify*)HeapReAlloc( GetProcessHeap(), 0,
notifys,
./dlls/kernel/local16.c:ptr = HeapReAll
Only 33 non HeapReAlloc entries remain:
./controls/edit.c: hloc32W_new = LocalReAlloc(es->hloc32W,
alloc_size, LMEM_MOVEABLE | LMEM_ZEROINIT);
./controls/edit.c: if ((hNew32W = LocalReAlloc(es->hloc32W, alloc_size,
LMEM_MOVEABLE | LMEM_ZEROINIT))) {
./controls/edit.c:
"Dimitrie O. Paun" <[EMAIL PROTECTED]> writes:
> Hi folks,
>
> Oleg has been doing a lot of good work, and we are now
> down to 73 HeapReAlloc and 73 non-HeapReAlloc entries
> to review. I'm still not sure how the comctl32.ReAlloc()
> should behave, any help in getting that resolved would
> be hig
On Monday 13 October 2003 04:56 pm, Ivan Leo Murray-Smith wrote:
> There already is an app that can do the menus, the ros explorer. If it was
> compiled as a winelib app, it would solve the menu problem, at least for
> who likes desktop mode (And the ros explorer makes wine look like a "real"
> emu
21 matches
Mail list logo
