>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 win
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 Kalb
> 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
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 been
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.
>
>
>
> IIRC it's possible to ask the WM
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 shell
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
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 BI
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
avoi
> 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
> 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.
> 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
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 files
"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.
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 sometime
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
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, 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 windowin
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
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 manag
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'
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 me
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 bu
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, 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 t
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 ;)
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 16MB
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 +
29 matches
Mail list logo
