Alexandre Julliard wrote:
Francois Gouget [EMAIL PROTECTED] writes:
Well, no, the cost is linear. It would only be quadratic if the number
of strcat calls depended on the length of the string.
Well - still snprintf is more efficient.
It's more efficient to do:
sprintf(foo,
Hi all,
I've been following the recent work on D3D and decided I would give a couple
of
benchmarks/demos I had around a go. Pleasantly I found that they actually
start up
now and display some stuff on screen! Before the recent patches they would
fail
completely when starting the actual D3D
Hi all,
I just found out that the version I posted on the web was an old one.
Some of the bugs there were purely visual, but there is a serious
problem with the shared memory creation there that causes it not to work
on Windows 98. Since I also have the new version, I have updated the
link
Lionel Ulmer wrote:
' This begs the question:
Does the Linux implementation of pthread really work anyway?
Considering that about 2 months ago, I was able to play HalfLife
Opposing Force all the way through under Wine, I doubt the pthread
emulation is a problem.
By the way, what drivers
On November 29, 2002 02:45 pm, Francois Gouget wrote:
If you modify wine itself then you should be able to remove the wrapper.
However, how will you instruct Wine to load just the right libraries?
We already have a wrapper for the .exe.so, we can pass in some flags.
Something like --preload
On November 29, 2002 01:43 pm, Patrik Stridvall wrote:
On 64 bit platforms we can never get 100% Win32 source compabillity
because of compiler problems. If fact we can't get 100% Win64 support
either for the same reasons so I guess Wine on 64-bit platforms will
be some kind of pseudo mode.
On November 29, 2002 03:06 pm, Francois Gouget wrote:
Now we have a way to pretty easily compile them on Windows. Here's the
procedure:
* get the Wine source
* run ./tools/winapi/msvcmaker --no-wine
(it's a perl script so you might even be able to do it on Windows)
* make those source
On December 1, 2002 11:36 am, Patrik Stridvall wrote:
So that is why we never will support 100% Win64 source
compatibillity
on 64bit platforms. We can (and presumably) will support a
LP64 variant
of Win64 but it won't be 100% source compatible.
I don't think it's nearly as bad as you
Shachar Shemesh [EMAIL PROTECTED] writes:
Well - still snprintf is more efficient.
I don't think so, but feel free to provide benchmarks.
But there is also no reason not to welcome these submissions if
someone already took the time to submit them.
There's no objective reason why sprintf is
Alexandre Julliard wrote:
Shachar Shemesh [EMAIL PROTECTED] writes:
Well - still snprintf is more efficient.
I don't think so, but feel free to provide benchmarks.
Benchmark will follow soon. In the mean time, think about the fact that,
compared to linear copying of the strings in,
I said that due to the wall to wall agreement over the superiority of
sprintf/snprintf. If there is a consensus, we should stick to it.
But the performance of it will suck badly.
Something like:
char *
str_add(char *s, char *lim, const char *a)
{
int c;
do {
On December 1, 2002 12:35 pm, Patrik Stridvall wrote:
That solves the libc problem however compiling with -flong-int also
means that it will be impossible to call other libraries, which
means that it will be a little hard to use Unix specific library
to have extra functionallity under Unix.
On December 1, 2002 12:35 pm, Patrik Stridvall wrote:
That solves the libc problem however compiling with -flong-int also
means that it will be impossible to call other libraries, which
means that it will be a little hard to use Unix specific library
to have extra functionallity under
When I'm wrong, I'm wrong.
sun@sun:~/sources/wine/test$ gcc -O0 strcpy.c -o way1 -DWAY1
sun@sun:~/sources/wine/test$ gcc -O0 strcpy.c -o way2 -DWAY2
sun@sun:~/sources/wine/test$ gcc -O0 strcpy.c -o way3 -DWAY3
sun@sun:~/sources/wine/test$ ./way1
Operation took 0 seconds 450763 usec
Hi all, I've just started working on the DIB engine, FYI.
--
Johan Gill, [EMAIL PROTECTED]
Hi,
Before you re-invent the wheel - David (forgot his family name, sorry David)
from Transgaming (if I'm not mistaken) has started to work on a DIB engine
that uses SDL, so you might want to collaborate with him on his engine..
This reminds me a question: Is there a way that instead of using
Hi Hetz,
Just a few clarifications.
The TransGaming DIBengine doesn't use SDL, and it was written mostly by
Jonathan Meunier with help from Gav, Peter and myself.
Anyhow, I believe Johan Gill is aware that we have the dibengine, and is in
fact probably refering to it (as I have had private
I found an unopened copy of msvc++ 4.0 at a garage sale last year for $5,
couldn't resist. Today I finally tried to install it under Wine.
wine-20020605-2 (rh8):
installer started; when I clicked on 'Install Visual C++',
it put up a 'Installing... please wait' dialog, then failed with a
'Can't
I am continually amazed at how well Wine emulates Windows - for example,
my recent experiences show Wine has the whole Just re-install it, it
will fix it thing down pat! 8^
To recap the story thus far - Several months ago, I was able to play
Halflife- Opposing force all the way through under
Shachar Shemesh wrote:
Benchmark will follow soon. In the mean time, think about the fact
that, compared to linear copying of the strings in, these are the
overheads (neglecting function call overhead, which is not neglectible
but is fair):
n - number of strings in the final string
m(i) -
Dan Kegel wrote:
I found an unopened copy of msvc++ 4.0 at a garage sale last year for $5,
couldn't resist. Today I finally tried to install it under Wine.
OK, more details. I switched to testing the simplest
function of msvc's setup program: the exit button.
All I do is click on the exit
21 matches
Mail list logo
