Hi folks,
it's often been said that wine can't use libsmbclient because
of license problems. I'd like to look at that assumption a bit.
- What would wine like to use libsmbclient for, if it could?
- Would it suffice to just link it in to wineserver, or would
it need to be invoked directly by al
On Fri, Oct 23, 2009 at 10:27 AM, Alexandre Julliard
wrote:
>> For process termination it's harmless, but for explicit unload it's a
>> leak. Probably a similar thread data tracking
>> should be added here too.
>
> In theory yes, but in general that's not necessary. Particularly for
> something li
Nikolay Sivov writes:
> For process termination it's harmless, but for explicit unload it's a
> leak. Probably a similar thread data tracking
> should be added here too.
In theory yes, but in general that's not necessary. Particularly for
something like msvcrt that won't get loaded and unloaded
Dan Kegel wrote:
MSDN says
"When a DLL is unloaded from a process as a result of an unsuccessful
load of the DLL, termination of the process, or a call to FreeLibrary,
the system does not call the DLL's entry-point function with the
DLL_THREAD_DETACH value for the individual threads of the proces
Dan Kegel wrote:
On Fri, Oct 23, 2009 at 9:37 AM, Nikolay Sivov wrote:
Did I miss something?
Sorry, I'm not fully awake (and I think the last time I was fully awake was
some time before I had children :-).
Same here I can tell you.
MSDN says
"When a DLL is unloaded from a process
On Fri, Oct 23, 2009 at 9:37 AM, Nikolay Sivov wrote:
> Did I miss something?
Sorry, I'm not fully awake (and I think the last time I was fully awake was
some time before I had children :-).
MSDN says
"When a DLL is unloaded from a process as a result of an unsuccessful
load of the DLL, terminat
Dan Kegel wrote:
On Fri, Oct 23, 2009 at 9:19 AM, Nikolay Sivov wrote:
Looking at msvcrt.dll._fcvt leak reported in recent results it's not quite
clear for me how could this happen.
It uses heap block allocated as thread data and it should be freed on
DLL_THREAD_DETACH.
Really? I don
On Fri, Oct 23, 2009 at 9:19 AM, Nikolay Sivov wrote:
> Looking at msvcrt.dll._fcvt leak reported in recent results it's not quite
> clear for me how could this happen.
> It uses heap block allocated as thread data and it should be freed on
> DLL_THREAD_DETACH.
Really? I don't see it being freed
Dan Kegel wrote:
http://kegel.com/wine/valgrind/logs/ is updated as usual, this time with
all of the log files I used to generate. For instance,
http://kegel.com/wine/valgrind/logs/2009-10-22-19.57-summary.txt
is a diff of just the first line of each error, to give you
a quick idea what changed.
On 10/23/2009 06:08 PM, Juan Lang wrote:
Wouldn't it be cleaner to change the use of the hardcoded c:\deadbeef.dbf?
I don't think so. The point is we expect the file not to be there,
and we're testing what the resulting GUID is when the file doesn't
exist. We're less concerned about the parti
> Wouldn't it be cleaner to change the use of the hardcoded c:\deadbeef.dbf?
I don't think so. The point is we expect the file not to be there,
and we're testing what the resulting GUID is when the file doesn't
exist. We're less concerned about the particular last error. I
suppose I could have
Charles Davis wrote:
> Charles Davis wrote:
>> Alexandre Julliard wrote:
>>> Charles Davis writes:
>>>
OK, thanks. Now I've got this straight. I should do something like
dlls/mountmgr.sys/device.c, where I'd have an NT device like
\Device\CdRom0 (or some such), whose FD I'd pass to
Charles Davis wrote:
> Alexandre Julliard wrote:
>> Charles Davis writes:
>>
>>> OK, thanks. Now I've got this straight. I should do something like
>>> dlls/mountmgr.sys/device.c, where I'd have an NT device like
>>> \Device\CdRom0 (or some such), whose FD I'd pass to the server so that
>>> when N
Alexandre Julliard wrote:
> Charles Davis writes:
>
>> OK, thanks. Now I've got this straight. I should do something like
>> dlls/mountmgr.sys/device.c, where I'd have an NT device like
>> \Device\CdRom0 (or some such), whose FD I'd pass to the server so that
>> when NTDLL opens the device and ge
Hello Alexandre,
It's a long time now since my last contrib to the wine project (1997),
and I try to run a proprietary W31/W95 program without any success :
It fails immediately with :
wine: Unhandled page fault on read access to 0x at address
0x124f:0x90f7 (thread 001c), starting
Charles Davis writes:
> OK, thanks. Now I've got this straight. I should do something like
> dlls/mountmgr.sys/device.c, where I'd have an NT device like
> \Device\CdRom0 (or some such), whose FD I'd pass to the server so that
> when NTDLL opens the device and gets its FD, it still has the CD-ROM
Alexandre Julliard wrote:
> Charles Davis writes:
>
>> OK, so let me see if I have all this straight: you want me to implement
>> some wine-specific IOCTLs in mountmgr that return the SCSI address and
>> anything else I can think of tha belongs in mountmgr. You also say that,
>> if necessary, I s
http://kegel.com/wine/valgrind/logs/ is updated as usual, this time with
all of the log files I used to generate. For instance,
http://kegel.com/wine/valgrind/logs/2009-10-22-19.57-summary.txt
is a diff of just the first line of each error, to give you
a quick idea what changed. (The logs are pre
Charles Davis writes:
> OK, so let me see if I have all this straight: you want me to implement
> some wine-specific IOCTLs in mountmgr that return the SCSI address and
> anything else I can think of tha belongs in mountmgr. You also say that,
> if necessary, I should pass an FD from mountmgr bac
19 matches
Mail list logo
