wine-devel December 2002

wine-devel@winehq.org

132 participants
377 discussions

RE: strcat+strcat+strcat == baaad"
by vkxzjq6lg＠cswebmail.com 06 Dec '02

06 Dec '02

> -----Original Message----- > From: wine-devel-admin(a)winehq.com > [mailto:wine-devel-admin@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. You're right in theory but you're partly wrong in practice. Some time back I changed a shared library which had been used by ten or so developers for about eight years. I changed all possible unspecified length string copies and concatenates to versions with length limits. The programs using the library crashed less and displayed bad output less. Nobody noticed any speed change there might have been. We all had access to all of the source code involved and none of it was deliberately hostile to the library. The changes caught things the application programmers had missed in their testing and odd or corrupt data which ended up in the databases and made them less harmful. It was then also easier to follow up and fix "the program displayed xyz trash here" than it was to fix "my PC crashed" or "your program died". As programmers we all try to follow the limits and take care with buffer sizes and lengths and validation. We all fail and we all fail to catch every time we fail. That's just the nature of bugs and what we do. Buffer length issues are particularly hard to find and no realistic testing for a project the size of wine will catch them all. Wine also needs to remember that hostile Windows program developers may deliberately try to break programs under wine by passing invalid parameters. Even if wine doesn't check all of those, it shouldn't die when it happens. At least one company has an interest in breaking wine when running its programs and coding defensively is a prudent thing. Performance is unknown and won't be known until any possible shared function is implemented. Just announce it with the length parameter and do it with a define. Let the person who implements it decide whether to use strcat, strlcat or whatever in the first implementation, a function or inline or whatever. Six months or a year from now someone can try different implementations to see whether there is a speed difference. Then they can do something about selecting the most efficient. It's an issue, so deal with it, but there's no way to know today which will be the best implementation because it depends on the data and it is obvious that nobody knows the data well enough to be certain which will work best. If you don't like the strlcat implementeation, then you can try it with strcat and tell everyone how much faster it is when the l is ignored. Or not. Even if the l is eventually ignored in production, having it around offers the opportunity to turn it on with a compile option and/or to use it for assert sanity checking in a debug build. Finally, hi.:) Just started monitoring this list because I'm helping to get a Windows application (OzWin) working under wine. James Day ___________________________________________________ The ALL NEW CS2000 from CompuServe Better! Faster! More Powerful! 250 FREE hours! Sign-on Now! http://www.compuserve.com/trycsrv/cs2000/webmail/

3 2

Registering DLL's
by Jeff Smith 06 Dec '02

06 Dec '02

I was looking at entry C.5 of the 0.9 Todo list: "Make Wine's DLLs register themselves to avoid manual merging of the winedefault.reg [TODO]" Upon first glance I figured the approach is to (not necissarily in this order): add regsvr32.exe calls in the installation scripts, fill in the DllRegisterServer (and DllUnregisterServer) sections of the appropriate libraries, and remove those entries from winedefault.reg. About a dozen dll files have their names in winedefault.reg. So I checked the native versions of these files, and only half of them have a DllRegisterServer function. I did some further research and found that perhaps DllInstall was what I needed. Well, that only adds one library, and two have *both* functions. Does anyone have any better ideas on what the "Right Way" to tackle this item is? I am sure that adding external functions that do not exist in native versions is *not* the way. -- Jeff S _________________________________________________________________ Add photos to your e-mail with MSN 8. Get 2 months FREE*. http://join.msn.com/?page=features/featuredemail

4 4

Cabinet FDICreate()
by Mike Hearn 06 Dec '02

06 Dec '02

Hi, The MSXML4 .msi package dies with : fixme:cabinet:FDICreate (0x525bee, 0x525bf3, 0x52668d, 0x525e99, 0x525bf8, 0x525fb9, 0x526042, -1, 0x54a2a8): stub Is this scheduled to be implemented as part of the cabinet merge in work? thanks -mike -- Mike Hearn <m.hearn(a)signal.qinetiq.com> QinetiQ - Malvern Technology Center

1 0

Re: wine/tools Makefile.in .cvsignore mingwrap.c
by Dimitrie O. Paun 06 Dec '02

06 Dec '02

On December 5, 2002 02:12 pm, Alexandre Julliard wrote: > ChangeSet ID: 6503 > CVSROOT: /opt/cvs-commit > Module name: wine > Changes by: julliard(a)wine.codeweavers.com 2002/12/05 13:12:13 > > Modified files: > tools : Makefile.in .cvsignore > Added files: > tools : mingwrap.c > > Log message: > Dimitrie O. Paun <dpaun(a)rogers.com> > New MinGW wrapper that makes gcc on Linux behave like MinGW on > Windows, using the Wine headers. I'm afraid this (from Makefile.in) can't quite work: mingwrap: mingwrap.o $(CC) $(CFLAGS) -DINCLUDEDIR="$(includedir)" -o mingwrap mingwrap.o You're passing the -D to an already compiled file... -- Dimi.

1 0

Re: Loading Autorun.inf on CD's
by Dustin Navea 06 Dec '02

06 Dec '02

----- Original Message ----- From: "Dustin Navea" <speeddymon(a)sbcglobal.net> To: "Wine Developers" <wine-devel(a)winehq.com> Sent: Thursday, December 05, 2002 11:37 PM Subject: Loading Autorun.inf on CD's > Hey guys, > > I was browsing through the forums on franksworld.net and noticed this post: > > http://www.frankscorner.org/wineforum/viewthread.php?tid=158 > > Now that got me thinking, wine doesnt have any method to check .inf files > right now and load an installer if it finds one on a CD. I was wondering, > what do you guys think it would take to get that supported? I know that we > would probably have to associate .inf files with wine and/or have some sort > of a wine cd detector that actively monitors cd's for autorun files, but > what would need to be added to wine itself to parse an autorun file, so that > we could create the loader later? > > -Dustin > I just thought of one thing we could do.. I bet we could make a bash script that gets called by wine (is that possible) that parses the config to check the cd path first and then checks the cd path for any autorun files, if one exists, it parses it and loads up the correct binary. Now, if that isnt a good idea, or someone thinks we should do it in the code, feel free to flame me. We still would have to have an active monitoring program though that watches for cd's to be inserted and then that calls up the script, but we could always ask the autofs guys if they would be willing to add wine load support for inf files to their perl scripts, so that if a user has autofs installed, it uses wine.. --Dustin P.S. Call me crazy if you want to, but it was just an idea..

1 0

[Alsa] A simple test for IDirectSound.GetCaps.
by Sylvain Petreolle 06 Dec '02

06 Dec '02

Running the dsound test using winealsa.drv, the program hangs and try to call the debugger. [syl@snoop dsound]$ make test make[1]: Entre dans le répertoire `/home/wine/dlls/dsound/tests' ../../../tools/runtest -q -P wine -M dsound.dll -T ../../.. -p dsound_test.exe.so dsound.c && touch dsound.ok err:ntdll:RtlpWaitForCriticalSection section 0x400ec230 "../../loader/module.c: loader_section" wait timed out, retrying (60 sec) tid=0876cdc8 wine: Unhandled exception, starting debugger... err:ntdll:RtlpWaitForCriticalSection section 0x400ec230 "../../loader/module.c: loader_section" wait timed out, retrying (60 sec) tid=0876cdc8 err:seh:EXC_DefaultHandling Unhandled exception code c0000194 flags 0 addr 0x400bb478 make[1]: Quitte le répertoire `/home/wine/dlls/dsound/tests' According to http://www.delphifaq.com/fq/q1061.shtml, exception c0000194 is STATUS_POSSIBLE_DEADLOCK. How could I debug the tests ? ===== Sylvain Petreolle spetreolle(a)users.sourceforge.net Fight against Spam ! http://www.euro.cauce.org/en/index.html ICQ #170597259 "Don't think you are. Know you are." Morpheus in Matrix, chapter 15. ___________________________________________________________ Soyez solidaire soutenez laction du Téléthon avec Yahoo! France. http://www1.telethon.fr/030-Espace-Relais-Dons/webtirelire1.asp?hebergeur_i…

1 0

WineBuild/WineLib <-> MFC
by jaymz＠free.fr 05 Dec '02

05 Dec '02

Going further into the MFC dll handling, I raised the following issue: I have two dynamic libs (mfc.dll.so and myapp.dll.so), both loaded by the wrapper (myapp.exe.so). The problem is that global or static class variables are badly exported from mfc.dll.so to myapp.dll.so. Here's an example: In mfc.dll.so, let assume that I export a global integer variable named myVar. I add @ extern myVar myVar in mfc.dll.spec. When I do a GetProcAddress of myVar from the wrapper, the returned address is good, but when I link my application, myVar is undefined (WineBuild did not include it in myapp.dll.spec.c). If I add instead in the spec file something like @ stdcall myVar() myVar, it's still good when using GetProcAdress, I can now link my application, but at runtime, the address of the variable is not the good one, so I'm using corrupted data ! Therefore, when the app runs, all static data are in fact not or badly initialized and it crashes. What's the exact syntact to correctly export class static variable from a dll ? Thanks a lot for your attention.

2 1

[RFC] wrc & windres
by Dimitrie O. Paun 05 Dec '02

05 Dec '02

Hi folks, As we discussed here a few weeks ago, there is good reason to have a windres compatible mode for wrc. Needless to say, this will greatly ease porting apps that use windres to Winelib. More information about the issues at hand can be found in this thread: http://www.winehq.com/hypermail/wine-devel/2002/11/index.html#1518 These messages in particular deal with this problem: http://www.winehq.com/hypermail/wine-devel/2002/11/1546.html http://www.winehq.com/hypermail/wine-devel/2002/11/1550.html http://www.winehq.com/hypermail/wine-devel/2002/11/1551.html http://www.winehq.com/hypermail/wine-devel/2002/11/1552.html http://www.winehq.com/hypermail/wine-devel/2002/11/1555.html That being said, what would it take to (1) keep the current wrc behavior, and (2) make it compatible with windres? First, windres supports any conversions between .rc, .res, .o files, whereas wrc supports only .rc -> .res. It would be interesting (from the Winelib point of view) to also support .rc and .res -> .o. The other transformations supported by windres (.o -> .res -> .rc) are not as interesting, as they are not used in the build process. With that in mind, what do we need to do to have said compatibility? Well there are two things: 1. Support windres command line options 2. Add conversion of .rc and .res to .o I will treat each of these below. Command line compatibility -------------------------- Luckily, there is only one (seldom used) option that conflicts: -I. Moreover, it has a long format name in windres as well, which can be used instead. In other words, it should be very simple to add support for the windres options to wrc (most of them will just get ignored). In other words we can support windres's options while keeping full backwords compatibility. Having this compatibility makes sense as long as we support the conversion to .o files as well. Assuming we can do that, I would say this is something we should have. Conversion to .o files ---------------------- As Alexandre pointed out in here: http://www.winehq.com/hypermail/wine-devel/2002/11/1550.html generating .o files in proper format is non-trivial. And since I'm willing to do the work, there's no chance I'm going to propose something difficult to implement! :) What I have in mind is quite simple: store the .res file, as a byte array, in a .wine.resources ELF section, and have winebuild pick it up from there (as an alternative to getting it directly from the .res file, so current behavior is conserved). With these two changes, we eliminate the biggest nastiness of getting apps compiled with Winelib. The modification will typically be: -WINDRES=windres +WINDRES=wrc Moreover, the solution is: o Simple to implement o Fully backwards compatible with current Wine practice o Fully compatible with Win32 apps using the MinGW toolchain o Supports multiple resource files, etc. So now the big question: Alexandre, are patches that implement these ideas acceptable? Sorry for the long message, and thanks for reading this far. -- Dimi.

3 6

Re: [RFC] wrc & windres
by Jeff Smith 05 Dec '02

05 Dec '02

>From: "Dimitrie O. Paun" <dpaun(a)rogers.com> >Hi folks, > >As we discussed here a few weeks ago, there is good reason >to have a windres compatible mode for wrc. <snip> >That being said, what would it take to (1) keep the current wrc >behavior, and (2) make it compatible with windres? Here is an alternative idea for dealing with command-line incompatibility: create a link 'windres' pointing to 'wrc'. In the program, we could determine how the program was invoked and handle the command-line options accordingly. This should technically work, unless we find some reason to 'mix' command line options, in which case we we would have to start 'blending' the two syntaxes. Please note that I am not familiar with the command line options of either program. <snip> >The modification will typically be: >-WINDRES=windres >+WINDRES=wrc WINDRES would not have to be changed using this method. -- Jeff S. _________________________________________________________________ The new MSN 8: smart spam protection and 2 months FREE* http://join.msn.com/?page=features/junkmail

3 2

Re: possible memory corruption
by steve.lustbader＠philips.com 05 Dec '02

05 Dec '02

>>>>>> "steve" == steve lustbader <steve.lustbader(a)philips.com> writes: > > steve> When I try to load a window in my app that has a treeview in it, > steve> it crashes immediately, before the window even gets displayed. > steve> This is the end of the backtrace: > > Try running with native commctrl to see if the corruption comes from our > commctrl implementation. Then run with --debugmsg +relay,+heap. Wine will > check on every heap manipulation to see if the heap is still okay. Then >look what corrupted the heap. It works fine with a native (WinXP) comctl32.dll. I'll post the +relay,+heap output shortly. -Steve

1 0

← Newer
1
...
29
30
31
32
33
34
35
...
38
Older →

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

wine-devel December 2002