On Fri, Jul 19, 2013 at 5:50 PM, Julian Rüger wrote:
> Hi Frédéric,
>
>> - $(CC) $(CC_OPTS) -DRC_INVOKED -E -x c $< | $(WRC) -N $(WRCFLAGS)
>> $(WINELIB_FLAGS) -o $@
>> + $(CC) $(CC_OPTS) -DRC_INVOKED -E -x c $lt; | $(WRC) -N $(WRCFLAGS)
>> $(WINELIB_FLAGS) -o $@
>
> looks like you forgo
Hi Frédéric,
> - $(CC) $(CC_OPTS) -DRC_INVOKED -E -x c $< | $(WRC) -N $(WRCFLAGS)
> $(WINELIB_FLAGS) -o $@
> + $(CC) $(CC_OPTS) -DRC_INVOKED -E -x c $lt; | $(WRC) -N $(WRCFLAGS)
> $(WINELIB_FLAGS) -o $@
looks like you forgot the "&".
Best,
Julian
Hi,
Well, your testcase had a trivial mistake which i now see.
This line:
typedef struct AEffect * (*main_entry_t)(audioMasterCallback);
must read:
typedef struct WINAPI AEffect * (*main_entry_t)(audioMasterCallback);
WINAPI is critical here, as it changes the call from the SysV AMD64
calling
Hey Marcus,
> Can you add a
> printf("plugin %p\n", plugin);
> after above line?
>
> I would suspect things like:
> - checks for processor features and returns 0x if not found.
I added this line to the sources / compiled and tested - here is
output: http://pastebin.com/QMtWttRZ
executable that load a really simple DLL (it is a test)
> and I want to create a Winelib DLL that will override the Windows DLL.
> Basically, I created mylib_main.c and mylib.spec to build the Winelib DLL
> with the command:
> > winegcc -mwindows -o mylib.dll.so mylib_main.c -I${WINE_ROO
able that load a really simple DLL (it is a test) and
> I want to create a Winelib DLL that will override the Windows DLL. Basically,
> I created mylib_main.c and mylib.spec to build the Winelib DLL with the
> command:
> winegcc -mwindows -o mylib.dll.so mylib_main.c -I${WINE_ROOT}/in
Hey Marcus
> Works for me on my AMD Phenom(tm) II X4 945 Processor.
great :) (very similar CPU).
> It looks like the
> struct AEffect* plugin = main_entry((audioMasterCallback)
> simple_master_callback);
>
> returns 0x, which is probably a failure indication.
>
> Can you add a
able that load a really simple DLL (it is a test)
> and I want to create a Winelib DLL that will override the Windows DLL.
> Basically, I created mylib_main.c and mylib.spec to build the Winelib DLL
> with the command:
> winegcc -mwindows -o mylib.dll.so mylib_main.c -I${WINE_ROOT}/include
Hi,
First, I already asked for the same thing at the forum where I've been
told to post here for my question
Link here : http://forum.winehq.org/viewtopic.php?f=8&t=18675
I have a Windows executable that load a really simple DLL (it is a test)
and I want to create a Winelib DLL
On Thu, Apr 04, 2013 at 07:39:16PM -0400, jordan wrote:
> Hey List,
>
> A few days ago, i posted to the list about possibly porting a winelib
> app to support x86_64. (currently supports x86).
>
> the original post is here (for those interested, but not entirely
> relevant
> Hello!
Hey Gediminas! ;)
> Works fine on my AMD system:
Can you also give me the rest of your specs / distro, please?
> vinis@g44:/media/vinis/code/temp/fsthost-code$
> WINEPREFIX=/media/vinis/bottles/test64 ./test64.exe ../ColourEQ_64.dll
> Load plugin ../ColourEQ_64.dll
> fixme:heap:HeapSet
On Fri, Apr 5, 2013 at 3:36 AM, jordan wrote:
> It's been tested with several wine versions (1.4.1, 1.5.24, 1.5.27).
> On intel systems, it works on ALL versions. On my AMD system, it
> doesn't work at all.
Hello!
Works fine on my AMD system:
vinis@g44:/media/vinis/code/temp/fsthost-code$
WINEPR
Hey Andre.
> only thing that comes to mind is that you need gcc>=4.4, but configure checks
> that for you.
> Did you tried the binaries of your intel mate?
Well, i am using gcc-4.8 (but have also tested with gcc-4.7.3/4). He
is using gcc 4.7.3 or .4.
No, i did not try his binaries ~ but that is
Am 05.04.2013 02:36, schrieb jordan:
> Hey Andre,
>
>> was it the same binary or did you compiled it on each cpu?
>> Do you have the same Wine versions?
>
> Compiled on each respective system. (no sharing of binaries).
>
> It's been tested with several wine versions (1.4.1, 1.5.24, 1.5.27).
> On
Hey Andre,
> was it the same binary or did you compiled it on each cpu?
> Do you have the same Wine versions?
Compiled on each respective system. (no sharing of binaries).
It's been tested with several wine versions (1.4.1, 1.5.24, 1.5.27).
On intel systems, it works on ALL versions. On my AMD s
Am 05.04.2013 02:06, schrieb jordan:
> Hey Austin
>
>> Are y'all using the same OS/distro/kernel/gcc/libc versions?
>
> Different (distro) but everything else is very similar, if not the
> same. My feeling is that this is not going to end up being the problem
> and if i remember correctly, the 2
Hey Austin
> Are y'all using the same OS/distro/kernel/gcc/libc versions?
Different (distro) but everything else is very similar, if not the
same. My feeling is that this is not going to end up being the problem
and if i remember correctly, the 2 Intel systems are not the same
either..
But just
On Thu, Apr 4, 2013 at 6:39 PM, jordan wrote:
> Hey List,
>
> A few days ago, i posted to the list about possibly porting a winelib
> app to support x86_64. (currently supports x86).
>
> the original post is here (for those interested, but not entirely
> relevant to this p
Hey List,
A few days ago, i posted to the list about possibly porting a winelib
app to support x86_64. (currently supports x86).
the original post is here (for those interested, but not entirely
relevant to this post):
http://wine.1045685.n5.nabble.com/exploring-possibly-porting-winelib-app-to
Hi Andre,
>> Entry Pt Ordn Name
>> 00012900 1 VSTPluginMain
>> 00012900 2 main
>
> so with:
>> 0042:Call KERNEL32.GetProcAddress(18000,7f77bb3950b0 "VSTPluginMain")
>> ret=7f77bb394182
>> 0042:Ret KERNEL32.GetProcAddress() retval=180012900 ret=7f77bb394182
>
> it looks as exp
Am 01.04.2013 20:28, schrieb jordan:
> Hi Andre,
>
>>> Can anyone offer any help / advice on how to determine / confirm that
>>> address returned by GetProcAddress is correct in our test64.exe??
>>
>> I doubt that's the problem, but to really confirm it i'd need a:
>> winedump -j export yourvst.dl
Hi Andre,
>> Can anyone offer any help / advice on how to determine / confirm that
>> address returned by GetProcAddress is correct in our test64.exe??
>
> I doubt that's the problem, but to really confirm it i'd need a:
> winedump -j export yourvst.dll
Okay, I am trying to load Automation.dll wi
Am 01.04.2013 19:56, schrieb jordan:
> Can anyone offer any help / advice on how to determine / confirm that
> address returned by GetProcAddress is correct in our test64.exe??
I doubt that's the problem, but to really confirm it i'd need a:
winedump -j export yourvst.dll
Hi Daniel
> This is a little off-topic from the original thread, but I think 64-bit Wine
> works pretty well. Our ArcGIS Server > on Linux is exclusively 64-bit and is
> in use by some large organizations.
..and those 'large organizations' are not the only one's out there
using Wine64. ;)
I t
> probably Wine's 64-bit support, since that's a little-used feature).
>
This is a little off-topic from the original thread, but I think 64-bit Wine
works pretty well. Our ArcGIS Server on Linux is exclusively 64-bit and is in
use by some large organizations
Hey Vincent,
First thank you for your input :)
On Mon, Apr 1, 2013 at 11:57 AM, Vincent Povirk wrote:
> Given that Wine uses winelib for its builtin exe's and dll's, and that
> the way it works is not much different from a PE exe or dll, I don't
> think winelib is likely
Given that Wine uses winelib for its builtin exe's and dll's, and that
the way it works is not much different from a PE exe or dll, I don't
think winelib is likely to be at fault here. My guess is that you are
running into an ordinary Wine bug relating to your specific dll (and
pro
Hi list.
A friend of mine and myself, have been exploring expanding a (currently,
32bit only) winelib app to support 64bit plugins in wine (64). The app is
called FSThost, which is used to host win32 VST instruments and effects
(.dll) as a standalone app in Gnu/linux. Webpage:
http
what can i do then to setup the wine environment correctly
>> and use the wine libraries from fpc.
>> thanks
>
> Essentially what you need to do is to write your application as a winelib
> application. That means it will have a code similar to a Win32 EXE but will be
> i
the wine libraries from fpc.
> thanks
Essentially what you need to do is to write your application as a winelib
application. That means it will have a code similar to a Win32 EXE but will be
in ELF format.
I have no idea if/how you can do that using fpc.
An alternative would be to write a winelib
>>This won't work. Simply doing a dlopen on the wine libraries won't get
>>your environment setup properly.
what can i do then to setup the wine environment correctly
and use the wine libraries from fpc.
thanks
--
*
En la tierra
On Mon, Aug 29, 2011 at 2:05 PM, Reinier Napoles Martinez
wrote:
> lib:=dlopen('/usr/lib/wine/user32.dll.so',1);
This won't work. Simply doing a dlopen on the wine libraries won't get
your environment setup properly.
--
Steven Edwards
"There is one thing stronger than all the armies in the w
best regards
I would like to know
if it is possible to use the wine libraries with freepascal compiler.
kylix had a modified version of the wine libraries and I believe that it was
possible to invoke them from pascal.
I've tried several ways but all I get is "segment fault".
sorry for my Englis
alright, so heres how it works:
first, you need to pass spec into the right place, heres the output of the
make file.
winegcc -c -mno-cygwin -m32-o zmq.o zmq.c
winegcc -shared zmq.dll.spec -mno-cygwin -o zmq.dll.so zmq.o -lzmq
next, you need to make sure to include in zmq.c and put WIN
So i
thought this would be the best option. I know its simple to do, i just dont
know what im doing wrong...
On Thu, Nov 18, 2010 at 8:59 PM, Seth Burleigh wrote:
>
> Im trying to build a simple winelib. Its not working and is returning
> 'error 127'. I have some question:
&g
Im trying to build a simple winelib. Its not working and is returning 'error
127'. I have some question:
(1) how do i determine which functions are exported by wine? All i see using
nm zmq.dll.so is the names of my proxy function (add_proxy) instead of the
name that is going to be cal
Thanks all! I got it to work! There was 2 mistakes with my thing -
first, i had an empty definition for DllMain which caused the error 126
and then , well, i called the wrong function from metatrader. I shouldve
been calling MyWinFunction. I guess i wasn't doing this because i wasn't
seeing it whe
Am 17.06.2010 04:52, schrieb Seth Burleigh:
> OK, so i have the dll built. However, it doesn't seem to be able to
> open. Let me explain, im using it in metatrader and so all im doing is
> moving the dll.so (and renamed it to MyWin.dll) to its libraries folder
> and doing an import statement in mq
OK, so i have the dll built. However, it doesn't seem to be able to
open. Let me explain, im using it in metatrader and so all im doing is
moving the dll.so (and renamed it to MyWin.dll) to its libraries folder
and doing an import statement in mql4. However, i then get a system
error 'Cannot load
Well, adding the -shared worked! Thanks! Is there any way i can get
winemaker to do this automatically? I thought the -dll option would
work?
Am 16.06.2010 15:50, schrieb Seth Burleigh:
> Thanks, the example helped, i added in the dll main part. But im still
> getting the WinMain error and im convinced it has something to do with
> how im executing winemaker.
>
> winemaker . --nosource-fix --dll --single-target MyWin --nomfc -I"."
> -L"
Thanks, the example helped, i added in the dll main part. But im still
getting the WinMain error and im convinced it has something to do with
how im executing winemaker.
winemaker . --nosource-fix --dll --single-target MyWin --nomfc -I"."
-L"." -iMyLinuxFunc
The new command line result of make is
, Jun 16, 2010 at 2:04 AM, Seth Burleigh wrote:
> Im attempting to build a dll which a windows program running under wine
> can dynamically load. The dll will be a wrapper around a linux library.
> In preparation ive tried to follow the instructions here
> http://www.winehq.org/docs/
Im attempting to build a dll which a windows program running under wine
can dynamically load. The dll will be a wrapper around a linux library.
In preparation ive tried to follow the instructions here
http://www.winehq.org/docs/winelib-guide/bindlls
with a simple example but have not succeeded
--- On Fri, 16/4/10, Marcus Meissner wrote:
> On Fri, Apr 16, 2010 at 10:51:29PM
> +0200, André Hentschel wrote:
> > ---
> > tools/winegcc/winegcc.c |8
>
> > 1 files changed, 8 insertions(+), 0
> deletions(-)
> >
> > diff --git a/tools/winegcc/winegcc.c
> b/tools/winegcc/winegcc.c
On 4/16/10 2:51 PM, André Hentschel wrote:
> ---
> tools/winegcc/winegcc.c |8
> 1 files changed, 8 insertions(+), 0 deletions(-)
>
> diff --git a/tools/winegcc/winegcc.c b/tools/winegcc/winegcc.c
> index 7023ff4..f780a69 100644
> --- a/tools/winegcc/winegcc.c
> +++ b/tools/winegcc/w
On Fri, Apr 16, 2010 at 10:51:29PM +0200, André Hentschel wrote:
> ---
> tools/winegcc/winegcc.c |8
> 1 files changed, 8 insertions(+), 0 deletions(-)
>
> diff --git a/tools/winegcc/winegcc.c b/tools/winegcc/winegcc.c
> index 7023ff4..f780a69 100644
> --- a/tools/winegcc/winegcc.c
>
On Tue, Sep 29, 2009 at 3:01 PM, Greg Geldorp wrote:
>> From: Paul Vriens [mailto:paul.vriens.w...@gmail.com]
>>
>> Can't we just compile shell32 tests as a GUI app?
>
> I don't think that will work, but I'll look into it. Wine tests expect
> to have access to stdout. At the very least you won't s
> From: Paul Vriens [mailto:paul.vriens.w...@gmail.com]
>
> Can't we just compile shell32 tests as a GUI app?
I don't think that will work, but I'll look into it. Wine tests expect
to have access to stdout. At the very least you won't see output when
running the test manually on Windows. Not sure
t the IMAGE_DOS_HEADER, follow it to the IMAGE_NT_HEADERS and just patch the
OptionalHeaders.Subsystem field.
My limited understanding of the structure of Winelib executables makes doing
the same for testing on Wine quite a bit harder. I assume there's still a
IMAGE_NT_HEADERS structure in there som
Greg Geldorp writes:
> My limited understanding of the structure of Winelib executables makes doing
> the same for testing on Wine quite a bit harder. I assume there's still a
> IMAGE_NT_HEADERS structure in there somewhere and with some research I'll
> probably be able to
ADERS and just patch the
OptionalHeaders.Subsystem field.
My limited understanding of the structure of Winelib executables makes doing
the same for testing on Wine quite a bit harder. I assume there's still a
IMAGE_NT_HEADERS structure in there somewhere and with some research I'll
prob
ow if it's
actually possible to call decorated Dll functions from a winelib
application.
Therefore I'm going to use LoadLibrary et.al. which is a bit tiresome with
300 exported functions but at least is guaranteed to work.
Thomas
On Sat, Aug 22, 2009 at 11:17 AM, Juan Lang wrote:
>> 1) Creating a vendor.def file doesn't work. The resulting file has an empty
>> EXPORTS section:
>>
>> winedump spec vendor.dll
>> winebuild --def -E vendor.spec -o vendor.def
>
> That seems to mean winedump isn't parsing this right, or that it t
> I have a windows dll without source code (vendor.dll) that I want to use in
> a winelib application.
>
> 1) Creating a vendor.def file doesn't work. The resulting file has an empty
> EXPORTS section:
>
> winedump spec vendor.dll
> winebuild --def -E vendor.spec -o v
Thomas Trummer schrieb:
> Hi,
>
> I have a windows dll without source code (vendor.dll) that I want to use
> in a winelib application.
>
> There are two problems however:
>
> 1) Creating a vendor.def file doesn't work. The resulting file has an
> empty EXP
Hi,
OK, a minute after I sent the mail I figured out number two:
For vendor.dll the corresponding .def file has to be called libvendor.def.
I still need help with point one, though.
Thomas
Hi,
I have a windows dll without source code (vendor.dll) that I want to use in
a winelib application.
There are two problems however:
1) Creating a vendor.def file doesn't work. The resulting file has an empty
EXPORTS section:
winedump spec vendor.dll
winebuild --def -E vendor.sp
On Tue, Aug 18, 2009 at 7:44 AM, Maarten
Lankhorst wrote:
> Hi Jesse,
>
> 2009/8/12 Jesse Allen :
>> Oh that may have been the correct way for vmrender.idl, but the patch
>> you proposed of protecting with a struct does compile. My app does
>> not use a VMRGUID, so I don't know if it really works
Hi Jesse,
2009/8/12 Jesse Allen :
> Oh that may have been the correct way for vmrender.idl, but the patch
> you proposed of protecting with a struct does compile. My app does
> not use a VMRGUID, so I don't know if it really works :)
Commit a664043e1d1e93bcbe2 fixes this in the cleanest way for
On Tue, Aug 11, 2009 at 7:30 AM, Maarten
Lankhorst wrote:
> Hi Jesse,
>
> Judging by that link you sent me, shouldn't it be:
>
> typedef struct tagVMRGUID
> {
> #if defined(__cplusplus)
> ::GUID *pGUID, GUID;
> #else
> GUID *pGUID, GUID;
> #endif
> } VMRGUID;
>
> Or am i reading that link wrong
everytime.
Can you take a look at the problem? I think we will want this to work
for winelib on g++ as it's pretty well dependent.
Main problem is of course the msvc compiler doesn't have that problem,
but if that ifdef works perhaps it's possible to have it like that.
Cheers,
Maarten.
ompatibility checker is
http://ispras.linux-foundation.org/index.php/ABI_compliance_checker
Wine (and winelib) is supposed to be binary compatible with Windows
applications, so it's virtually impossible to make it incompatible
in future versions. There is one tiny possibility, that a winelib
Hello,
I'm from Institute for System
Programming of Russian Academy of Sciences and we are developing a free
lightweight tool for checking backward/forward binary compatibility of
shared C/C++ libraries in OS Linux. It checks interface signatures and
data type definitions in two library versions
I did this (http://www.winehq.org/docs/winelib-guide/winelib-getting-started) :
$ winemaker --lower-uppercase .
$ make
It throws some error in wrc. So according to GSG I did exactly this:
To fix that problem, you will need to edit the list of resource files
winemaker thought
"Josef Simánek" wrote:
I edit Makefile and type make into console.
What exactly did you do? notepad is not supposed to work as a console
application for your information.
My problem above. In the
guide is written to report bad compiling behaviour. So I did it. Any
hints ?
mirindos...@mirin
Hi !
I was reading Winelib GSG and I tried to compile notepad from Wine
sources. So I downloaded Wine sources (version 1.1.21) and I installed
wine from Wine Ubuntu repository (version 1.1.21).
I edit Makefile and type make into console. My problem above. In the
guide is written to report bad
Austin English schrieb:
2009/5/1 André Hentschel :
To my suprise it didnt run.
Interesting...does it run as a 32-bit winelib app? Have you tried
compiling it with 64-bit mingw and seeing if it works there?
i have problems compiling it with mingw64, because i am not familiar
with
Austin English schrieb:
2009/5/1 André Hentschel :
To my suprise it didnt run.
Interesting...does it run as a 32-bit winelib app? Have you tried
compiling it with 64-bit mingw and seeing if it works there?
Putty runs as 32-bit winelib app. The test with mingw64 i will try next
2009/5/1 André Hentschel :
> To my suprise it didnt run.
Interesting...does it run as a 32-bit winelib app? Have you tried
compiling it with 64-bit mingw and seeing if it works there?
--
-Austin
Hi,
these days i got my gcc 4.4 working and first compiled wine64. Next
thing i did was to modify winemaker to generate Makefiles for 64-Bit
compilation.
I first tried something simple and it worked great, so i took my
modified Putty-sourcecode and gave it a try. And wow it worked great!
Just
project file into a winelib-aware, scons-powered, linux-compatible build
> system. This would make it very easy for a Windows-only Visual Studio
> project to be ported.
>
> Now, normally, someone writing portable code would probably want to use
> scons from the start instead of Visual
On Mar 22, 2009, at 11:18 AM, Francois Gouget wrote:
The Winelib tools (winebuild, winegcc, wrc, widl, etc) are actually
used everyday [sic] and are under active development as they are
used to build Wine itself.
Ah, I didn't know that. I thought winelib was more like a replacement
On Mar 22, 2009, at 4:47 AM, King InuYasha wrote:
Does SCons support the project-within-a-project build style that is
used in Visual Studio? ...
SCons is amazingly policy-neutral, and we work to keep it that way.
(It has occasionally been a bone of contention, when people have
wanted us
On Sat, 21 Mar 2009, Greg Noel wrote:
[...]
> On the other hand, I'd wonder about viability. It doesn't look like the basic
> winelib information has been updated since January 2005, although there's
> mention of a planned 0.9 release in September 2005. That'
On Sat, Mar 21, 2009 at 10:42 AM, Greg Noel wrote:
> On Mar 20, 2009, at 4:50 PM, Scott Ritchie wrote:
>
> ... I want a magic script that can convert a visual studio project file
>> into a winelib-aware, scons-powered, linux-compatible build system. ...
>> I'm
On Mar 20, 2009, at 4:50 PM, Scott Ritchie wrote:
... I want a magic script that can convert a visual studio project
file into a winelib-aware, scons-powered, linux-compatible build
system. ... I'm not sure whether this will function better as an
scons summer of code project or a
mailto:sc...@open-vote.org>> wrote:
>>> For a while now I've been hoping someone would tackle a pet
project of
>>> mine. It occurred to me that it would be a great summer of
code project.
>>>
>>> Basically, I want a magic
It occurred to me that it would be a great summer of code
> project.
> >>>
> >>> Basically, I want a magic script that can convert a visual studio
> >>> project file into a winelib-aware, scons-powered, linux-compatible
> build
> >>> system. T
gt;>
>> On Sat, Mar 21, 2009 at 12:50 AM, Scott Ritchie wrote:
>>> For a while now I've been hoping someone would tackle a pet project of
>>> mine. It occurred to me that it would be a great summer of code project.
>>>
>>> Basically, I want a magic sc
now I've been hoping someone would tackle a pet project of
>> mine. It occurred to me that it would be a great summer of code project.
>>
>> Basically, I want a magic script that can convert a visual studio
>> project file into a winelib-aware, scons-powered, linux
It occurred to me that it would be a great summer of code project.
>
> Basically, I want a magic script that can convert a visual studio
> project file into a winelib-aware, scons-powered, linux-compatible build
> system. This would make it very easy for a Windows-only Visual S
For a while now I've been hoping someone would tackle a pet project of
mine. It occurred to me that it would be a great summer of code project.
Basically, I want a magic script that can convert a visual studio
project file into a winelib-aware, scons-powered, linux-compatible build
s
I can
> gather. Since you guys do have winelib for the purpose of building Win32
> source code, I thought that I could suggest that the people that do maintain
> Winelib could take over this project and import it into Wine's git
> repository.
> The project is called the Open Foundati
Hello, I was doing my random web browsing when I stumbled on an issue with
source code with MSVC++ 2005 Express, and I was searching for a solution. I
think I found one, but it hasn't been maintained for years from what I can
gather. Since you guys do have winelib for the purpose of building
w pass info back and forth between wine and linux via shared memory,
>>
>
> Sweet! I had forgotten about /dev/shm.
>
>
If your going the win32 executable way. then do something much easier here.
Create a winelib (plugin) DLL that exports a stable API to your win32
applic
>
> If your going the win32 executable way. then do something much easier here.
> Create a winelib (plugin) DLL that exports a stable API to your win32
> application.
>
If I were to do that, I wouldn't need a win32 executable. My goal here
has been to find a way to distri
On Sat, Oct 25, 2008 at 8:10 AM, Alan Nisota <[EMAIL PROTECTED]> wrote:
> Very cool. Here is what I did:
> In linux (host):
> use shm_open and ftruncate to create a shared-memory region (this will be at
> /dev/shm/ in linux)
> use mmap to map that into memory
> create a socket to use as a semaphor
Dan Kegel wrote:
For starters, have you tried CreateFileMapping in wine, and
mmap on the same file in the native bit?
Sadly, linux does not use tmpfs by default, so the backing
store writes would probably hurt performance.
But it would be interesting to hear whether this worked at all.
Very
On Fri, Oct 24, 2008 at 9:13 AM, Alan Nisota <[EMAIL PROTECTED]> wrote:
> So I'd be happy to have a win32 app that can talk to linux via shared memory
> (I also need semaphores, but that could likely be handled via socket
> communication) but I don't think this is possible
There ought to be a way.
so that users on
>>> x86-64 can install it easily without needing a 32bit build environment...
>>>
>> I expect to need to depend on the wine package anyway.
>> What I was looking for is a way to supply an executable
>> that will run on any distro that has
ll it easily without needing a 32bit build environment...
>
>I expect to need to depend on the wine package anyway.
>What I was looking for is a way to supply an executable
>that will run on any distro that has wine installed already.
>However, as I said, it must be a winelib app, and I
&
> x86-64 can install it easily without needing a 32bit build environment...
>
> Offhand, I don't think winelib lends itself to use as a static
> library. We're rather heavily wedded to dynamic linking,
> more so than in the past.
> How bad would it be, really, to de
needing a 32bit build environment...
Offhand, I don't think winelib lends itself to use as a static
library. We're rather heavily wedded to dynamic linking,
more so than in the past.
How bad would it be, really, to depend on the wine package?
I'd be happy to help you think through
x27;loader' library, but there are stability problems with this solution
(the 'loader' library many hacks to provide just enough infrastructure
to the codec, and debugging issues is difficult due to the binary nature
of the filter)
I found that building against winelib works quite w
ine dev list archives also -fshort-
wchar GCC flag solution, but it seems this makes C library's UNICODE
function not work at all as expected. Nice to learn something new.
> Wrong, it compiles and works (for winelib) on SUN.
Good to know.
Cheers,
--
Adam Strzelecki |: nanoant.com :|
unimplemented or differs from unsigned
WCHAR is not the same as wchar_t.
> short? Anyway AFAIK Wine is only Intel (LittleEndian) 32-bit.
Wrong, it compiles and works (for winelib) on SUN.
Vitaliy
> Wine already had at some point strlen along with some other string
> functions
> implemented in asm, however they have been removed after it was
> proved that
> gcc optimized C code outperforms it.
Let me ask this way, why Wine don't use standard C library functions
for lstringsomething ke
"Adam Strzelecki" <[EMAIL PROTECTED]> wrote:
> I believe the further discussion is pointless. If you ever dared to
> look how MSVCRT or GLIBC strlen function is implemented you would know
> that it is exactly same algorithm (that just differs in the
> implementation) using 4 byte fetching wi
I believe the further discussion is pointless. If you ever dared to
look how MSVCRT or GLIBC strlen function is implemented you would know
that it is exactly same algorithm (that just differs in the
implementation) using 4 byte fetching with magic bits matching, also
described in few books
1 - 100 of 499 matches
Mail list logo
