Hello,
Once again cross-posting because I would like to see if this is
something we can work together on. What is left to do for us to be able
to build and have a working implementation of stdole.tlb or any other
type libs? I ask because it seems Wines DCOM implementaton is almost
good enough for
Shachar Shemesh wrote:
[EMAIL PROTECTED]:~/sources/wine/threadtest$ time ../wine/wine Debug/main.exe
> /dev/null
Program exit 299732
Just for comparison, when running on Windows, I get as far as 298015,
but in less time.
Just for the record, if all the threads run to completion, and the mutex
Chipzz a écrit :
Hi all!
As a saw a few updates to the debugger a couple of days ago, I decided
to give the debugger another go. The problem with the stack trace is
gone now, but now I get another problem when I attach to a running
process, set a breakpoint and continue, the program crashes. When I
I find that there are several disturbing things here:
1. There is only one process. How did that happen?
you mean thread don't you ?
2. The debugger cannot load the debug info for my winelib application.
What the?
did you compile your winelib app with -g or -gstabs as it's supposed to be ?
A+
hehe i'm sorry about the sill errors...I will look over it very
carefully this time and make sure all the leaks are gone.
On Fri, 27 Aug 2004 12:28:45 -0700, Alexandre Julliard
<[EMAIL PROTECTED]> wrote:
> James Hawkins <[EMAIL PROTECTED]> writes:
>
> > Changelog
> > * make CryptSetProviderEx on
James Hawkins <[EMAIL PROTECTED]> writes:
> Changelog
> * make CryptSetProviderEx only delete the 'Name' value and not
> delete the entire 'Type XXX' key when deleting the default provider.
You are still leaking keys, and it doesn't even build (CryptCloseKey
is not a valid function). Please take
Is the attached patch correct?
yes
Shachar Shemesh <[EMAIL PROTECTED]> writes:
> #define NUMTHREADS 3000
>
> [...]
> WaitForMultipleObjects(NUMTHREADS, threads, TRUE, INFINITE);
That's probably not the cause of the deadlock, but you can't wait for
more than 64 objects with WaitForMultipleObjects, so your code won't
wait for th
James Hawkins <[EMAIL PROTECTED]> writes:
> Changelog
> * make CryptSetProviderEx only delete the 'Name' value and not
> delete the entire 'Type XXX' key when deleting the default provider.
You are still leaking key handles...
--
Alexandre Julliard
[EMAIL PROTECTED]
On 27 Aug 2004, Vincent Béron wrote:
> Just redirecting it to glibc would be trivial, but the problem is that's
> not the Right Thing To Do (tm) as both don't have exactly the same
> behavior, and that some apps rely on the msvcrt behavior (ie, break when
> using glibc's).
This part if fine. Now
Mike Hearn wrote:
However, the program doesn't run properly. When running it, I get
deadlocked.
Does anyone have any explanation? Is it a bug in my Win32 code?
Doubt it, it *looks* OK. But the acid test is to run it on Windows.
I've not used the mutex APIs much though, so could well be wrong.
er
On Fri, 27 Aug 2004, Michael Drüing wrote:
> Hi,
>
> running the program in WinXP results in an output like this:
> Failed to create thread 8
> Failed to create thread 8
> (repeated quite often)
> Failed to create thread 8
> Failed to create thread 8
> Program exit 33060
>
> Watching the prog
Le ven 27/08/2004 à 11:38, Saulius Krasuckas a écrit :
[snip]
> MSVCRT.DLL.SO fprintf() doesn't get redirected? OK, lets switch to glibc
> (or anything who works properly). Isn't it trivial to do?
Just redirecting it to glibc would be trivial, but the problem is that's
not the Right Thing To
I'm reading through msdn some more and they say ICC_STANDARD_CLASSES should
"Load one of the intrinsic User32 control classes. The user controls
include button, edit, static, listbox, combobox, and scrollbar."
If I'm remembering, those controls are already implemented in
wine/controls. Maybe ICC
Hi,
I've had a lot of people ask me about how well kazaa lite runs in
wine, so I will be working on getting it to work. The install file is
called klitekpp243e.exe, and the setup works great. (NOTE: im trying
to get the app to work without having to use any native dlls) After
the installatio
On Wed, 18 Aug 2004, Ferenc Wagner wrote:
> Saulius Krasuckas <[EMAIL PROTECTED]> writes:
> > On Wed, 18 Aug 2004, Ferenc Wagner wrote:
> >> The problem is that msvcrt's output functions aren't redirected by
> >> libc's filehandle operations, so winetest doesn't get the output (it
> >> gets printed
Hi,
running the program in WinXP results in an output like this:
Failed to create thread 8
Failed to create thread 8
(repeated quite often)
Failed to create thread 8
Failed to create thread 8
Program exit 33060
Watching the program with the taskmanager shows that it seems to only create
abo
However, the program doesn't run properly. When running it, I get
deadlocked.
Does anyone have any explanation? Is it a bug in my Win32 code?
Doubt it, it *looks* OK. But the acid test is to run it on Windows.
I've not used the mutex APIs much though, so could well be wrong.
err:ntdll:RtlpWaitFor
Hi list,
Attached is the epoll patch. All problems described in my previous patch
sent should be solved here. The only reason I'm not sending this to
wine-patches instead of here is that I have not yet had a chance to
check it on my client's huge system, and so I cannot say for sure that
all pr
Hi all,
Attached is a sample program, originally written to find out about the
impact of using epoll on performance.
However, the program doesn't run properly. When running it, I get
deadlocked.
Does anyone have any explanation? Is it a bug in my Win32 code?
err:ntdll:RtlpWaitForCriticalSection
-- Forwarded message --
From: James Hawkins <[EMAIL PROTECTED]>
Date: Fri, 27 Aug 2004 08:18:48 -0400
Subject: Re: Re: make CryptSetProviderEx update the provider Name and
TypeName to registry
To: Jakob Eriksson <[EMAIL PROTECTED]>
I sent in a patch earlier that added tests for Cry
Your knowledge of porting is evidently limited. The folks at the Fink
project would be surprised to learn that what they're doing is simple.
It's trivial compared to porting an app from a proprietary OS - I think
the existance of Winelib spells that out. Porting an app from Linux to
FreeBSD, So
Mike Hearn wrote:
This is the more general project that has emerged from my initial idea
for Darwine, namely X86/Linux binary compatibility for OS X.
Hmm, what is that useful for? Nearly all software for Linux is open
source and can be ported or sometimes simply recompiled for any given
platfo
> From: Mike McCormack
>
> This patch writes the output of the RTF parser into the edit
> control in
> 1024 byte chunks, and reads the input via a char[1024] buffer, rather
> than a linked list of single characters.
Not that it should matter very much, but the MS control always seems to
read t
"Roger Olson" <[EMAIL PROTECTED]> wrote:
> I am wondering why delete the CreateThread() code and refer all such
> requests
> to CreateRemoteThread()? It would appear to me that retaining the
> CreateThread()
> code in addition to and compliant with the patch changes would be more
> expeditious
>
This is the more general project that has emerged from my initial idea
for Darwine, namely X86/Linux binary compatibility for OS X.
Hmm, what is that useful for? Nearly all software for Linux is open
source and can be ported or sometimes simply recompiled for any given
platform. Do you have an
if I right click in the file open dialog, select a file and right click,
I get a context menu with English menu items.
Expected: I'll get a localized menu (e.g. in German).
Any idea how to get a localized version?
You'd have to internationalize that piece of code. As you already found,
it'd need
27 matches
Mail list logo
