2009/2/17 Vincent Povirk madewokherd+8...@gmail.com:
My opinion on this particular issue doesn't matter, but we don't
strictly prevent Windows apps from seeing the underlying Linux
environment. Any app can make linux system calls, access the filename
conversion functions, invoke linux
On Mon, Feb 16, 2009 at 12:14 PM, Francois Gouget fgou...@free.fr wrote:
From what I understand, they're not accessible to full win32 apps.
FWIW, it's kernel32.wine_get_unix_file_name(). So it's available to any
Win32 application that knows about it. Just LoadLibrary()+GetProcAddress().
This
Is a shame that a lot of discussions on wine-devel has to end like this.
A new people propose something that he things is the solution to a
problem he has in wine.
And all the 'established' developers try to find as much
It is unfortunate that many discussions here on wine-devel to end
On Tue, Feb 17, 2009 at 4:35 AM, Martin Hinner mar...@hinner.info wrote:
Just to add few comments at once, the problem is solved for us
(libwinegate.dll.so is shipped with the software, we'll have to
recompile it when libwine/libc changes...),
Wait, what can winegate do that
hdll =
On Tue, Feb 17, 2009 at 3:34 PM, Dan Kegel d...@kegel.com wrote:
On Tue, Feb 17, 2009 at 4:35 AM, Martin Hinner mar...@hinner.info wrote:
Just to add few comments at once, the problem is solved for us
(libwinegate.dll.so is shipped with the software, we'll have to
recompile it when
On Tue, Feb 17, 2009 at 6:42 AM, Martin Hinner mar...@hinner.info wrote:
hdll = LoadLibraryA(libwine.dll);
wine_dlopen = GetProcAdress(hdll, wine_dlopen);
wine_dlsym = GetProcAdress(hdll, wine_dlsym);
wine_dlclose = GetProcAdress(hdll, wine_dlclose);
The above doesn't work ... LoadLibraryA
On Tue, Feb 17, 2009 at 8:56 AM, Dan Kegel d...@kegel.com wrote:
They really are very simple wrappers around Unix system
calls. There's no reason you can't write your own wrappers
in assembly inside your winegate, they would probably
only be ten lines or so each.
According to the man page,
On Tue, Feb 17, 2009 at 7:10 AM, Vincent Povirk
madewokherd+8...@gmail.com wrote:
On Tue, Feb 17, 2009 at 8:56 AM, Dan Kegel d...@kegel.com wrote:
They really are very simple wrappers around Unix system
calls. There's no reason you can't write your own wrappers
in assembly inside your
2009/2/18 Marco Meijer ma...@mandrivaclub.nl:
It is unfortunate that many discussions here on wine-devel to end this way.
A new developer thinks he has solved a problem he has in wine, and wants to
share the solution with the rest of the community.
And 'the established' developers try to find
The problems with this concept have already been discussed
(such as calling conventions).
This is a problem for trying to expose a linux .so as a windows .dll,
as the interface is almost never identical. It's not a problem for a
program that is explicitly written to use a linux .so.
I believe
On Sun, 15 Feb 2009, Ben Klein wrote:
2009/2/15 Dan Kegel d...@kegel.com:
On Sat, Feb 14, 2009 at 5:11 PM, Ben Klein shackl...@gmail.com wrote:
[...]
I think that's not quite true. There are a couple supported
wine extensions to win32, aren't there? I think there's
an ioctl to get the
I don't want to be rude, but I have better things to do than
propagandize my solution. We can live without such library in Wine, it
would just require us to maintain separate libraries for different
libc or wine versions. Having it in wine distribution would solve this
problem smoothly,
On So, 2009-02-15 at 01:02 +0100, Martin Hinner wrote:
- It's already present in Wine:
libwine.dll has exports for wine_dlopen/wine_dlclose/wine_dlsym
please read: libs/wine/loader.c
I saw it, but I don't understand how is it exported to the Win32
world, i.e. how do I import these
Detlef,
On Sun, Feb 15, 2009 at 12:50 PM, Detlef Riekenberg wine@web.de wrote:
Just use this infos:
hdll = LoadLibraryA(libwine.dll);
wine_dlopen = GetProcAdress(hdll, wine_dlopen);
wine_dlsym = GetProcAdress(hdll, wine_dlsym);
wine_dlclose = GetProcAdress(hdll, wine_dlclose);
The
On Sun, Feb 15, 2009 at 3:37 AM, Roderick Colenbrander
thunderbir...@gmx.net wrote:
I don't want to be rude, but I have better things to do than
propagandize my solution. We can live without such library in Wine, it
would just require us to maintain separate libraries for different
libc or
On Sa, 2009-02-14 at 05:39 +0100, Martin Hinner wrote:
Hello,
I have created a small library to allow Win32 applications running
under Wine to load native Unix shared libraries (.so). First (one-hour
hack) version is available at
http://martin.hinner.info/tmp/winegate.tar.gz ; Please
On Fr, 2009-02-13 at 22:44 -0800, Dan Kegel wrote:
Very interesting.
... but not needed
I'd been suggesting to ISVs that they create a single
winelib dll and conditionally load that if present,
but winegate.dll might be an appealing alternative.
Use wine_dlopen/wine_dlclose/wine_dlsym from
On Sun, Feb 15, 2009 at 12:35 AM, Detlef Riekenberg wine@web.de wrote:
On Sa, 2009-02-14 at 05:39 +0100, Martin Hinner wrote:
Hi Martin.
Thanks for your interest in Wine.
I read your Mail, and my first impresion was: not needed
After downloading winegate.tar.gz and reading the source:
Dan,
On Sat, Feb 14, 2009 at 7:44 AM, Dan Kegel d...@kegel.com wrote:
I'd been suggesting to ISVs that they create a single
winelib dll and conditionally load that if present,
but winegate.dll might be an appealing alternative.
I think wine needs some universal library so as there is not 20
Ben,
On Sat, Feb 14, 2009 at 7:10 AM, Ben Klein shackl...@gmail.com wrote:
2009/2/14 Martin Hinner mar...@hinner.info:
Wine is (or has been) working on a driver system to handle native
Windows USB device drivers via libusb, for things like printers and
scanners where there are no Linux-native
2009/2/15 Martin Hinner mar...@hinner.info:
If wine-team decides not to include this (or similar .dll) in the Wine
package, we'll just redistribute it with the application, but I think
there is need for such library.
You repeat yourself in another post:
2009/2/15 Martin Hinner
Martin Hinner wrote:
Hello,
Purpose of this Wine DLL is to allow Windows applications to use
directly Unix library functions. This is useful for example for
applications which talk to specific drivers and it's not
efficient/possible to create system native DLL for such driver or
Martin Hinner wrote:
On Sun, Feb 15, 2009 at 12:35 AM, Detlef Riekenberg wine@web.de wrote:
- It's already present in Wine:
libwine.dll has exports for wine_dlopen/wine_dlclose/wine_dlsym
please read: libs/wine/loader.c
I saw it, but I don't understand how is it exported to the Win32
On Sat, Feb 14, 2009 at 5:11 PM, Ben Klein shackl...@gmail.com wrote:
You obviously don't understand how Wine works. It's not in win32, nor
is it in any other API standard Wine has to deal with (such as
Directx). It won't be shipped with Wine.
I think that's not quite true. There are a couple
VItaliy,
On Sun, Feb 15, 2009 at 3:21 AM, Vitaliy Margolen
wine-de...@kievinfo.com wrote:
Depending on what you need to do it might be a good thing or might be a
complete no-go. Remember that Wine has an additional layer on top of system.
If you bypass it, you can potentially create lots and
2009/2/15 Dan Kegel d...@kegel.com:
On Sat, Feb 14, 2009 at 5:11 PM, Ben Klein shackl...@gmail.com wrote:
You obviously don't understand how Wine works. It's not in win32, nor
is it in any other API standard Wine has to deal with (such as
Directx). It won't be shipped with Wine.
I think
Martin Hinner wrote:
reducing our task only to maintain native Linux
shared lib for hardware access.
Which means you'll have to maintain it anyway. No, what you proposed not
going to fly. It can not work within Wine. It's called hack and things
with that name not getting into Wine.
Vitaliy
Hello,
I have created a small library to allow Win32 applications running
under Wine to load native Unix shared libraries (.so). First (one-hour
hack) version is available at
http://martin.hinner.info/tmp/winegate.tar.gz ; Please consider
inclusion in WINE tree (dll/ directory). Please note
2009/2/14 Martin Hinner mar...@hinner.info:
Purpose of this Wine DLL is to allow Windows applications to use
directly Unix library functions. This is useful for example for
applications which talk to specific drivers and it's not
efficient/possible to create system native DLL for such
Hi,
On Sat, Feb 14, 2009 at 6:31 AM, Ben Klein shackl...@gmail.com wrote:
2009/2/14 Martin Hinner mar...@hinner.info:
Purpose of this Wine DLL is to allow Windows applications to use
directly Unix library functions. This is useful for example for
applications which talk to specific drivers
2009/2/14 Martin Hinner mar...@hinner.info:
Hi,
On Sat, Feb 14, 2009 at 6:31 AM, Ben Klein shackl...@gmail.com wrote:
2009/2/14 Martin Hinner mar...@hinner.info:
Purpose of this Wine DLL is to allow Windows applications to use
directly Unix library functions. This is useful for example for
Very interesting.
I'd been suggesting to ISVs that they create a single
winelib dll and conditionally load that if present,
but winegate.dll might be an appealing alternative.
I don't think this really brings up any security considerations
but it is a reminder that Windows programs under Wine
32 matches
Mail list logo