On Sun, 4 Apr 2004 10:58:44 +0200
Lionel Ulmer [EMAIL PROTECTED] wrote:
So you should just have to loop over all the rectangles and do the
'copy_on_screen' as many times as there are rectangles.
Of course, if they overlap, this method will still work except that we would
're-Blit' some
Thanks for the responses, and sorry for the late reply (real
life has been limiting my hacking time...)
glXMakeCurrent(default_display, None, NULL)
If you could do a non-wine test case for that and see if it's just a buggy
driver, that'd be good.
It turns out not to be as simple as that. I did a
1. MusicVR exits with this error:
Could you send me a +opengl trace of the problem ? Maybe the game is done
some strange things (like doing a SwapBuffer without a rendering context set
or stuff like that) which are OK on Windows and not on Linux.
I did the +opengl trace, but it comes to about
On Tue, 06 Apr 2004 09:29:05 +0100, James Perry wrote:
I did the +opengl trace, but it comes to about 16MB! Is there
something specific you are looking for that I could grep for?
bzip2 destroys Wine traces. 16mb is nothing compared to the multi-gig logs
we sometimes deal with around here ;)
On Tue, 06 Apr 2004 09:23:45 +0100, James Perry wrote:
It's difficult to trace properly as PECrypt has debugger
detection and behaves oddly if it detects breakpoints or
whatever. But I narrowed it down to 3 Wine calls in the
critical loop: SetEvent, WaitForSingleObject and ResetEvent.
I tried
Could someone please remove the following postings from the
archive as they contain viruses?
http://www.winehq.org/hypermail/wine-patches/2004/04/0082.html
http://www.winehq.org/hypermail/wine-patches/2004/04/0084.html
Rolf Kalbermatter
On Tue, Apr 06, 2004 at 09:23:45AM +0100, James Perry wrote:
Thanks for the responses, and sorry for the late reply (real
life has been limiting my hacking time...)
glXMakeCurrent(default_display, None, NULL)
If you could do a non-wine test case for that and see if it's just a buggy
Hey guys,
http://www.winehq.org/hypermail/wine-patches/
Check that out - 5mb of patches for the last 3 months running. A meg of
patches just 6 days into the new month already!
It seems Wine is moving faster than ever before.
To put things in perspective, the Wine source tree is 10mb - that
Geoff wrote:
Or we write our own BIO that wraps up whatever glue is desirable on the
wine-side. Worst-case (and it's not that bad an alternative) is that you
use a memory-base BIO to encapsulate all I/O and worry about moving data
to and from sockets, whatever they look like, afterwards.
That's
So, me and Mike have been discussing some ideas for window management in
Wine. Currently it hasn't turned into code, but I thought I'd write up
what our thoughts were so others could comment and maybe be inspired to
write patches.
The problem:
Currently Wine decides whether to make a window
On Tue, 6 Apr 2004, Mike Hearn wrote:
Well, one way forward is to implement another mode, in which Wine makes
all windows managed and uses a variety of WM hints to get the desired
behaviour. For instance, the PPosition flag asks the WM to place the
window where the application requests it to.
On Tue, 06 Apr 2004 11:25:13 -0400, Dimitrie O. Paun wrote:
But this, I'm afraid, besides the point. This entire discussion assumes
that the Win32 windows are mapped to X windows. If IIRC, Alexandre was
saying that we need to switch back to the old ways, where we handle most
of the windowing
On Tue, 06 Apr 2004 14:38:26 +0100, you wrote:
To put things in perspective, the Wine source tree is 10mb - that means in
only 2 months as many lines of patch were generated as exists in Wine
itself!
Are you talking about a compressed tar bal perhaps?
$ find wine -type f|xargs cat |wc -lc
On Tue, 2004-04-06 at 16:57, Rein Klazes wrote:
Are you talking about a compressed tar bal perhaps?
Yes, sorry, 10mb is for the compressed tarball. The real tree is far
larger - I thought that sounded a bit suspicious when I wrote it, but
wasn't thinking straight :(
$ find wine -type f|xargs
Mike Hearn wrote:
On Tue, 06 Apr 2004 09:29:05 +0100, James Perry wrote:
I did the +opengl trace, but it comes to about 16MB! Is there
something specific you are looking for that I could grep for?
bzip2 destroys Wine traces. 16mb is nothing compared to the multi-gig logs
we sometimes deal
Florian Goth [EMAIL PROTECTED] wrote:
Added some more stubs after examining the dosbox source code
Could you please try to stick to the formatting style used
in the file in your changes?
--
Dmitry.
Hi list,
Here are the formal instructions for compiling Wine with bidi support.
When doing so, it is recommended that you use a fairly recent version of
ICU (2.6 and up), or else there is going to be a runtime soft dependancy
on some ICU files in the resulting Wine. No big deal - if these
I did the +opengl trace, but it comes to about 16MB! Is there
something specific you are looking for that I could grep for?
As Mike said, Wine traces compress REALLY well with gzip or bzip2. After,
once it gets into a manageable state, you could either upload it somewhere
for me to download it
btw, are there already any automated tools for parsing Wine logs?
There is the examine-relay perl script in the tools directory, but it's only for
relay traces.
Ivan.
Geoff wrote:
Or we write our own BIO that wraps up whatever
glue is desirable on the wine-side. Worst-case
(and it's not that bad an alternative) is that
you use a memory-base BIO to encapsulate all I/O
and worry about moving data to and from sockets,
whatever they look like,
Hi Robert,
Robert wrote:
It depends on which part you are trying to
implement.
For the Certificate Store functions I would
recommend
implementing the OID support functions first,
I was taking a look at implementing the certificate
store functions, and I was thinking (hoping?) I could
avoid
Hi Juan,
--- Juan Lang [EMAIL PROTECTED] wrote:
Yep, in fact the real way to do this as far as Wine
is concerned is to implement SSL in secur32.dll, since
this is where Windows does it. It looks about like
this, although as Geoff pointed out to me the API is a
bit broken. Doing a BIO inside
Mike Hearn [EMAIL PROTECTED] writes:
I should have clarified things a bit: as far as I know the WM rewrite is
about using X windows only for toplevel win32 windows, and not using X
child windows for win32 child windows. The managed/unmanaged thing is only
relevant to toplevel windows. So I
Hi guys!
I'd like to run a TAPI based application in Wine (updated from CVS today).
I extracted the vendor specific TAPI driver and the registry keys
and included both into a Wine setup.
Then I tried to do setup the TAPI driver using the
telephon.cpl (taken from Win98):
wine rundll32.exe
Mike Hearn wrote:
So, me and Mike have been discussing some ideas for window management in
Wine. Currently it hasn't turned into code, but I thought I'd write up
what our thoughts were so others could comment and maybe be inspired to
write patches.
snip
IIRC it's possible to ask the WM
Hi
I already posted this on gmane.comp.emulators.wine.user
but didn't get a response, maybe I have more luck here.
I'm running wine-20040309 on a SuSE 8.2 system and trying
to get Keil µVision2 Evaluation Version (Integrated Development
Environment for Microcontrollers) working. So far, I've
Check that out - 5mb of patches for the last 3 months running. A meg of
patches just 6 days into the new month already!
It seems Wine is moving faster than ever before.
The website stats are interesting too:
Daily Avg | Monthly Totals
Hits
Hi,
If only ole32.dll.CoRegisterPSClsid() is implemented (empty stub
returning '1' is enough) then the application GeoGeogrid® for Windows© starts
and allows at least some basic operations.
(tested with Baden-Würtemberg AMTLICHE TOPOGRAPHISHE KARTEN Top50, Version 4)
For more info on GeoGrid
Le mar 06/04/2004 à 06:07, Rolf Kalbermatter a écrit :
Could someone please remove the following postings from the
archive as they contain viruses?
http://www.winehq.org/hypermail/wine-patches/2004/04/0082.html
http://www.winehq.org/hypermail/wine-patches/2004/04/0084.html
Rolf
On Tue, 06 Apr 2004 11:25:13 -0400, Dimitrie O. Paun wrote:
But this, I'm afraid, besides the point. This entire discussion assumes
that the Win32 windows are mapped to X windows. If IIRC, Alexandre was
saying that we need to switch back to the old ways, where we handle most
of the windowing
30 matches
Mail list logo
