Actually, what we want is exactly what we currently do: native Windows
dll already call into ELF libraries (albeit special ELF files).
Yes, but we can do this because we control the dynamic linker. The only
reason I can think of (are there others?) to build the DLLs as real PE
DLLs is so apps tha
Le mar 07/09/2004 à 09:50, Mike Hearn a écrit :
> > I'm wondering what would actually be needed for an analogous
> > 'crossdll' target. The reason or one of the reasons for the current
> > practice of out-of-tree cross builds is that Wine's build tools
> > should not be cross compiled, correct? An
I'm wondering what would actually be needed for an analogous
'crossdll' target. The reason or one of the reasons for the current
practice of out-of-tree cross builds is that Wine's build tools
should not be cross compiled, correct? Any other obstacle?
Well, as I said before the main reason to do i
On Tuesday 7 September 2004 10:58, Mike Hearn wrote:
> Well, we seem to be in a bit of a quandry then. Some apps require the
> DLLs to be physically present, and others can't deal with it if they are
> but empty. So the only solution seems to be to actually have real PE
> DLLs in the virtual wi
Hi,
On Tue, Sep 07, 2004 at 09:58:44AM +0100, Mike Hearn wrote:
> >It's not that the app wants the dll to be empty, it's that it can deal
> >with the file not being there at all, but it can't deal with the file
> >being there but empty (since that would never happen on Windows). So
> >in many case
It's not that the app wants the dll to be empty, it's that it can deal
with the file not being there at all, but it can't deal with the file
being there but empty (since that would never happen on Windows). So
in many cases creating empty files makes things worse than not having
the files at all.
W
Mike Hearn <[EMAIL PROTECTED]> writes:
> On Sat, 2004-09-04 at 15:49, Vincent Béron wrote:
>> How? Remove a particular touched dll from c:\windows\system? If you have
>> two apps, one wanting the 0-sized dll and the other one choking on it,
>> what do you do?
>
> Well I doubt any app actually reli
I have completely hand-installed DirectX 9.0c at this time along with
dxdiag.exe and additional DXMedia runtime components along with the
DCOM and several other subsystems from Windows 2000 professional
Well, native DirectX (DirectDraw+Direct3D at least) requires some
kernel/driver support tha
-- codebase introduction/induction documentation, anything? --
Im new to the wine codebase and see several bugs I am wanting to handle,
however my main concern at this immediate time is trying to sort out
cross-compatability issues...
I have completely hand-installed DirectX 9.0c at this time
On Sat, Sep 04, 2004 at 04:08:11PM +0100, Mike Hearn wrote:
> On Sat, 2004-09-04 at 15:49, Vincent B??ron wrote:
> > What we could do is if such a cross-compiler is detected at build time,
> > use it to build PE dlls in addition to ELF dlls (or in place of? Not
> > sure yet). If no cross-compiler i
On Sat, 2004-09-04 at 15:49, Vincent BÃron wrote:
> What we could do is if such a cross-compiler is detected at build time,
> use it to build PE dlls in addition to ELF dlls (or in place of? Not
> sure yet). If no cross-compiler is detected, nothing different from now
> happens.
That would lead to
On Sat, 2004-09-04 at 15:45, Hans Leidekker wrote:
> On Saturday 4 September 2004 16:29, Mike Hearn wrote:
>
> > Well, yes, I know. But solving that one 100% reliably means making a
> > cross compiler a buildreq of Wine, and that would be a big pain not to
>
> That would be developer pain traded
Le sam 04/09/2004 à 10:29, Mike Hearn a écrit :
> On Sat, 2004-09-04 at 14:52, Hans Leidekker wrote:
> > You could make it look like a valid PE file by just adding a
> > PE header, but the next failure would probably be on accessing
> > some resource or something else inside the DLL.
>
> Well, ye
On Saturday 4 September 2004 16:29, Mike Hearn wrote:
> Well, yes, I know. But solving that one 100% reliably means making a
> cross compiler a buildreq of Wine, and that would be a big pain not to
That would be developer pain traded for user pain. We like that don't we?
> mention the difficulty
On Sat, 2004-09-04 at 14:52, Hans Leidekker wrote:
> You could make it look like a valid PE file by just adding a
> PE header, but the next failure would probably be on accessing
> some resource or something else inside the DLL.
Well, yes, I know. But solving that one 100% reliably means making a
On Saturday 4 September 2004 15:28, Mike Hearn wrote:
> LoadLibrary should check the Wine DLL path first, as far as I know at
> least for DLLs that default to builtin. So if the program does
> LoadLibrary("c:\windows\system\user32.dll") for instance, it should still
> load the builtin DLL just fin
On Sat, 04 Sep 2004 15:15:33 +0200, Hans Leidekker wrote:
> There are applications (eDonkey is one of them IIRC) that call
> LoadLibray() themselves on a number of DLLs.
LoadLibrary should check the Wine DLL path first, as far as I know at
least for DLLs that default to builtin. So if the program
On Saturday 4 September 2004 14:25, Mike Hearn wrote:
> Make apps that search for the DLL files directly happy by creating empty
> files for each shipped library
There are applications (eDonkey is one of them IIRC) that call
LoadLibray() themselves on a number of DLLs. Could be that they do
their
18 matches
Mail list logo
