On November 27, 2003 01:38 am, Shachar Shemesh wrote:
While I will be happy to hear Dimi's rational for his, I don't
think there is much room for an actual discussion, as these things
tend to turn into religious flame wars.
OK, I'll take the bait. Of course, there is no big difference between
Hi,
On Thu, Nov 27, 2003 at 09:01:00AM +0200, Shachar Shemesh wrote:
Something that does affect efficiency, which I debated with myself for
some time, is the order of the tests. As the if is, by far, much more
likely to be false than true, we should order the condition using a cost
Dimitrie O. Paun [EMAIL PROTECTED] writes:
On November 27, 2003 01:38 am, Shachar Shemesh wrote:
While I will be happy to hear Dimi's rational for his, I
don't think there is much room for an actual discussion,
as these things tend to turn into religious flame wars.
There are some things
Hello Alexandre,
currently debug channels are initialized too late. Due to that
debugging with +nls turned on doesn't show traces produced by
dlls/kernel/locale.c,LOCALE_Init().
--
Dmitry.
On Wed, 2003-11-26 at 21:31, dim owner wrote:
So, a (the) big question is, how can we get this windows app to compunicate
with UNIX processes?
It's tricky. The easiest way is simply to convert the Gimp into a
Windows program by compiling it with WineLib. No, I don't know how to do
that, Dimi
On Thu, 2003-11-27 at 14:02, Shachar Shemesh wrote:
- What is the current status of --with-nptl on RH9? Is it positively
necessary to include that when running ./configure? I know it's not
necessary when running wineinstall.
--with-nptl is no longer required and has been removed, at least,
On November 27, 2003 09:02 am, Shachar Shemesh wrote:
I also have specific questions, if anyone knows the answers:
- What is the current status of --with-nptl on RH9? Is it positively
necessary to include that when running ./configure? I know it's not
necessary when running wineinstall.
No
On November 27, 2003 06:21 am, Sylvain Petreolle wrote:
Is this second attempt better ?
(not tested with alsa 0.9)
Why don't you define the snd_pcm_hw_params_* macros for
alsa 0.9. For example, this bit:
-snd_pcm_format_t format = snd_pcm_hw_params_get_format(hw_params);
-
--- Dimitrie O. Paun [EMAIL PROTECTED] a écrit : On November 27,
2003 06:21 am, Sylvain Petreolle wrote:
Is this second attempt better ?
(not tested with alsa 0.9)
Why don't you define the snd_pcm_hw_params_* macros for
alsa 0.9. For example, this bit:
snip
Eliminates a lot of
This question comes up a lot.
A similar project to below would be the use of windows ODBC drivers
under unixODBC.
(where/how does one add a Fun project suggestion)
There are few example projects that do Just that. One is right here at
home and for some reason these people do not want to come
On Thu, 2003-11-27 at 17:26, Boaz Harrosh wrote:
A. How is the Netscape-plugin-to-OCX works in CrossOver-plugin. Is that
an out of process plugin embedded inside the browser X-window? What is
the out-of-process (RPC) communication between the Netscape-plugin and
the wine-OCX-host? What is
Happy Thanksgiving!
On Thursday 27 November 2003 00:10, you wrote:
On November 26, 2003 04:31 pm, dim owner wrote:
So, a (the) big question is, how can we get this windows app to
compunicate with UNIX processes?
Well, indeed, this is the $1 question. I don't much care at this
point
On Thursday 27 November 2003 12:26, Boaz Harrosh wrote:
B. MPlayer, and others, are known to host Codec DLLs from windows like
divx-avi and other. Do they use wine. or is it a code rip like the
ndiswrapper (http://sourceforge.net/projects/ndiswrapper/) I think it
looks like a wine derived
The easiest way is simply to convert the Gimp into a
Windows program by compiling it with WineLib
That means that in order to use Photoshop
plugins in the Gimp you'd need a special build of the Gimp
Special build? Wouldn't it be easier to use the native version of gimp for windows?
On Thu, 2003-11-27 at 15:58, Ivan Leo Murray-Smith wrote:
Special build? Wouldn't it be easier to use the native version of gimp for windows?
Nah, you can still access the standard Linux filesystem if you use
WineLib, whereas a native binary run under emulation is unaware of its
existance.
MSVC build log of wine conformance tests:
http://vmlinux.org/jakov/Wine/build_log_MSVC_CVS_2003-11-27.txt
All in all, 14 tests compile and 7 do not.
AFAIK I use an up to date VC++ 7.
(I reinstalled Windows though, so I _might_ have missed something.)
regards,
Jakob
Here's a more readable version of what I just posted to wine-patches.
There are quite a few, aren't there? Full marks to anybody who can
actually describe what they all monitor :)
accel
adpcm
advapi
animate
aspi
atom
avicap
avifile
bidi
bitblt
bitmap
cabinet
capi
caret
cdrom
cfgmgr32
class
The Windows icon cache has always been one of the buggiest pieces of
code. I always assumed they fixed it for NT/2000/XP but it wouldn't
surprise me in the slightest if it still gets corrupted at times.
On Thu, 2003-11-27 at 02:36, Jakob Eriksson wrote:
I am told this is what the Internet
In article [EMAIL PROTECTED], Kevin Koltzau wrote:
I decided to give KDE 3.2-beta1 a try (just for reference I'm using the Gentoo
ebuild), and found a problem with compiling winearts
under KDE 3.1 artsc-config --cflags gives me
-I/usr/kde/3.1/include/artsc
but under KDE 3.2-beta1 I get
Dimitrie O. Paun [EMAIL PROTECTED] writes:
-- cross compilation not tested at this point
Has a problem, indeed:
../../include/wine/port.h:87: dlfcn.h: No such file or directory
Understandable, as gcc has dlfcn.h, but the MinGW gcc does
not. But commenting out the offending #define in
According to the language definition, a constant 0 in
a pointer context is converted into a null pointer at
compile time.
Indeed even if the stored bit pattern for the 'NULL' pointer isn't
all zero [1], then the literal 0 denotates a NULL pointer.
So:
char *p = 0;
Ferenc Wagner [EMAIL PROTECTED] writes:
Has a problem, indeed:
../../include/wine/port.h:87: dlfcn.h: No such file or directory
That's because if you want to cross-compile you need to
cross-configure too. The crosstest stuff is a hack that works
because the tests don't use Wine-specific
Dmitry Timoshkov [EMAIL PROTECTED] writes:
currently debug channels are initialized too late. Due to that
debugging with +nls turned on doesn't show traces produced by
dlls/kernel/locale.c,LOCALE_Init().
That's because we need the locale stuff before parsing the command
line, and the debug
The current code compiles with a few warnings, in the attachment.
BTW you can see how code degenerates rapidly when it's not free software any
more, probably 10% of all the output when compiling winex 3.2 is compiler warnings.
warnings
Description: Binary data
On Thu, 2003-11-27 at 22:59, Huw D M Davies wrote:
We should be doing this already. If cups is installed then we use the
cups default, otherwise for printcap systems we use the PRINTER
env variable or if that isn't set the first entry in /etc/printcap.
Take a look at dlls/winspool/info.c
Mike Hearn [EMAIL PROTECTED] writes:
b) Notify the Wine community of what the patches do/are but keep their
contents secret. Pros: Less chance of duplication, Cons: if people need
the patch, knowing I have one won't be much use and it'd be hard to
notify people without spamming the mailing
26 matches
Mail list logo
