Re: strcat+strcat+strcat == baaad
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, %s%s%s%s%s%s, bar1,bar2,bar3,bar4,bar5,bar6); I seriously doubt that sprintf would be faster that a couple of strcats. And I don't think we need to worry about this kind of micro-optimizations right now... But there is also no reason not to welcome these submissions if someone already took the time to submit them. Shachar
Programs to test D3D
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 stuff. I'm not sure if you're aware of these programs or not but I figured I would pass on the URLs to you as they might be of help. This first is a demo called Bleam: http://www.bluespoon.com/banjoh/ This page has a binary of the demo and source code as well. The second is an older benchmark/demo called Tirtanium: http://www.tirtanium.de/prog3d.html The homepage doesnt seem to have the binary anymore so here's a direct link to a mirror: http://public.planetmirror.com/pub/3dfiles/tweakfiles/benchmark/tirta190.zip Both display stuff on screen and will run through to the end with no crashes. Justin Chevrier PS. Great work guys! _ Help STOP SPAM with the new MSN 8 and get 2 months FREE* http://join.msn.com/?page=features/junkmail
Re: SetWindowHookEx
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 with the new version. My appologies. http://www.consumer.org.il/personal/xeyes.zip As before, treat this as a GPL program. Shachar Shachar Shemesh wrote: I sent Alexandre the App privately. I originally wanted to CC the list (the app can be distributed under either GPL or LGPL), but the mail was rejected. I would hereby like to appologize for trying to attach more than the set limit of 40Kb of a zip file to the list. My appologies. In leu of such atrocities which I would not like to commit, and I would like to thank the moderator for stopping that mail, I have placed on a web site, and am hereby making both source and a compiled binary available in a zip file (no wonder it was more than 40Kb, what was I thinking trying to send it to the list) at http://www.consumer.org.il/personal/xeyes.zip. D/L size is 49Kb. Thanks, Shachar Alexandre Julliard wrote: Shachar Shemesh [EMAIL PROTECTED] writes: So you mean to say that my windows X-Eyes implementation won't work on WINE? Damn. Anyone knows of any Unix port of that program? Shachar No, wait. I'm using a mouse hook. Maybe it'll work after all. At this point probably not, but if you could send me that app I'd be interested to play with it.
Re: Texture problems under Wine - more info
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 are you using ? XFree86 DRI for Radeon 7500 (r100 driver) from CVS. I haven't had time to begin regressing the OpenGL shim under Wine, as this weekend has been rather busy doing other things, but as I get time I will begin doing so.
Re: Fwd: Re: [putty]Winelib support + patch
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 ntdll,kernel,user,gdi,... Of course, the ideal fix is if wine canfigure things out automatically from the .exe.so file. Since we are going to have that link script sooner or later, what about we store this information in a ELF section, and get it from there before dlopening the file? BTW, how hard would be to get to such a section? But you cannot create trampolines for variables. No, but I guess you can trigger a segfault, and do the fixup in the signal handler. But regardless, how does Windows deal with this? How come it works there, and not under Wine? -- Dimi.
Re: [RFC] Wine headers
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. Why are you saying that? What about the current difference between the sizeof(wchar_t), it wasn't such a big deal. Can't we have other flags in the great tradition of -fwchar-short? -- Dimi.
Re: Janitorial Projects
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 accessible by a Windows machine (e.g. export them via Samba) * load winetest.dsw in Visual C++ * hit that build button This is too complicated. First, it requires Visual C++, which sucks. We should be able to compile the tests with MinGW, as any OSS project out there. So I would say the TODO for building the tests is as follows: * make sure we can compile them with MinGW * arrange such that we can generate _one_ executable for all tests * create script that builds them say, every few (3-5) days, tests if the executable changed (by comparing MD5 sums) from the last build, and if so, put it up for download on a site, and email the test volunteers a notification (containing the URL) that the tests have changed, and they should retest. The URL should be fixed (e.g. http://www.corp.com/wine/wine-tests.exe), so the tester can bookmark it, write scripts against it, etc. * enlist a volunteer to run said script on a regular basis. As it stands, the tests have to do way too much work for this to have a snowball's chance in hell of working long term. Don't forget that the testers need to worry of a different box, etc. which is already enough work. The rest can be automated, as I just described. -- Dimi.
RE: [RFC] Wine headers
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 make it. In the Wine sources, we'll just use explicit types that don't depend of compiler switches, while Winelib apps will just use the -flong-int flag, and get what they expect. Of course, they'll have to use our msvcrt lib instead of the native libc, but that's largely true today anyway (for different reasons). 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. But sure having a -flong-int flags is nice but it doesn't solve all problems. Perhaps would be good to push for its addition even now, it might take a few years before standard GNU C installation supports it.
Re: strcat+strcat+strcat == baaad
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 better than strcat in that case, it's purely a matter of personal taste. As such, whoever writes the code in the first place gets to choose the way it's done. What if I apply that patch and someone sends a patch tomorrow changing the sprintfs back into strcats because he prefers that? Should I apply it? After all he took the time to submit it too... -- Alexandre Julliard [EMAIL PROTECTED]
Re: strcat+strcat+strcat == baaad
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, 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) - length of string i (0i=n) sm(i) - sigma of all lengths up to i (0i=n) sm(n) - total length of all strings with sprintf - parsing the format string*n+sm(n) with strcpy+strcat - for each strcat we have to find the end of the string (sm(i-1)), and then write our own string (m(i)). 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 better than strcat in that case, it's purely a matter of personal taste. Not if you accept my performance claim. Also, there is the security thingamy. The str* method is a bitch to make secure. You have to keep subtracting the already processed strings from the remaining buffer length, and then you run into the risk of subtracting more than you have, resulting in a negative number=buffer overflow despite your best efforts. There is the question of the null - yes/no. There is a horrible performance hit for strncpy for filling the entire buffer, while not promising null termination. In short, it is one major headache. snprintf, on the other hand, is simple, to the point, and clean. You still have to make sure the buffer is terminated, but that's all. As such, whoever writes the code in the first place gets to choose the way it's done. Agreed, assuming ALLof my previous arguments are rejected. What if I apply that patch and someone sends a patch tomorrow changing the sprintfs back into strcats because he prefers that? Should I apply it? After all he took the time to submit it too... 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. Shachar
Re: strcat+strcat+strcat == baaad
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 {
if (s = lim) {
s = lim - 1;
c = 0;
} else
c = *a++;
*s++ = c;
} while (c);
return s;
}
So you can do:
lim = buf + len;
buf = str_add(buf, lim, abc);
buf = str_add(buf, lim, 123);
...
might be safer.
David
--
David Laight: [EMAIL PROTECTED]
Re: [RFC] Wine headers
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. But those apps will be aware of the issue, and can use explicit types, just like we're going to do in Wine. Sure, they will not be able to use the header files directly (actually, they might by having some compat files that are not compiled with said flag on), but I don't think it's a big deal anyway. It's workable, and Win64 will not bother us for some time... -- Dimi.
RE: [RFC] Wine headers
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. But those apps will be aware of the issue, and can use explicit types, just like we're going to do in Wine. Sure, they will not be able to use the header files directly (actually, they might by having some compat files that are not compiled with said flag on), but I don't think it's a big deal anyway. It's workable, A better solution would be to port the source code to the LP64 model. It is entirely possible for to support all of LP32 (Win32 and Unix32), LLP64 (Win64) and LP64 (Unix64) in a sane way. I don't think it is worth the effort to support LLP64 beyond having a -flong-int flag to get a working version to show as a prototype that porting is indeed possible. and Win64 will not bother us for some time... True. Microsoft doesn't seems that eager pushing Win64 either...
Re: strcat+strcat+strcat == baaad
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
sun@sun:~/sources/wine/test$ ./way2
Operation took 0 seconds 598408 usec
sun@sun:~/sources/wine/test$ ./way3
Operation took 0 seconds 427037 usec
With higher O values, the difference becomes bigger, but I'm not sure
then that some of the operations are not optimized out of the process,
which makes the entire benchmark useless.
So, what are our conclusions? Do we just implement strlcpy and strlcat
so that everyone has a function that is both efficient AND secure?
Do we go for David's suggestion, that is more efficient, but is also
more cubersome and requires two extra vars to implement right?
Shachar
David Laight wrote:
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 {
if (s = lim) {
s = lim - 1;
c = 0;
} else
c = *a++;
*s++ = c;
} while (c);
return s;
}
So you can do:
lim = buf + len;
buf = str_add(buf, lim, abc);
buf = str_add(buf, lim, 123);
...
might be safer.
David
#include stdio.h
#include string.h
#include sys/time.h
#include time.h
const int NUM_ITER=10;
const char * const STRING=01234567890123456789012345678901234567890123456789;
char *
str_add(char *s, char *lim, const char *a)
{
int c;
do {
if (s = lim) {
s = lim - 1;
c = 0;
} else
c = *a++;
*s++ = c;
} while (c);
return s;
}
int main()
{
struct timeval before, after;
char buffer[1000];
int i;
gettimeofday(before, NULL);
for( i=0; iNUM_ITER; ++i )
{
#ifdef WAY1
strcpy( buffer, STRING );
strcat( buffer, STRING );
strcat( buffer, STRING );
strcat( buffer, STRING );
strcat( buffer, STRING );
strcat( buffer, STRING );
strcat( buffer, STRING );
strcat( buffer, STRING );
strcat( buffer, STRING );
strcat( buffer, STRING );
#elif WAY2
sprintf( buffer, %s%s%s%s%s%s%s%s%s%s, STRING, STRING, STRING, STRING,
STRING, STRING, STRING, STRING, STRING, STRING );
#elif WAY3
char *pointer=buffer;
char *const limit=buffer+sizeof(buffer);
buffer[0]='\0';
pointer=str_add( buffer, limit, STRING );
pointer=str_add( buffer, limit, STRING );
pointer=str_add( buffer, limit, STRING );
pointer=str_add( buffer, limit, STRING );
pointer=str_add( buffer, limit, STRING );
pointer=str_add( buffer, limit, STRING );
pointer=str_add( buffer, limit, STRING );
pointer=str_add( buffer, limit, STRING );
pointer=str_add( buffer, limit, STRING );
pointer=str_add( buffer, limit, STRING );
#endif
}
gettimeofday(after, NULL);
{
long diff_sec, diff_usec;
diff_sec=after.tv_sec-before.tv_sec;
diff_usec=after.tv_usec-before.tv_usec;
if( diff_usec0 )
{
diff_usec+=100;
diff_sec--;
}
printf(Operation took %ld seconds %ld usec\n, diff_sec, diff_usec );
}
return 0;
}
DIB engine
Hi all, I've just started working on the DIB engine, FYI. -- Johan Gill, [EMAIL PROTECTED]
Re: DIB engine
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 the DIB engine, to create an RDP events and show them in an application like rdesktop? Thanks, Hetz On Sunday 01 December 2002 22:52, Johan Gill wrote: Hi all, I've just started working on the DIB engine, FYI. -- Johan Gill, [EMAIL PROTECTED]
Re: DIB engine
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 correspondence with him) For those who don't follow this list all the time, more information can be found in these two threads: http://www.winehq.com/hypermail/wine-devel/2002/09/0680.html and http://www.winehq.com/hypermail/wine-devel/2002/11/0849.html Cheers David On Mon, 2 Dec 2002 08:17, Hetz Ben Hamo wrote: 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 the DIB engine, to create an RDP events and show them in an application like rdesktop? Thanks, Hetz On Sunday 01 December 2002 22:52, Johan Gill wrote: Hi all, I've just started working on the DIB engine, FYI. -- Johan Gill, [EMAIL PROTECTED]
regression: msvc4.0 install dies sooner now
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 read version info from C:\windows\kernel386.drv' message (more or less), then hung. wine-20021125 (from source): installer started; when I clicked on 'Install Visual C++', it hung. Looks like a regression to me. Logs of --debugmsg +relay are up at http://www.kegel.com/msvc4setup-wine20020605.log.bz2 http://www.kegel.com/msvc4setup-wine20021125.log.bz2 The latter file is 28MB uncompressed, 512KB compressed. I'm now building the intermediate releases of wine to see if I can narrow down when the regression occurred. - Dan
Wine REALLY emulates Windows (was: Texture corruption in Wine)
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 Wine. Then my motherboard died, and I replaced it with an SMP mobo. I had to do some tweaks to my kernel, my X server, and to Wine to get everybody back up. But when I was done, and I went to install Halflife-Blue shift, the textures were screwed up. So were the textures in OpFor. I tried booting UMP, I tried scraping the fake Windows install and reinstalling, to no avail. Friday, I downloaded Transgamings WineX in an effort to remove a few variables from the matrix. WineX ran BlueShift and OpFor flawlessly - exonerating my X server, kernel and system. So, this morning I set about trying to find out what changed in Wine. I went back and pulled Wine as of the 20020902 tag, and rebuilt. Then I did my usual install method: rm /usr/local/winelibs /usr/local/include/wine /usr/local/bin/win* -R make install Still had no luck with Halflife - still had corrupted textures. So, I moved my fake Windows and .wine directories out of the way, created new, empty directories, copied my old .wine/config over, re-installed the Wine default registry, and re-installed Blueshift. And it worked. OK, maybe the install had problems. I moved my new fake windows and .wine directories out of the way, and moved the old directories back. And still, it worked. All textures were fine. Note: at this point, I should have had the OLD install of Blueshift back in place, and the old registry. The very one that didn't work five paragraphs ago. So, I went to my image of the current CVS of Wine, rebuilt it, and once again did a rm /usr/local/winelibs /usr/local/include/wine /usr/local/bin/win* -R make install. And still, it worked. In theory, I should have been back to where I started from. Except where I started from didn't work. Where I was did. Now, I am at a loss as to what could have changed from the non-working state to the working state. Like I said, Wine has the whole Windows mysterious changes thing down pat! But it works. As Bugs Bunny said, I don't ask questions, I just have fun. So, I am off to kill some headcrabs. But for the life of me I don't know HOW what I did fixed it
Re: strcat+strcat+strcat == baaad
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) - length of string i (0i=n) sm(i) - sigma of all lengths up to i (0i=n) sm(n) - total length of all strings with sprintf - parsing the format string*n+sm(n) with strcpy+strcat - for each strcat we have to find the end of the string (sm(i-1)), and then write our own string (m(i)). Shachar Shemesh wrote: 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 sun@sun:~/sources/wine/test$ ./way2 Operation took 0 seconds 598408 usec sun@sun:~/sources/wine/test$ ./way3 Operation took 0 seconds 427037 usec Was going to say earlier, but didn't get to it ... the reason is probably that you were underestimating the time required to parse the format string, which is probably greater than anything else. Everything else is simple searching and copying whereas the parsing is probably at least a quadratic-order function. Anyway you've now demonstrated that so this isn't that relevant anymore... David
Re: regression: msvc4.0 install dies sooner now
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 button. (Easy, right?) It works fine in Wine-20020804, but fails in Wine-20020904 and later. Logs at http://www.kegel.com/msvc4-setup-wine-20020804.ok.log.bz2 http://www.kegel.com/msvc4-setup-wine-20020904.bad.log.bz2 The interesting part is the 1000 lines after the line containing 'Button'; it looks like in the later wines, the program gets stuck in a WaitForSingleObject, maybe. I have to kill Wine to recover. Next step appears to be for me to download ftp://ftp.winehq.com/pub/wine/wine-cvsdirs-20020804.tar.gz and start fetching the cvs tree as of particular days in August, and figure out exactly which commit caused the regression. What cvs command do I use to do that (it's not documented on winehq.com, I think)? Or is there a better way? Thanks, Dan
