December 2002 - Wine-Devel - list.winehq.org

Re: Cabinet update

by Alexandre Julliard

Patrik Stridvall <ps(a)leissner.se> writes: > *** cabinet > > * include/fci.h, > include/fdi.h, > dlls/cabinet/Makefile.in, > dlls/cabinet/fci.c, > dlls/cabinet/fdi.c, > dlls/cabinet/main.c: > - Added previously forgotten file main.c. There is no reason to have a stub DllMain, it only slows things down and makes no difference for the app. We should only add it if/when we really need it. -- Alexandre Julliard julliard(a)winehq.com

Dec. 2, 2002

Re: Janitorial Projects

by Francois Gouget

On Sun, 1 Dec 2002, Dimitrie O. Paun wrote: [...] > This is too complicated. First, it requires Visual C++, which sucks. I think that being able to compile the tests with Visual C++ is very important. There are a lot of professional Windows programmers out there who have Visual C++ and who would be very qualified for writing tests and who may not want to install MinGW on their Windows machine. So it's important to make it as easy as possible for them to write tests in the environment they are most confortable with, i.e. Visual C++. > 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 That said I agree that the tests should also be compilable with MinGW because OSS projects should strive to be self-sufficient. > * arrange such that we can generate _one_ executable for all tests I think this is not necessary. All we need is a batch file to invoke all the tests and Patrik has already supplied that part. > * 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. All that's needed now is the packaging of the batch file plus the test executables. Then we may start on the automation aspects but it may not be very easy unless we can cross-compile the tests, i.e. generate Windows executables from Linux (which I believe should be possible). -- Francois Gouget fgouget(a)free.fr http://fgouget.free.fr/ Nouvelle version : les anciens bogues ont été remplacés par de nouveaux.

Dec. 2, 2002

Re: The conformance tests need you!

by Martin Wilck

Am Mon, 2002-12-02 um 19.12 schrieb Francois Gouget: > > Am Sam, 2002-11-30 um 04.02 schrieb Francois Gouget: > > > > > > Come on people, we can do better. > > > Send fixes to wine-patches, and send me emails to so that I update this > > > table. > > > > I'll have a look at the winsock stuff. > > Thanks :-) I am currently having trouble with running stuff natively on Windows. Can anybody run the winsock test with verbose output (trace enabled) on Windows NT and send me the result ? Martin -- Martin Wilck Phone: +49 5251 8 15113 Fujitsu Siemens Computers Fax: +49 5251 8 20409 Heinz-Nixdorf-Ring 1 mailto:Martin.Wilck(a)Fujitsu-Siemens.com D-33106 Paderborn http://www.fujitsu-siemens.com/primergy

Dec. 2, 2002

Re: Winelib - MFC application

by Dimitrie O. Paun

On December 2, 2002 10:57 am, jaymz(a)free.fr wrote: > >What exatcly did you do for this one? > > Comment out the section that defined NONAMELESSTRUCT and NONAMELESSUNION >From the Makefile? > >>- There was a conflict on HKEY type between <afxres.h> and > >> <wine/windef.h> > > > >What did you do? > > > > remove one of them ! Maybe we can find a solution that doesn't require removing anything! :) It works on Windows, how do they do it? > >>- Some little others syntax issues like: __try __expect, asm {}, > >>unsigned short(x), (LPCTSTR)CString > >> > > > >I reckon these are mods to the MFC source, no? > > yes ! I'd be curious to see the patch, if you can make it available, of course... -- Dimi.

Dec. 2, 2002

Re: strcat+strcat+strcat == baaad

by Alexandre Julliard

David Laight <david(a)l8s.co.uk> writes: > Yes, but even then strcpy may not be safe! Another thread could change > the length after you've counted it. Please, this is silly. If another thread is changing the string, all string functions will break, strlcpy is not magically "safer" than strcpy. -- Alexandre Julliard julliard(a)winehq.com

Dec. 2, 2002

POSE (Palm OS Emulator) on WINE?

by Bodo Wenzel

Hi list. Because Sony doesn't provide a Unix source code branch, I tried to run their Windows based POSE on WINE. At first glance it runs, but only until a command of the context menu is chosen. WINE reports an "unhandled exception" and launches the debugger. My question: does anyone heard about how to make POSE run on WINE? Is anyone interested in making them work together? Both are Open Source... Unfortunately I can't because of my lack of time :-( TIA, Bodo

Dec. 2, 2002

How to fix display errors?

by Ferenc Wagner

Hello, I decided to forward a previous post of mine from the users' newsgroup, since I got no answers there, and consider this a developer question: I'd like to correct some bugs. Having read the Developers' Guide didn't help me much: the relevant topic was empty (the program runs, but shows some errors). Perhaps you can point me in the right direction (I mean: source file in the tree)? Below is the article. See a screenshot at http://afavant.elte.hu/~wferi/wine.png (25K). It exhibits several slight problems. 1. The scrollable list has no border (Suchanfrage window, above the Phrasensuche checkbox). 2. The text input field (with Goethe in it) has no border, too. 3. The "Minimize" button is misplaced: clicking to the right of it invokes its action, the button itself is not clickable. 4. The little toolbar window to the right looks strange, but what is worse, it is sticky: appears on every viewport (It's not managed by fvwm2, like the main window.) The Suchanfrage subwindow is not sticky. While executing the program, I get the following messages: err:toolbar:ToolbarWindowProc unknown msg 0465 wp=0000004c lp=412c1d70 fixme:accel:CreateAcceleratorTableA should check that the accelerator descriptions are valid, return NULL and SetLastError() if not. fixme:mdi:MDIRefreshMenu partially function stub fixme:mdi:MDIRefreshMenu partially function stub err:statusbar:StatusWindowProc unknown msg 0486 wp=0000 lp=00000000 err:toolbar:ToolbarWindowProc unknown msg 0486 wp=00000000 lp=00000000 fixme:accel:CreateAcceleratorTableA should check that the accelerator descriptions are valid, return NULL and SetLastError() if not. fixme:mdi:MDIRefreshMenu partially function stub fixme:mdi:MDIRefreshMenu partially function stub fixme:mdi:MDIRefreshMenu partially function stub fixme:mdi:MDIRefreshMenu partially function stub fixme:mdi:MDIRefreshMenu partially function stub Is there anything I can do about the above (cosmetic) errors? I use a recent CVS checkout (Wine 20021125), and I know C programming, but have no experience with graphics and Windows. Feri.

Dec. 2, 2002

Re: strcat+strcat+strcat == baaad

by David Laight

> > And in any case the right approach to writing > > correct and secure code is not to truncate every string in sight to > > some fixed buffer size; it's to make sure you allocate buffers of the > > right size, and then you can use standard strcpy/strcat/sprintf/etc. > > without worrying about lengths. Yes, you can use a small (on stack) buffer for the 'usual' case and only allocate a large one in the unusual ones. (but don't use alloca()...) > I think this statement has to be tightened. I am sure you know exactly what > you mean, Alexandre, and I believe that I and many others do. However I > think we need to mention that one needs to consider that the strings passed > in may be bad, e.g. unterminated. Either one uses that actual measured > lengths of the strings when allocating or one checks the lengths of the > strings against the allocated space. Yes, but even then strcpy may not be safe! Another thread could change the length after you've counted it. > In particular one DOES NOT allocate on > the basis of some wishy-washy documentation statement or a hard-coded > constant that the caller may well have ignored. Absolutely! David -- David Laight: david(a)l8s.co.uk

Dec. 2, 2002

Re: strcat+strcat+strcat == baaad

by Martin Wilck

Am Mon, 2002-12-02 um 13.57 schrieb David Laight: > It is as if the code from your program is executing far > slower than anything from libc! That is very well possible if he has the right libc. Take a look at the optimizations in the string functions in glibc, and you'll have an idea why. Unless you are a assembler programming Guru for a certain architecture, you'll have a hard time beating them. Martin -- Martin Wilck Phone: +49 5251 8 15113 Fujitsu Siemens Computers Fax: +49 5251 8 20409 Heinz-Nixdorf-Ring 1 mailto:Martin.Wilck(a)Fujitsu-Siemens.com D-33106 Paderborn http://www.fujitsu-siemens.com/primergy

Dec. 2, 2002

Re: strcat+strcat+strcat == baaad

by Martin Wilck

Am Son, 2002-12-01 um 23.07 schrieb Shachar Shemesh: > When I'm wrong, I'm wrong. > sun(a)sun:~/sources/wine/test$ ./way1 > Operation took 0 seconds 450763 usec > sun(a)sun:~/sources/wine/test$ ./way2 > Operation took 0 seconds 598408 usec > sun(a)sun:~/sources/wine/test$ ./way3 > Operation took 0 seconds 427037 usec First off, the program is wrong in that "way3" doesn't do what it's supposed to (concatenate). Below is a patch for your benchmark with a "WAY4" going a similar path as WAY3, but using strlen() and memcpy(), and a WAY5 that is pretty similar to David's, but better with gcc 3.2. My resume is: Don't try to outwit the C library. Assume that the user has installed a good one, and use library functions. (Btw ever looked at the section about "strcat" in the glibc info pages?) WAY4 below is very fast with a good C library. On i686, it is best for all optimizations except -O1 where gcc inlines self-generated i386-optimized code which is more than a factor of 2 slower than the library routine. It also requires the "-march=i686" option to gcc, otherwise gcc wrongly assumes that i386 optimizations are the best, and uses them always. Of course, if the lengths of the strings are known, you can speed this up a lot by doing without strlen(). WAY2 depends on the "strcat" implementation in the library. It may be slower than the snprintf solution if strcat is badly optimized. (And it's unsafe)! David's WAY3, being not library dependent, is quite good except for -O0. With GCC 3.2 and optimization -O2 and above, it is necessary to reverse the "if" and "else" clauses in str_add(), otherwise performance degrades because gcc assumes the "if" branch is taken more often. (That reversed str_add is called "WAY5" below. These are my results, obtained on a PIII system with RedHat 8.0, using "gcc -Ox -march=i686" as optimization: (I took gcc3.2 -O0 as "reference value" 1.0): GCC 3.2 -O0 -O1 -O2 -O3 WAY1 1.00 0.98 0.97 0.97 WAY2 0.93 0.98 0.92 0.93 WAY3 2.28 0.67 0.95 1.05 WAY4 0.49 1.00 0.46 0.41 WAY5 2.53 0.66 0.66 0.76 GCC 2.96 -O0 -O1 -O2 -O3 WAY1 1.00 0.98 1.02 1.02 WAY2 0.93 0.93 0.93 0.93 WAY3 2.21 0.67 0.69 0.63 WAY4 0.49 1.02 0.48 0.42 WAY5 2.42 0.67 0.69 0.63 Martin --- strorg.c Mon Dec 2 13:29:43 2002 +++ strcpy.c Mon Dec 2 17:35:00 2002 @@ -12,15 +12,38 @@ int c; do { +#if WAY5 + if ( s < lim ) c = *a++; + else { + s = lim - 1; + c = 0; + } +#else if (s >= lim) { s = lim - 1; c = 0; } else c = *a++; +#endif *s++ = c; } while (c); - return s; + return --s; +} + +char* +str1_add(char*s, int *len, const char *a) +{ + + int l = strlen(a); + if ( l >= *len ) + l = *len - 1; + + memcpy ( s, a, l ) ; + *len -= l; + s += l; + *s = 0; + return s; } int main() @@ -32,7 +55,7 @@ gettimeofday(&before, NULL); for( i=0; i<NUM_ITER; ++i ) { -#ifdef WAY1 +#if WAY1 strcpy( buffer, STRING ); strcat( buffer, STRING ); strcat( buffer, STRING ); @@ -46,21 +69,33 @@ #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 +#elif ( WAY3 || WAY5 ) 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 ); + pointer=str_add( pointer, limit, STRING ); + pointer=str_add( pointer, limit, STRING ); + pointer=str_add( pointer, limit, STRING ); + pointer=str_add( pointer, limit, STRING ); + pointer=str_add( pointer, limit, STRING ); + pointer=str_add( pointer, limit, STRING ); + pointer=str_add( pointer, limit, STRING ); + pointer=str_add( pointer, limit, STRING ); + pointer=str_add( pointer, limit, STRING ); + pointer=str_add( pointer, limit, STRING ); +#elif WAY4 + char *p = buffer; + int len = sizeof(buffer); + p = str1_add (p, &len, STRING); + p = str1_add (p, &len, STRING); + p = str1_add (p, &len, STRING); + p = str1_add (p, &len, STRING); + p = str1_add (p, &len, STRING); + p = str1_add (p, &len, STRING); + p = str1_add (p, &len, STRING); + p = str1_add (p, &len, STRING); + p = str1_add (p, &len, STRING); + p = str1_add (p, &len, STRING); #endif } gettimeofday(&after, NULL); @@ -70,13 +105,7 @@ diff_sec=after.tv_sec-before.tv_sec; diff_usec=after.tv_usec-before.tv_usec; - if( diff_usec<0 ) - { - diff_usec+=1000000; - diff_sec--; - } - - printf("Operation took %ld seconds %ld usec\n", diff_sec, diff_usec ); + printf("Operation took %07ld usec\n", diff_sec * 1000000 + diff_usec ); } return 0; -- Martin Wilck Phone: +49 5251 8 15113 Fujitsu Siemens Computers Fax: +49 5251 8 20409 Heinz-Nixdorf-Ring 1 mailto:Martin.Wilck(a)Fujitsu-Siemens.com D-33106 Paderborn http://www.fujitsu-siemens.com/primergy

Dec. 2, 2002

Re: valgrind and wine

by Dan Kegel

Aric Stewart wrote: > I have actually worked a little with Julian Steward on this problem > just before 1.1.0 I actually have a build of valgrind here on my laptop > with works with very simple wine applications. I remember there was one > hack i had to do to the valgrind source to disable some of its sanity > checking. > > I could not get valgrind to work with more advanced wine programs > because i kept getting > > trace:seh:EXC_RtlRaiseException code=eedfade flags=1 addr=0x402e1a30 > > if you want to work with valgrind i will did up how i turned off the > sanity checking with 1.1.0 and see if you can get it working. Yes, please do document how you got valgrind to start working with Wine! Maybe somebody bright with time on their hands will be able to solve the issue you ran into. Thanks, Dan

Dec. 2, 2002

RE: strcat+strcat+strcat == baaad

by Medland, Bill

> -----Original Message----- > From: wine-devel-admin(a)winehq.com > [mailto:wine-devel-admin(a)winehq.com]On > Behalf Of Alexandre Julliard > Sent: Monday, December 02, 2002 9:03 AM > To: Shachar Shemesh > Cc: David Laight; David Fraser; Shachar Shemesh; Francois Gouget; > wine-devel(a)winehq.com > Subject: Re: strcat+strcat+strcat == baaad > > > Shachar Shemesh <winehebhaim(a)sun.consumer.org.il> writes: > > > I suggest implementing strlcat and strlcpy, as in OpenBSD. > I can write > > them, but I'm not sure where to place them. They should either be > > inlined (as in - implemented in an include file as a static > func), or > > in some library that will be linked (statically, I hope). Ideas? > > We don't need that, there are Windows API functions like lstrcpyn that > can be used for that. And in any case the right approach to writing > correct and secure code is not to truncate every string in sight to > some fixed buffer size; it's to make sure you allocate buffers of the > right size, and then you can use standard strcpy/strcat/sprintf/etc. > without worrying about lengths. I think this statement has to be tightened. I am sure you know exactly what you mean, Alexandre, and I believe that I and many others do. However I think we need to mention that one needs to consider that the strings passed in may be bad, e.g. unterminated. Either one uses that actual measured lengths of the strings when allocating or one checks the lengths of the strings against the allocated space. In particular one DOES NOT allocate on the basis of some wishy-washy documentation statement or a hard-coded constant that the caller may well have ignored. > > -- > Alexandre Julliard > julliard(a)winehq.com > > Bill Medland

Dec. 2, 2002

Re: strcat+strcat+strcat == baaad

by Alexandre Julliard

Shachar Shemesh <winehebhaim(a)sun.consumer.org.il> writes: > I suggest implementing strlcat and strlcpy, as in OpenBSD. I can write > them, but I'm not sure where to place them. They should either be > inlined (as in - implemented in an include file as a static func), or > in some library that will be linked (statically, I hope). Ideas? We don't need that, there are Windows API functions like lstrcpyn that can be used for that. And in any case the right approach to writing correct and secure code is not to truncate every string in sight to some fixed buffer size; it's to make sure you allocate buffers of the right size, and then you can use standard strcpy/strcat/sprintf/etc. without worrying about lengths. -- Alexandre Julliard julliard(a)winehq.com

Dec. 2, 2002

Re: valgrind and wine

by Aric Stewart

Hello, I have actually worked a little with Julian Steward on this problem just before 1.1.0 I actually have a build of valgrind here on my laptop with works with very simple wine applications. I remember there was one hack i had to do to the valgrind source to disable some of its sanity checking. I could not get valgrind to work with more advanced wine programs because i kept getting trace:seh:EXC_RtlRaiseException code=eedfade flags=1 addr=0x402e1a30 if you want to work with valgrind i will did up how i turned off the sanity checking with 1.1.0 and see if you can get it working. -aric Lionel Ulmer wrote: >>==6476== Valgrind detected that your program requires >>==6476== the following unimplemented functionality: >>==6476== modify_ldt(): I (JRS) haven't investigated this yet; sorry. >>==6476== This may be because the functionality is hard to implement, >>==6476== or because no reasonable program would behave this way, >>==6476== or because nobody has yet needed it. In any case, let me know >>==6476== (jseward(a)acm.org) and/or try to work around the problem, if you can. > > > Which version of Valgrind is this ? According to the web page, 1.1.0 should > support this system call : 'Specifically, valgrind can now deal with x86 > segment registers, segment override prefixes and the modify_ldt system > call'. > > But well, for it to really be useful, we would need then also to override in > Valgrind (or in Wine) all the Threading and Heap functions. > > Lionel >

Dec. 2, 2002

Re: Winelib - MFC application

by jaymz＠free.fr

Dimitrie O. Paun wrote: >>The packing pragmas looks handled by gcc-3.2.1, so we may remove all >>modifications made by winemaker >> >> >Maybe winemaker should be patched to not add them based on a >switch (maybe determine default value based on compiler). >BTW, do you _have_ to remove them, or it doesn't matter? > It was just warning issues >>I had to force winnt.h to use nameless struct and unions >> >> >What exatcly did you do for this one? > Comment out the section that defined NONAMELESSTRUCT and NONAMELESSUNION >>- I added #define EDEADLOCK EDEADLK in /wine/msvcrt/errno.h >> >> >Sounds like a patch would be in order, no? > >>- I linked _alloca() to alloca() function >> >> >Where? Again, maybe you should submit this one. > >>- There was a conflict on HKEY type between <afxres.h> and <wine/windef.h> >> >> >What did you do? > > remove one of them ! >>- Some little others syntax issues like: __try __expect, asm {}, >>unsigned short(x), (LPCTSTR)CString >> >> >I reckon these are mods to the MFC source, no? > yes !

Dec. 2, 2002

Re: Wine/FF7 midi help request

by Jeff Smith

>From: Robotech_Master <robotech(a)eyrie.org> > >On Tue Jun 11 2002 - 13:50:43 CDT Johan Gill wrote (as part of a >discussion about midi in WINE in which FF7 was mentioned): > > > Done. TiMidity++-2.12.0beta as alsa sequencer client requires no > > modification to wine at all, and the OSS emulation of ALSA makes the > > thing transparent to WINE. > >Can you, or someone, please let me know how to set up wine to use >this? I'm running Debian Linux; these are the versions of timidity >and wine that I have: > >ii timidity 2.11.2-1.3 Software-only MIDI sequencer. >ii wine 0.0.20021125-1 Windows Emulator (Binary Emulator) This is something I would not mind knowing myself. It's not too high a priority for me though as I have SoundFonts working on my SBLive now. >For sound, I'm using artsdsp 0.6.1 to emulate esd. I have a >Soundblaster live card. > >On the FF7 config program, it gives me the choices > > Wine OSS midi out (#0) - disabled > EMU10K1 midi This looks like what I would get from the OSS driver - emu10k1. The module name for the ALSA driver is snd-emu10k1. The choices I would expect from ALSA's OSS emulation would be something like: Emu10k1 MIDI 0-0 Emu10k1 Port 0 Emu10k1 Port 1 Emu10k1 Port 2 Emu10k1 Port 3 >Under "midi data" it gives me the choises > > General midi > Soundfont midi (Creative AWE32/AWE64) > Yamaha XG midi I would imagine this should stay on General midi unless you are *sure* it needs to be on another selection. >No matter what I try, in whatever combination, I get "Error opening >device" and the wine console says > >fixme:winmm:MIDI_StreamOpen *lpuDeviceID=1 >fixme:dsound:IDirectSoundImpl_SetCooperativeLevel >(0x403ab930,0001003c,3):stub > >Can someone help me out--or point me at somewhere else I can find >help? Try running it like this ... wine -debugmsg +winmm,+midi,+msacm program_name.exe ... and send the output. -- Jeff S _________________________________________________________________ Add photos to your messages with MSN 8. Get 2 months FREE*. http://join.msn.com/?page=features/featuredemail

Dec. 2, 2002

Re: regression: msvc4.0 install dies sooner now

by Dimitrie O. Paun

On December 2, 2002 03:04 am, Greg Turner wrote: > cvs is the "right way" although I forget how it's done. I've used tkcvs > for this sort of thing. it's a horrible anachronistic kinda gui but it > has a really useful graphical view of each file's history in there that > can be a huge help when tracking down a particular change. A picture > is worth 1000 keystrokes sometimes... BTW, anyone willing to take wincvs for a spin. Is a very nice CVS frontend, for those of use addicted to clicking about, and a perfect target for Wine! http://www.wincvs.org -- Dimi.

Dec. 2, 2002

Winelib - MFC application

by jaymz＠free.fr

I'm currently trying to build an MFC based-applications using Winelib. I (almost) successfully compiled the MFC, and get an mfc.dll.so file. Here are the few troubles I had or still have: First for compiling the MFC: --------------------------------------- - I had to uncomment PSH_WIZARD97 in /wine/prsht.h - The packing pragmas looks handled by gcc-3.2.1, so we may remove all modifications made by winemaker - I had to force winnt.h to use nameless struct and unions - I added #define EDEADLOCK EDEADLK in /wine/msvcrt/errno.h - I linked _alloca() to alloca() function - There was a conflict on HKEY type between <afxres.h> and <wine/windef.h> - Some little others syntax issues like: __try __expect, asm {}, unsigned short(x), (LPCTSTR)CString ==> it worked then, using some additional defines as suggested in the Winelib documentation page. Then for my MFC-based application: ------------------------------------------------- - Winemaker tries to link with libmfc.so, but by default we have a dll, so i just symlink it to mfc.dll.so - I first tried winemaker default settings on my app, but it creates two targets with the same name (the dll and the executables), so I had to override this using interactive mode - Then I encountered the MFC initialization problems (a crash in dllname() when loading my application .so), so I added the wrapper using winemaker - Even when using the wrapper, it crashes at startup when trying to load my application dll. - The backtrace is something like dllname (from libmfc.so) operator new ... Init (from /gcc-3.2.1/libstdc++-v3/src/ios.cc:211) ___static_initialization_and_destruction_ ... _dl_open ... WinMain (from myapp.exe_wrapper.c:83) __wine_exe_main (from myapp.exe.spec.c:129) start_process call_on_thread_stack - Winelib must have been initialized, but the problem stills here ? Any suggestion ? - I then tried to remove linking with libmfc.so but using only the mfc.dll.so (I had to fill the mfc.dll.spec file to export all the symbols, using weird mangling rules), but it then hook in the msvcrt.dll in an infinite _lock loop ? I'm a bit lost with this error, as it's not in an easy-to-debug code area.... Any advices are welcomed !

Dec. 2, 2002

Re: Screenshots v0.1

by Dimitrie O. Paun

On December 1, 2002 02:41 pm, Brian Vincent wrote: > I've gotten a lot of great screenshots over the past few weeks. I've > put together a preview you can find here: > > http://www.theshell.com/~vinn/ss/preview.html Very nice! I'll add the link to the TODO entry. > Be warned, the format isn't the best, the thumbnails aren't even close > to optimized, I only looked at it in one browser, and it might even steal > your lunch money. They look great man, what do you want to optimize them for? :) > Okay, if you've read this far maybe you're expecting something to > prompt discussion. One of the things you'll notice is there's a > lot of screenshots on there there almost certainly don't run out > of the box. In some instances the folks above listed exactly what > they had to do to make it run. Personally, I don't think it matters. > We already have the apps DB and the proposed "Gold/Silver/.." apps > list, I really don't think we need more than a link to one of those. Indeed. I would say as long as the app runs decently (with whatever tricks) it's OK. But if the app runs enough just to produce the shot... it's not fair, kinda like false advertisement. -- Dimi.

Dec. 2, 2002

Re: Winelib - MFC application

by Dimitrie O. Paun

On December 2, 2002 10:04 am, Ronald MALLET wrote: Cool! Shouldn't some of these be submitted as patches? > First for compiling the MFC: > --------------------------------------- > - I had to uncomment PSH_WIZARD97 in /wine/prsht.h > - The packing pragmas looks handled by gcc-3.2.1, so we may remove all > modifications made by winemaker Maybe winemaker should be patched to not add them based on a switch (maybe determine default value based on compiler). BTW, do you _have_ to remove them, or it doesn't matter? > - I had to force winnt.h to use nameless struct and unions What exatcly did you do for this one? > - I added #define EDEADLOCK EDEADLK in /wine/msvcrt/errno.h Sounds like a patch would be in order, no? > - I linked _alloca() to alloca() function Where? Again, maybe you should submit this one. > - There was a conflict on HKEY type between <afxres.h> and <wine/windef.h> What did you do? > - Some little others syntax issues like: __try __expect, asm {}, > unsigned short(x), (LPCTSTR)CString I reckon these are mods to the MFC source, no? -- Dimi.

Dec. 2, 2002

Winelib - MFC application

by Ronald MALLET

I'm currently trying to build an MFC based-applications using Winelib. I (almost) successfully compiled the MFC, and get an mfc.dll.so file. Here are the few troubles I had or still have: First for compiling the MFC: --------------------------------------- - I had to uncomment PSH_WIZARD97 in /wine/prsht.h - The packing pragmas looks handled by gcc-3.2.1, so we may remove all modifications made by winemaker - I had to force winnt.h to use nameless struct and unions - I added #define EDEADLOCK EDEADLK in /wine/msvcrt/errno.h - I linked _alloca() to alloca() function - There was a conflict on HKEY type between <afxres.h> and <wine/windef.h> - Some little others syntax issues like: __try __expect, asm {}, unsigned short(x), (LPCTSTR)CString ==> it worked then, using some additional defines as suggested in the Winelib documentation page. Then for my MFC-based application: ------------------------------------------------- - Winemaker tries to link with libmfc.so, but by default we have a dll, so i just symlink it to mfc.dll.so - I first tried winemaker default settings on my app, but it creates two targets with the same name (the dll and the executables), so I had to override this using interactive mode - Then I encountered the MFC initialization problems (a crash in dllname() when loading my application .so), so I added the wrapper using winemaker - Even when using the wrapper, it crashes at startup when trying to load my application dll. - The backtrace is something like dllname (from libmfc.so) operator new ... Init (from /gcc-3.2.1/libstdc++-v3/src/ios.cc:211) ___static_initialization_and_destruction_ ... _dl_open ... WinMain (from myapp.exe_wrapper.c:83) __wine_exe_main (from myapp.exe.spec.c:129) start_process call_on_thread_stack - Winelib must have been initialized, but the problem stills here ? Any suggestion ? - I then tried to remove linking with libmfc.so but using only the mfc.dll.so (I had to fill the mfc.dll.spec file to export all the symbols, using weird mangling rules), but it then hook in the msvcrt.dll in an infinite _lock loop ? I'm a bit lost with this error, as it's not in an easy-to-debug code area.... Any advices are welcomed !

Dec. 2, 2002

Re: regression: msvc4.0 install dies sooner now

by Paul Millar

On Mon, 2 Dec 2002, Greg Turner wrote: > cvs is the "right way" although I forget how it's done. For the record, Gerard's writeup on how to do CVS regression hunting is available here: http://cvs.winehq.com/cvsweb/wine/documentation/cvs-regression.sgml ---- Paul Millar

Dec. 2, 2002

Re: strcat+strcat+strcat == baaad

by David Laight

> optimizations: -O2 strcpy/cat sprintf snprintf str_add stpcpy > 2.926220 1.427674 1.408928 3.405458 0.892890 1000 > 2.622081 1.308464 1.292384 3.062085 0.867009 900 > 2.363464 1.169335 1.152487 2.727685 0.740690 800 These do not look right, in particular the first column is too fast. For instance my system gives (NUM_ITER=1000): 0.174988 0.042060 0.042097 0.057267 1000 0.155118 0.038678 0.038592 0.051500 900 0.138036 0.034586 0.034597 0.045832 800 ... 0.005573 0.006449 0.006452 0.002103 30 0.003858 0.005962 0.005964 0.001536 20 0.002163 0.005783 0.005802 0.000967 10 It is as if the code from your program is executing far slower than anything from libc! David -- David Laight: david(a)l8s.co.uk

Dec. 2, 2002

RE: strcat+strcat+strcat == baaad

by Patrik Stridvall

> I suggest implementing strlcat and strlcpy, as in OpenBSD. I > can write > them, but I'm not sure where to place them. They should either be > inlined (as in - implemented in an include file as a static > func), or in > some library that will be linked (statically, I hope). Ideas? Since the do exists on some platforms (OpenBSD and FreeBSD) the obvious place to put them would be library/port.c like any other function that doesn't exists on all platforms. Just remember to add detect in configure.ac and use the HAVE_ macro in library/port.c As for (re)writing them. Why not just borrow the source from FreeBSD or OpenBSD. They both have licenses compatible with Wine. No need to reinvent the wheel.

Dec. 2, 2002

Re: Screenshots v0.1

by Mike Hearn

Good stuff Brian, I saw the new preview page earlier. Even I was impressed by what Wine can do and I've been using it for a while now so that has to be a good start. I dunno, maybe you could have a "see more screenshots" link which just links to a directory with symlinks to the rest of the screenshots that weren't included, no matter what the size etc: I know some people who just *cannot* get enough screenshots sometimes. On Sun, 2002-12-01 at 19:41, Brian Vincent wrote: > I've gotten a lot of great screenshots over the past few weeks. I've > put together a preview you can find here: > > http://www.theshell.com/~vinn/ss/preview.html > > Be warned, the format isn't the best, the thumbnails aren't even close > to optimized, I only looked at it in one browser, and it might even steal > your lunch money. > > Random notes: > > - there's lots of great shots not on the thumbnails page - most likely > there's a reason, not 800x600, didn't scale well, or I simply overlooked it > > - you can find all of the screenshots at: > http://www.theshell.com/~vinn/ss > > - the images predominantly are PNG, though there are quite a few JPEGs. > No GIF. > > - Special thanks to: > Thomas Wickline > Carlos Lozano > David Buchmann > Guido Grazioli > Ender > Juliasz Gonera > Michael Krasucki > Mike Hearn > Rick Romero > Robert Shade > Rory King > Tony Lambregts > tavis > > Okay, if you've read this far maybe you're expecting something to > prompt discussion. One of the things you'll notice is there's a > lot of screenshots on there there almost certainly don't run out > of the box. In some instances the folks above listed exactly what > they had to do to make it run. Personally, I don't think it matters. > We already have the apps DB and the proposed "Gold/Silver/.." apps > list, I really don't think we need more than a link to one of those. > > Also, a few weeks ago there was a lot of discussion of a new WineHQ > site. Any progress on that front? > > -Brian Vincent -- Mike Hearn <m.hearn(a)signal.qinetiq.com> QinetiQ - Malvern Technology Center

Dec. 2, 2002

Re: strcat+strcat+strcat == baaad

by Shachar Shemesh

David Laight wrote: >Inlining them would (probably) be bad news. They are not >a completely trivial size (ie smaller than the call sequence) >and they are more likely to be resident in the Icache if they >are functions. > Yes, but they are much more likely to fit into the function scope optimization if they are inlined. >They are useful though, and do what the programmer wanted >(unlike strncpy whose only point is that it doesn't overrun >the target buffer). > >However in this case they aren't quite right! > > len = strlcpy(buf, s0, buflen); > len += strlcpy(buf + len, s1, buflen - len) > len += strlcpy(buf + len, s2, buflen - len) > ahem. The code should be: strlcpy(buf, s0, buflen); strlcat(buf, s1, buflen); strlcat(buf, s2, buflen); If you are going to be sliding the buffer with each call, then you can just as well use your functions. >is slightly more complex than using my str_add(). > >The source for the functions can be grabbed from netbsd or freebsd. > > David > > >

Dec. 2, 2002

Re: strcat+strcat+strcat == baaad

by David Laight

> I suggest implementing strlcat and strlcpy, as in OpenBSD. I can write > them, but I'm not sure where to place them. They should either be > inlined (as in - implemented in an include file as a static func), or in > some library that will be linked (statically, I hope). Ideas? Inlining them would (probably) be bad news. They are not a completely trivial size (ie smaller than the call sequence) and they are more likely to be resident in the Icache if they are functions. They are useful though, and do what the programmer wanted (unlike strncpy whose only point is that it doesn't overrun the target buffer). However in this case they aren't quite right! len = strlcpy(buf, s0, buflen); len += strlcpy(buf + len, s1, buflen - len) len += strlcpy(buf + len, s2, buflen - len) is slightly more complex than using my str_add(). The source for the functions can be grabbed from netbsd or freebsd. David -- David Laight: david(a)l8s.co.uk

Dec. 2, 2002

Re: strcat+strcat+strcat == baaad

by David Laight

> 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. I don't think they would be, and it is easy enough to check (objdump -d way1). Benchmarking is meaningless if you don't use the optimisation level then will be used in real life. Also the compiler is really designed to be used with -O, the code generatd without it is only 'half cooked'. > Do we go for David's suggestion, that is more efficient, but is also > more cubersome and requires two extra vars to implement right? The extra variables are likely to be well optimised by the compiler. strlcpy/cat will be even slower than the strcpy/cat versions. way1: 900 ms way1a: 1321 (strlcpy/cat) way2: 721 ms way3: 322 ms way3a: 223 ms (without bound check) David -- David Laight: david(a)l8s.co.uk

Dec. 2, 2002

Re: strcat+strcat+strcat == baaad

by Shachar Shemesh

David Laight wrote: >>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. >> >> > >No it will be linear (on the length of the format string). >But just rather more expensive than you probably expect. > That's the reason that I thought it will be faster. However, since the test program copied 40 bytes 10 times, which is a rather extreme case, and still was not faster, we can only conclude that sprinf is not practical for almost all standard cases. >There is a lot of red tape lurking. > > David > > This, however, does not answer the usability issue. Obviously, we won't put in patches that convert to anything else just because someone didn't like it (yes, I agree with Alexander on this point). There is, however, the question of buffer overruns. I suggest implementing strlcat and strlcpy, as in OpenBSD. I can write them, but I'm not sure where to place them. They should either be inlined (as in - implemented in an include file as a static func), or in some library that will be linked (statically, I hope). Ideas? For those who don't know strl* functions - they are just like strn* functions, except that the parameters are sane: In strn*: * Resulting string is not always NULL terminated. * In strncat, the terminating null is always written, but is not counted in the size!!! * The size parameter is sometimes the total size of the buffer, and sometimes the size of the unused portion of the buffer. * On strncpy, the entire buffer is written into, even if very little of it is needed (performance) All of the above make for awkward and error prone coding. In order to use strncat properly, you have to keep subtracting the number of characters already copied, and 1 for the terminating nul. As a result of these subtractions, a negative overflow (i.e. - from 0 to maxint) may happen, which in turn causes buffer overruns itself. Unlike it, in the strl* functions: * Resulting string is ALWAYS NULL terminated, whether there was enough room or not. * The buffer is not padded with NULLs beyond the terminating one (performance). * The number is ALWAYS the total buffer size. No arithmetics are necessary. Shachar

Dec. 2, 2002

Re: strcat+strcat+strcat == baaad

by David Laight

> 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. No it will be linear (on the length of the format string). But just rather more expensive than you probably expect. There is a lot of red tape lurking. David -- David Laight: david(a)l8s.co.uk

Dec. 2, 2002

Re: Adding support for xxx_test.exe all

by Francois Gouget

On 30 Nov 2002, Alexandre Julliard wrote: [...] > > Do others find this patch acceptable? Useful? > > The drawback I see is that with this change the tests do not start > with a clean process state, which could cause problem for some of > them. Or we need to require that all tests cleanup properly after > them, which may be a bit painful. Tests have to cleanup behind themselves to some extent otherwise it means they cannot be run twice in a row and that would be very bad. But yes, they might leave static variables behind or environment variables or whatnot. That would really not be very clean. The tests don't work well enough on Windows that I know whether that is the case or not. Note that it would be pretty easy to just 'system("xxx_test.exe foo") each individual test which would solve the above issue. It may be that with Patrik's script for running all tests the need for an 'xxx_test.exe all' may be lower. I'll play some more with the tests and maybe I'll submit a patch that adds an 'all' option based on 'system'. -- Francois Gouget fgouget(a)free.fr http://fgouget.free.fr/ La terre est une bêta...

Dec. 2, 2002

Re: regression: msvc4.0 install dies sooner now

by Greg Turner

On Monday 02 December 2002 01:19 am, Dan Kegel wrote: > 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 cvs is the "right way" although I forget how it's done. I've used tkcvs for this sort of thing. it's a horrible anachronistic kinda gui but it has a really useful graphical view of each file's history in there that can be a huge help when tracking down a particular change. A picture is worth 1000 keystrokes sometimes... -- gmt

Dec. 2, 2002

Wine/FF7 midi help request

by Robotech_Master

On Tue Jun 11 2002 - 13:50:43 CDT Johan Gill wrote (as part of a discussion about midi in WINE in which FF7 was mentioned): > Done. TiMidity++-2.12.0beta as alsa sequencer client requires no > modification to wine at all, and the OSS emulation of ALSA makes the > thing transparent to WINE. Can you, or someone, please let me know how to set up wine to use this? I'm running Debian Linux; these are the versions of timidity and wine that I have: ii timidity 2.11.2-1.3 Software-only MIDI sequencer. ii wine 0.0.20021125-1 Windows Emulator (Binary Emulator) For sound, I'm using artsdsp 0.6.1 to emulate esd. I have a Soundblaster live card. On the FF7 config program, it gives me the choices Wine OSS midi out (#0) - disabled EMU10K1 midi Under "midi data" it gives me the choises General midi Soundfont midi (Creative AWE32/AWE64) Yamaha XG midi No matter what I try, in whatever combination, I get "Error opening device" and the wine console says fixme:winmm:MIDI_StreamOpen *lpuDeviceID=1 fixme:dsound:IDirectSoundImpl_SetCooperativeLevel (0x403ab930,0001003c,3):stub Can someone help me out--or point me at somewhere else I can find help? Thanks. -- Chris Meadows aka | Co-moderator, rec.toys.transformers.moderated Robotech_Master | Homepage: <URL:http://www.eyrie.org/~robotech/> robotech(a)eyrie.org | And now I've started a weblog: | http://robotech_master.livejournal.com

Dec. 2, 2002

Re: strcat+strcat+strcat == baaad

by Michal Janusz Miroslaw

On Mon, 2 Dec 2002, Shachar Shemesh wrote: > When I'm wrong, I'm wrong. > > sun(a)sun:~/sources/wine/test$ gcc -O0 strcpy.c -o way1 -DWAY1 > sun(a)sun:~/sources/wine/test$ gcc -O0 strcpy.c -o way2 -DWAY2 > sun(a)sun:~/sources/wine/test$ gcc -O0 strcpy.c -o way3 -DWAY3 > sun(a)sun:~/sources/wine/test$ ./way1 > Operation took 0 seconds 450763 usec > sun(a)sun:~/sources/wine/test$ ./way2 > Operation took 0 seconds 598408 usec > sun(a)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? Well, I tested this further. Result's attached (test.log). Columns are: WAY1 (strcat), WAY2 (sprintf), WAY2_5(snprintf), WAY3 (str_add), WAY4(stpcpy). WAY4 is something I remembered from old DOS days, but it's nonstandard and probably available only in glibc. Since I used glibc compiled for i686 (pentium2), we probably should not consider entries with '-mcpu=pentium4' in comparision. Test platform: Pentium4 Northwood; linux-2.4.20; glibc-2.2.4 compiled with optimizations for Pentium2. My vote is for sprintf, as it can easily be converted to safer version and is easier to read. My two cents only. :) Michal Miroslaw

Dec. 2, 2002

Re: regression: msvc4.0 install dies sooner now

by Dan Kegel

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

Dec. 2, 2002

Re: strcat+strcat+strcat == baaad

by David Fraser

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 (0<i<=n) > sm(i) - sigma of all lengths up to i (0<i<=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(a)sun:~/sources/wine/test$ gcc -O0 strcpy.c -o way1 -DWAY1 > sun(a)sun:~/sources/wine/test$ gcc -O0 strcpy.c -o way2 -DWAY2 > sun(a)sun:~/sources/wine/test$ gcc -O0 strcpy.c -o way3 -DWAY3 > sun(a)sun:~/sources/wine/test$ ./way1 > Operation took 0 seconds 450763 usec > sun(a)sun:~/sources/wine/test$ ./way2 > Operation took 0 seconds 598408 usec > sun(a)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

Dec. 2, 2002

Wine REALLY emulates Windows (was: Texture corruption in Wine)

by David D. Hagood

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....

Dec. 1, 2002

regression: msvc4.0 install dies sooner now

by Dan Kegel

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

Dec. 1, 2002

Re: strcat+strcat+strcat == baaad

by Shachar Shemesh

When I'm wrong, I'm wrong. sun(a)sun:~/sources/wine/test$ gcc -O0 strcpy.c -o way1 -DWAY1 sun(a)sun:~/sources/wine/test$ gcc -O0 strcpy.c -o way2 -DWAY2 sun(a)sun:~/sources/wine/test$ gcc -O0 strcpy.c -o way3 -DWAY3 sun(a)sun:~/sources/wine/test$ ./way1 Operation took 0 seconds 450763 usec sun(a)sun:~/sources/wine/test$ ./way2 Operation took 0 seconds 598408 usec sun(a)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 > > >

Dec. 1, 2002

Re: DIB engine

by David

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, johane(a)lysator.liu.se

Dec. 1, 2002

RE: [RFC] Wine headers

by Patrik Stridvall

> 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...

Dec. 1, 2002

Re: [RFC] Wine headers

by Dimitrie O. Paun

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.

Dec. 1, 2002

Re: DIB engine

by Hetz Ben Hamo

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, johane(a)lysator.liu.se

Dec. 1, 2002

DIB engine

by Johan Gill

Hi all, I've just started working on the DIB engine, FYI. -- Johan Gill, johane(a)lysator.liu.se

Dec. 1, 2002

Re: strcat+strcat+strcat == baaad

by David Laight

> 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: david(a)l8s.co.uk

Dec. 1, 2002

Re: strcat+strcat+strcat == baaad

by Shachar Shemesh

Alexandre Julliard wrote: >Shachar Shemesh <wine-devel(a)sun.consumer.org.il> 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 (0<i<=n) sm(i) - sigma of all lengths up to i (0<i<=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

Dec. 1, 2002

Re: "not enough space in GDI heap" / forking vstlib programs

by Kjetil S. Matheussen

On Sun, 1 Dec 2002, Uwe Bonnes wrote: > Kjetil> So is there a way around this error. Doing a fork for each new > Kjetil> plug-in perhaps? Is that safe? I want to do that also to avoid > Kjetil> having a plug-in crash the vst-server. > > Did you get this error with a recent wine version? I hadn't had this errors > for some time now. > Yes, Wine-20021031. How about forking a winelib program, is that legal? --

Dec. 1, 2002

Screenshots v0.1

by Brian Vincent

I've gotten a lot of great screenshots over the past few weeks. I've put together a preview you can find here: http://www.theshell.com/~vinn/ss/preview.html Be warned, the format isn't the best, the thumbnails aren't even close to optimized, I only looked at it in one browser, and it might even steal your lunch money. Random notes: - there's lots of great shots not on the thumbnails page - most likely there's a reason, not 800x600, didn't scale well, or I simply overlooked it - you can find all of the screenshots at: http://www.theshell.com/~vinn/ss - the images predominantly are PNG, though there are quite a few JPEGs. No GIF. - Special thanks to: Thomas Wickline Carlos Lozano David Buchmann Guido Grazioli Ender Juliasz Gonera Michael Krasucki Mike Hearn Rick Romero Robert Shade Rory King Tony Lambregts tavis Okay, if you've read this far maybe you're expecting something to prompt discussion. One of the things you'll notice is there's a lot of screenshots on there there almost certainly don't run out of the box. In some instances the folks above listed exactly what they had to do to make it run. Personally, I don't think it matters. We already have the apps DB and the proposed "Gold/Silver/.." apps list, I really don't think we need more than a link to one of those. Also, a few weeks ago there was a lot of discussion of a new WineHQ site. Any progress on that front? -Brian Vincent

Dec. 1, 2002

Re: strcat+strcat+strcat == baaad

by Alexandre Julliard

Shachar Shemesh <wine-devel(a)sun.consumer.org.il> 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 julliard(a)winehq.com

Dec. 1, 2002

Re: "not enough space in GDI heap" / forking vstlib programs

by Uwe Bonnes

>>>>> "Kjetil" == Kjetil S Matheussen <k.s.matheussen(a)notam02.no> writes: Kjetil> Hello, as I just announced I'm developing a vst-server, that Kjetil> loads and runs windows vst plugins. But after loading and Kjetil> unloading a lot of plugins, I get lots of Kjetil> "err:local:LOCAL_GetBlock not enough space in GDI heap 01f7 for Kjetil> 24 bytes" errors. Kjetil> I understand that the cause of this error is caused by a memory Kjetil> leak in a windows program. However, in the vst-server, there is Kjetil> no way to control memory leaks in the plug-ins, as those are Kjetil> made by various groups and persons. Kjetil> So is there a way around this error. Doing a fork for each new Kjetil> plug-in perhaps? Is that safe? I want to do that also to avoid Kjetil> having a plug-in crash the vst-server. Did you get this error with a recent wine version? I hadn't had this errors for some time now. Bye -- Uwe Bonnes bon(a)elektron.ikp.physik.tu-darmstadt.de Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt --------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------

Dec. 1, 2002