is it possible somehow to run Wine from the build tree? I
mean without 'make install'? It's too lengthy to install
after every one line change during printf-debugging...
Huh ? Doing 'make install' from the DLL directory where you did the change
is too slow ?
Lionel
--
Dimitrie == Dimitrie O Paun [EMAIL PROTECTED] writes:
Dimitrie On January 30, 2003 08:34 am, Ferenc Wagner wrote:
Hello,
is it possible somehow to run Wine from the build tree? I mean
without 'make install'? It's too lengthy to install after every one
line change
Hi Eric,
It is very strange indeed, but I just tested it again and I'm convinced
that on my system that call can take a few seconds. I'm also pretty sure
there is no concurrent access to the drive and automount is not running.
I even did this on a failsafe session just to be sure, but still
Ferenc == Ferenc Wagner [EMAIL PROTECTED] writes:
FerencHello, is it possible somehow to run Wine from
Ferenc the build tree? I mean without 'make install'? It's too
Ferenc lengthy to install after every one line change during
Ferenc printf-debugging...
I call
Lionel Ulmer [EMAIL PROTECTED] writes:
Huh ? Doing 'make install' from the DLL directory where
you did the change is too slow ?
Not the 'make install' alone, but the administration to keep
my distribution's package management happy.
Thanks for the answers, everyone, I'm going for it.
Ferenc Wagner a écrit:
Lionel Ulmer [EMAIL PROTECTED] writes:
Huh ? Doing 'make install' from the DLL directory where
you did the change is too slow ?
Not the 'make install' alone, but the administration to keep
my distribution's package management happy.
If it's just that, the easiest is
If MSN is calling explorer, maybe we should apply the patch
regardless
of the bug reports. It'd be nice if MSN was closer to working on
fake windows.
BTW, my patch only implements one commandline parameter, a directory
name.
Anyone know if MSN or any other common program uses any of the
Vincent Béron [EMAIL PROTECTED] writes:
Of course, wine let's you use it inside it's build dir, so
it may be easier to just do that.
Yes, it seems to work now. One catchup: I had to define a
new drive for /usr/local/src/wine/programs to be able to use
the debugger. What a deal...
[EMAIL PROTECTED] wrote:
On my Suse 7.3 Linux (Kernel 2.4.4) I tried to start the
w2k Explorer (Version 5.0 (Build 2195: Service Pack 3)
using wine-20030115 with just buildin dlls.
It is quite possible that there is a problem in the Exception handling in
Wine, however before Explorer is going to
liu spider [EMAIL PROTECTED] writes:
And I think maybe exchange the calling order of
XCloseIM and XCloseDisplay is a better method than
just comments out XCloseIM ( I think this will lead to
some other problems).
Exchanging them makes it crash on my machine, so I think we have to
avoid the
Rolf Kalbermatter wrote:
before Explorer is going to run under Wine, there needs to be
a whole lot more done than that. The entire shell support in Wine is not
at the point where Explorer will be able to do anything useful...
Yep. We need to implement a lot of shell hooks...
people want to be
On Thursday 30 January 2003 14:54, Uwe Bonnes wrote:
Dimitrie == Dimitrie O Paun [EMAIL PROTECTED] writes:
Dimitrie On January 30, 2003 08:34 am, Ferenc Wagner wrote:
Hello,
is it possible somehow to run Wine from the build tree? I mean
without 'make install'?
Hi folks,
There is a new page in my little Wine WWW -- the UI status page:
http://www.dssd.ca/wine/Wine-UI.html
This is a page that I've been meaning to create for many months now.
Please check it out, and let me know if you notice any inaccuracies.
--
Dimi.
Waldeck Schutzer wrote:
Hi Eric,
It is very strange indeed, but I just tested it again and I'm convinced
that on my system that call can take a few seconds. I'm also pretty sure
there is no concurrent access to the drive and automount is not running.
I even did this on a failsafe session just
This is a page that I've been meaning to create for many months now.
Please check it out, and let me know if you notice any inaccuracies.
I'd add the MDI control to the list too, and maybe the def procs
(window, dlg...)
A+
--
Eric Pouech
(I think MDI falls more intuitively into the Window Management
section than in the control section)
agreed (that's why I put control in quoted)
Common Dialog
-- File Open/Save
-- Font Selection
-- etc.
maybe, if you want full UI coverage, you could add a windowing driver
section
IMO, this type of information should be integrated in current status page.
Sure, it's just so much easier to work with it on my site.
I am a bit concerned that merging this page with the big
status page will result in a huge page that is not that
useful. I think that UI elements deserve a
On Thu, Jan 30, 2003 at 05:44:35PM +0100, Ove Kaaven wrote:
does not conform
to the DCE RPC wire protocol (mostly because I don't have a description of
it...
You could take a look at the Ethereal sniffer software (www.ethereal.com).
It has dissectors for some of Microsofts rpc stuff.
Ciao
On Thu, 30 Jan 2003, Eric Pouech wrote:
I'd add the MDI control to the list too, and maybe the def procs
(window, dlg...)
I will add two more sections:
Fundamentals:
-- Visible Region Handling
-- Window Management
-- MDI
(I think MDI falls more intuitively into the Window Management
On Thu, 30 Jan 2003, Eric Pouech wrote:
maybe, if you want full UI coverage, you could add a windowing driver
section (X11, TTY, SDL...)
That's a good idea, it will be another section.
IMO, this type of information should be integrated in current status page.
Sure, it's just so much easier
Well, I'm off to try that.
I tried a mv /usr/X11R6/whereverthefontswere/ to a back up dir, then reset xf86 and
wine worked fine... I'd like to believe that it was the fonts' fault, but everywhere
else they work fine.
I dunno my japanese fonts go funky on me sometimes... methinks kappa is a
how can I force wine to do font metrics?
--
De-fault! The two sweetest words in the English language.
-- Homer Simpson
Get Gaim for unix or win32 systems! gaim.sourceforge.net
Scott Action Jackson - [EMAIL PROTECTED]
msg16993/pgp0.pgp
Description: PGP signature
halflife majorly crashes on me:
err:local:LOCAL_GetBlock not enough space in GDI heap 01ff for 112 bytes
for thousands of lines, until it eventually pukes and wants to debug. then it tells me:
Couldn't start process '148738992 0x84 ' (twice)
Why? I don't know. I remember installing it under wine,
Here is something interesting. When I turn the drive back into a plain
ide (by removing the ide-scsi option from the kernel options), it speeds
up considerably. Now it rocks! This makes me wonder what the heck is
going on with the kernel.
Waldeck
Eric Pouech wrote:
Waldeck Schutzer wrote:
On Thursday 30 January 2003 10:44 am, Ove Kaaven wrote:
This one is sure to give Greg something to work with...
looks very interesting, indeed.
all of this was
implemented in a bit of a hurry, but since it's based on my research, it
should be a good starting point in understanding how
On January 30, 2003 03:59 pm, Eric Pouech wrote:
this matrix about status(es): on one side the various DLLs we're working
on, on the other side some metrics/characteristics we want to
highlight... and working only by rows or columns is not very efficient
I also agree that working on the ful
On January 30, 2003 09:38 pm, Dimitrie O. Paun wrote:
ChangeLog
Merge README.wrc into wrc's man page.
Sorry I forgot to mention, also do:
cvs rm -f tools/wrc/README.wrc
before you commit.
--
Dimi.
27 matches
Mail list logo
