> Do I put the bug in fixed state and submit the patch or leave that
> change to the raised?
I suppose you can submit the patch, and change the bug status to fixed once the
patch is committed.
Ivan.
> On my laptop (a 600mhz Pentium with 128mb of ram, so
> not too pokey) attempting to build the winetest binary actually kills
> the build dead.
I have a 500 mhz laptop with 128 mv of ram, and winetest builds quite
successfully, so maybe it's something wrong with
your build toolchain, or your con
Le 26 août 04, à 00:58, Jim White a écrit :
Of course if you're planning on compiling Wine as PPC then we're on
different pages architecturally.
I still believe it is the *best* way for us to go. But I agree that as
a first step we can go for qemu-darwin-i386-user, that's why I am now
working a
On 25 août 04, at 18:48, Alexandre Julliard wrote:
"Pierre d'Herbemont" <[EMAIL PROTECTED]> writes:
As a conclusion, would accept that we swap (using the regular way) the
headers in order to load exe on a Big Endian host? (since the exe
headers are Little Endian for each NT implementation)
Pierre
P
Alexandre,
As a conclusion, would accept that we swap (using the regular way) the
headers in order to load exe on a Big Endian host? (since the exe
headers are Little Endian for each NT implementation)
Pierre
PS : the exe header is Little Endian even on a PowerPC NT exe, since
the PowerPC NT im
Le 25 août 04, à 23:01, Jim White a écrit :
I would really like to get away from having to write all the little
wrappers to deal with the namespace problem. I believe we can solve
that with a suitable naming convention as we began to do with the
winegcc patch.
I think we can forget this solutio
On 24 août 04, at 22:50, Alexandre Julliard wrote:
"Pierre d'Herbemont" <[EMAIL PROTECTED]> writes:
Hi Alexandre,
This patch allows to load a PE exe to memory. You may notice that
there is no "mass" byte swapping. The technics used here is a bit
developer here:
http://stegefin.free.fr/wine/
You mig
From the limited experience I have the problem is that if a portion of
code expect to have a certain type of endianness, it would make some
special assumption, we won't be able to track out (See [1]). And it
will be even harder to track the issues for the x86 already compiled
code, in Wine we c
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 in-
stead don't
Oh ok thanks Rob I'll try it out.
On Thu, 26 Aug 2004 01:49:41 +0100, Robert Shearman <[EMAIL PROTECTED]> wrote:
> James Hawkins wrote:
>
> >I ran WINEDEBUG=trace+all wine setup.exe 2>&1 | sed '1,/Debug mark/d'
> >in the terminal, and all of the debug output is being displayed
> >already without
James Hawkins wrote:
I ran WINEDEBUG=trace+all wine setup.exe 2>&1 | sed '1,/Debug mark/d'
in the terminal, and all of the debug output is being displayed
already without selecting the "Put..log" option. I switched
"Managed" to "N" at Vincent's suggestion. Any ideas?
Try this instead:
WINEDEB
I ran WINEDEBUG=trace+all wine setup.exe 2>&1 | sed '1,/Debug mark/d'
in the terminal, and all of the debug output is being displayed
already without selecting the "Put..log" option. I switched
"Managed" to "N" at Vincent's suggestion. Any ideas?
On Wed, 25 Aug 2004 19:34:34 -0400, James Hawkin
Vincent Béron wrote:
> I didn't see it when used in "Managed"="Y" mode, but with "Managed"="N"
> the option's there (Alt-space, or the icon in the top-left corner of the
> window of the app).
When an app is running in Managed Mode we can access the system menu opening
the first menu (usually File)
Hi all,
I finally managed to create a patch that fixes the bug in CreateDIBitmap
and also changes all the WINE code that was relying on the wrong
behavior. I'll send the patch to wine-patches in a couple of minutes. So
if you intended to help, it's too late ;-)
Test Program (DIB-Testcase.zip):
I'm having the same problem
On Wednesday 25 August 2004 08:12 am, Paul Millar wrote:
> imagelist.o(.text+0x11ba):/home/paulm/Testing/wine-cross-source/dlls/comctl32/tests/imagelist.c:279:
>
> more undefined references to [EMAIL PROTECTED]' follow
> distcc[21076] ERROR: compile on localhost faile
Oh ok thanks a bunch I will definitely try it out now.
On 25 Aug 2004 19:25:19 -0400, Vincent Béron
<[EMAIL PROTECTED]> wrote:
> Le mer 25/08/2004 à 19:11, James Hawkins a écrit :
> > > > Then you just need to bring the system menu up and click on "Put 'Debug
> > > > mark' in debug log" and debugg
Le mer 25/08/2004 à 19:11, James Hawkins a écrit :
> > > Then you just need to bring the system menu up and click on "Put 'Debug
> > > mark' in debug log" and debugging will then start.
>
> I'm not exactly sure what you mean by system menu. I cant remember
> seeing the "Put...log" anywhere. Than
> > Then you just need to bring the system menu up and click on "Put 'Debug
> > mark' in debug log" and debugging will then start.
I'm not exactly sure what you mean by system menu. I cant remember
seeing the "Put...log" anywhere. Thankyou for your help on this
response btw.
On 25 Aug 2004 18:4
Pierre d'Herbemont wrote:
Le 25 août 04, à 23:01, Jim White a écrit :
I would really like to get away from having to write all the little
wrappers to deal with the namespace problem. I believe we can solve
that with a suitable naming convention as we began to do with the
winegcc patch.
I think
Le mer 25/08/2004 à 17:29, Robert Shearman a écrit :
> James Hawkins wrote:
>
> >Hi,
> >
> >Is there a way to change the trace options of WINEDEBUG during
> >runtime?
> >
> WINEDEBUG=trace+all wine setup.exe 2>&1 | sed '1,/Debug mark/d'
>
> Then you just need to bring the system menu up and
Jim White <[EMAIL PROTECTED]> writes:
> Mike Hearn wrote:
>
>> Please do some basic research, otherwise you just come off sounding
>> ignorant:
>
> Of course I'm ignorant of the most everything regarding Wine
> history. How is that germane to anything?
>
> Your hostile attitude is why I try to lim
Vincent Beron wrote:
>I attach the smatch script to generate the results I have. It's still
>not perfect (the listview.c references are wrong, for example), but as
>it's tied to gcc it can detect some calls which otherwise would not be
>caught. For example, the calls to GetWindowLongA in header.c
James Hawkins wrote:
Hi,
Is there a way to change the trace options of WINEDEBUG during
runtime?
WINEDEBUG=trace+all wine setup.exe 2>&1 | sed '1,/Debug mark/d'
Then you just need to bring the system menu up and click on "Put 'Debug
mark' in debug log" and debugging will then start. I seem t
Hi,
Is there a way to change the trace options of WINEDEBUG during
runtime? For example, let's say I'm running an installer that
encounters a fatal error during one part of the install. I'm not
exactly sure where in the wine code base this error is occurring and
it would take forever if I se
N.B. The only substantive paragraph here is the last one, so folks
interested in the X86/PPC linking problem should just jump down there.
Mike Hearn wrote:
I agree that flipping the syscalls is a much more promising approach
than the WIN32 API. I'm also thinking that there is bound to be some
Hi,
--- Evan Deaubl <[EMAIL PROTECTED]> wrote:
> Well, this has been a humbling experience. :-S Let's see if these
> patches finally come out right.
> + FIXME("stub!\n");
> + return ERROR_BAD_PROVIDER;
In the FIXME message you should print the values of the params being
passed to the function
Hiya, I've just set up a temporary Linux system to try to get back into
doing some wine development following a break and thought I'd start by
looking at some bugzilla bugs for now. I'm sure there used to be a page
which showed the lifespan of a bug but for the life of me I cant see it.
My underst
Le mer 25/08/2004 à 14:03, Robert Shearman a écrit :
> Vincent Béron wrote:
>
> >I played a bit with smatch and Wine (after reading
> >http://people.redhat.com/mstefani/wine/smatch/), to try to get over what
> >I mentionned in my last email (regarding winapi_check and cross-calls in
> >parenthesis
Jim White wrote:
Mike Hearn wrote:
I think you are going in the wrong direction with this; the right way
IMO is to compile Wine for x86 and run the whole Wine+app under the
CPU emulator. Otherwise you'll have to write wrappers for each of the
15,000 APIs.
Certainly dealing with the syscalls alone
Vincent Béron wrote:
I played a bit with smatch and Wine (after reading
http://people.redhat.com/mstefani/wine/smatch/), to try to get over what
I mentionned in my last email (regarding winapi_check and cross-calls in
parenthesis).
I attach the smatch script to generate the results I have. It's sti
I played a bit with smatch and Wine (after reading
http://people.redhat.com/mstefani/wine/smatch/), to try to get over what
I mentionned in my last email (regarding winapi_check and cross-calls in
parenthesis).
I attach the smatch script to generate the results I have. It's still
not perfect (the
Hey Joris, I would be glad to write a howto for your and possibly
others. I will get started on that soon.
On 25 Aug 2004 11:43:57 -0400, Vincent Béron
<[EMAIL PROTECTED]> wrote:
> Le mer 25/08/2004 à 11:27, Joris Huizer a écrit :
> [snip]
> > Hi James,
> >
> > Yeah I would like that, thanks for
Mike Hearn <[EMAIL PROTECTED]> writes:
> Ditto, was there something wrong with this one?
Not sure I see the point, could you please elaborate on what you are
trying to achieve here?
--
Alexandre Julliard
[EMAIL PROTECTED]
Mike Hearn <[EMAIL PROTECTED]> writes:
> Was this dropped? On my laptop (a 600mhz Pentium with 128mb of ram, so
> not too pokey) attempting to build the winetest binary actually kills
> the build dead. It ends up attempting to feed ~20mb of data to gas
> which doesn't make it very happy. I guess I
"Pierre d'Herbemont" <[EMAIL PROTECTED]> writes:
> As a conclusion, would accept that we swap (using the regular way) the
> headers in order to load exe on a Big Endian host? (since the exe
> headers are Little Endian for each NT implementation)
>
> Pierre
>
> PS : the exe header is Little Endian
Le mer 25/08/2004 à 11:27, Joris Huizer a écrit :
[snip]
> Hi James,
>
> Yeah I would like that, thanks for suggesting :)
> I'll try and do a search on unicode functions and stuff but -- well, you
> have seen more of wine specific details ...
>
> Also, I think it'd be smart to put something like
James Hawkins wrote:
Hey Joris,
I started developing wine in exactly the same way you are
starting: working on the janitorial projects. My current project is
converting the crypt cross calls, and it is almost finished, but im
waiting for my CryptSetProviderExA patch to be committed before I se
Hi Alexandre,
Was this dropped? On my laptop (a 600mhz Pentium with 128mb of ram, so
not too pokey) attempting to build the winetest binary actually kills
the build dead. It ends up attempting to feed ~20mb of data to gas which
doesn't make it very happy. I guess I misphrased it - it's not for
Ditto, was there something wrong with this one?
Mike Hearn
Don't fall back to OSS when Drivers=""
--- dlls/winmm/lolvldrv.c.~1.58.~ 2004-06-01 20:40:48.0 +0100
+++ dlls/winmm/lolvldrv.c 2004-08-03 22:01:16.795976000 +0100
@@ -731,6 +731,9 @@
size = sizeof(buffer);
if (!RegQueryVa
Maybe he's referring to the case where libc.so doesn't have
the epoll bindings, but the underlying kernel does?
Oh yes, I bet that's it. I never really thought about that before but I
guess there's no reason why libc would always support every feature of
the kernel. Thanks Dan!
Mike Hearn wrote:
That's fine, except that compiling your library on a machine that has
epoll, and then trying to run it on a machine without will not work.
It will not load if runtime glibc doesn't have epoll. I'm using
"syscall" to work around that problem in wine.
Why not use dlopen?
Maybe h
I agree that flipping the syscalls is a much more promising approach
than the WIN32 API. I'm also thinking that there is bound to be some
relevant code around aleady (perhaps even in QEMU).
Yes QEMU can do syscall conversion iirc, at least in some modes.
While the current phase of the Darwine ef
Not sure if what I'm thinking would even work, but let's mention it.
Could we add the swapping to qemu? We would end up with a x86
emulation that used big endian instead of little endian.
This way, all memory accesses (from the wine api) would end up
unswapped, while the method calls from the .exe
> "Alex" == Alex Zeiger <[EMAIL PROTECTED]> writes:
Alex> I'm interested in possibly working on USB support for Wine. I'm
Alex> not particularly familiar with USB programming, but I'm fluent in
Alex> C and C++. Where do I start?
Maybe
http://www.lvr.com/usb.htm#HostSoftware
has s
Hey Joris,
I started developing wine in exactly the same way you are
starting: working on the janitorial projects. My current project is
converting the crypt cross calls, and it is almost finished, but im
waiting for my CryptSetProviderExA patch to be committed before I send
the rest of my cr
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi,
Looks like something broke building cross-compiled tests last night. I now
get:
[EMAIL PROTECTED] tests]$ make
i686-mingw32msvc-gcc dpa.o imagelist.o subclass.o tab.o testlist.o -o
comctl32_test.exe -lcomctl32 -luser32 -lgdi32
imagelist.o(.te
Mike Hearn wrote:
I think you are going in the wrong direction with this; the right way
IMO is to compile Wine for x86 and run the whole Wine+app under the
CPU emulator. Otherwise you'll have to write wrappers for each of the
15,000 APIs.
Certainly dealing with the syscalls alone is a lot easier th
Joris Huizer wrote:
Hello,
I'm thinking of trying to do some helpfull work on wine;
Cool!
I have the following problem,
- I don't know where to start (I have never done stuff in wine or
another open source project) ; but I hope you have patience to guide me
into that (but I'm a informatica studen
Hello,
I'm thinking of trying to do some helpfull work on wine;
I have the following problem,
- I don't know where to start (I have never done stuff in wine or
another open source project) ; but I hope you have patience to guide me
into that (but I'm a informatica student, I like learning stuff l
I think you are going in the wrong direction with this; the right way
IMO is to compile Wine for x86 and run the whole Wine+app under the
CPU emulator. Otherwise you'll have to write wrappers for each of the
15,000 APIs.
Certainly dealing with the syscalls alone is a lot easier than flipping
on ev
Shachar Shemesh wrote:
Hi all,
Attached is a non-perfect patch for review. This is a migration of the
wineserver to use epoll instead of poll (if it's available).
current known issue with this patch:
1. Will not compile if HAVE_SYS_EPOLL_H is not 1 (i.e. - won't compile
if epoll not available a
That's fine, except that compiling your library on a machine that has
epoll, and then trying to run it on a machine without will not work. It
will not load if runtime glibc doesn't have epoll. I'm using "syscall"
to work around that problem in wine.
Why not use dlopen?
Dan Kegel wrote:
Shachar Shemesh wrote:
Now don't go and do level-triggered stuff just because it's easier :-)
That's not it at all, and edge vs. level is not part of my
considerations. Libevent does support a wider variety of selection
interfaces, and with wider platform support, than your libra
53 matches
Mail list logo
