March 2006 - Wine-Devel - list.winehq.org

Re: disallow networking flag

by n0dalus

On 3/20/06, rauschenimweltnetz(a)web.de <rauschenimweltnetz(a)web.de> wrote: > > I think it would be very usefull to disallow an application started with wine to connect to the network/internet by an options flag. > > Unless somebody would help me to find out what I have to change... So I would try it by myself. But in consideration of the fact that I need this feature as soon as possible I would better like to just watch and learn... ;) > I don't know how much of wine's source would need to be changed to disallow all network commands, but I know that this kind of thing is possible using iptables (particularly with the owner extension). If you create a new user id (which will be the one you use to start the application, using su or sudo), something like 'nonet', then run the following: iptables -I OUTPUT -m owner --uid-owner nonet -j REJECT --reject-with imcp-net-unreachable or something like that (I haven't tested it), it will block the 'nonet' user and any applications started as it from sending network packets. HTH, n0dalus.

March 20, 2006

disallow networking flag

by rauschenimweltnetz＠web.de

Ahoi! I think it would be very usefull to disallow an application started with wine to connect to the network/internet by an options flag. I'm new to this list and my coding skills are in its fledgling stages. So my part in this whole thing probably would be to watch and learn... :) Unless somebody would help me to find out what I have to change... So I would try it by myself. But in consideration of the fact that I need this feature as soon as possible I would better like to just watch and learn... ;) rauschi ______________________________________________________________ Verschicken Sie romantische, coole und witzige Bilder per SMS! Jetzt bei WEB.DE FreeMail: http://f.web.de/?mc=021193

March 20, 2006

Re: Vitaly Lipatov : gdi32: Look for ttf fonts in the Wine font dir.

by Vitaly Lipatov

В сообщении от 18 марта 2006 21:51 Alexandre Julliard написал(a): > + /* load the system truetype fonts */ > + data_dir = wine_get_data_dir(); > + if (data_dir && (unixname = HeapAlloc(GetProcessHeap(), 0, I did not use if (!data_dir) data_dir = wine_get_build_dir(); also for ttf mixing problem in fonts dir. What about to place source fonts and result (.fon, .ttf) in separate directories in source tree? -- Vitaly Lipatov, ALT Linux Team Russia, Saint-Petersburg, www.etersoft.ru

March 20, 2006

Re: crt0.o versus crtdll.dll etc - suggestions?

by Wesley Parish

Thanks, and my apologies for wasting your time. Wesley Parish Quoting Segin <segin2005(a)gmail.com>: > crt0.o is everything from the program's entry point until main() -- If > the OS doesn't parse arguments in the way main() handles them, the > crt0.o code converts them. Most unix systems have /usr/lib/crt?.o > > crtdll.dll is equilvant to libc.so, and therefore unrelatted > > Wesley Parish wrote: > > >Hi. > > > >I've got some Clipper files I want to translate to C for incorporation > into > >another program, and a program x2c to do the work. > > > >But it asks for crt0.o, which I don't have as such; I'm wondering which > of the > >*crt* files in Wine are most suitable for aliasing or linking as > crt0.o? > > > >Thanks > > > >Wesley Parish > > > >"Sharpened hands are happy hands. > >"Brim the tinfall with mirthful bands" > >- A Deepness in the Sky, Vernor Vinge > > > >"I me. Shape middled me. I would come out into hot!" > >I from the spicy that day was overcasked mockingly - it's a symbol of > the > >other horizon. - emacs : meta x dissociated-press > > > > > > > > > > > > "Sharpened hands are happy hands. "Brim the tinfall with mirthful bands" - A Deepness in the Sky, Vernor Vinge "I me. Shape middled me. I would come out into hot!" I from the spicy that day was overcasked mockingly - it's a symbol of the other horizon. - emacs : meta x dissociated-press

March 20, 2006

Re: Prevent the use of windowsx.h with Wine source.

by Alexandre Julliard

"Martin Fuchs" <martin-fuchs(a)gmx.net> writes: > Just one random example out of the committed Winefile patch: > > - int idx = ListBox_AddString(hlbox, infoStr); > - ListBox_SetItemData(hlbox, idx, pTxt); > + int idx = SendMessage(hlbox, LB_ADDSTRING, 0L, (LPARAM)infoStr); > + SendMessage(hlbox, LB_SETITEMDATA, idx, (LPARAM) pTxt); > > You can't tell us those SendMessage calls are cleaner and more easy to > understand. They contain those ugly (LPARAM) type casts, unused "0L" > wparam parameters and result in longer, less readable code. Not necessarily; the code makes it obvious that we are sending a message here, not calling a function (or worse, a macro disguised as a function). In many cases that's important information, for instance when you try to match a message trace with the code. The casts are ugly but they are present in the macro too, so it isn't any more typesafe, it just looks like it is. -- Alexandre Julliard julliard(a)winehq.org

March 20, 2006

Re: OLEAUT32: bug 4502 - request for comment before trying to fix

by Dan Kegel

On 3/19/06, Dan Kegel <dank(a)kegel.com> wrote: > Alex wrote: > >It seems that I will have to wait until I code > >enough of a test case for a *successful* > >ITypeInfo::Invoke() A few more vaguely relevant notes: http://codeguru.earthweb.com/Cpp/COM-Tech/atl/article.php/c3565/ briefly mentions how ATL uses ITypeInfo::Invoke(). http://www.opengroup.org/onlinepubs/009899899/CHP18GDC.HTM is the Open Group's documentation for ActiveX (!) which also covers this a bit. And, more usefully, http://groups.google.com/group/comp.os.ms-windows.programmer.ole/msg/c1417f… says: 0) Call CoCreateInstance() to get a pointer to the object 1) Create a ITypeLib interface (via the 'LoadTypeLib' API function). 2) Call ITypeLib::GetTypeInfo to obtain ITypeInfo interface. 3) Call ITypeInfo::Invoke (almost like IDispatch::Invoke) which is exactly what I was starting to gather by reading the Automation and Type Libraries chapters of "Essence of COM". - Dan

March 20, 2006

Re: winedbg: add diplay for floating point status

by Jeff Latimer

Thanks for the advice and encouragment. I will be submitting patches again soon. Should the all-regs be invoked at the exception or just the regs? I suppose the FPU errors are rather rare. Jeff Eric Pouech wrote: > Jeff L wrote: > >> This patch adds code to examine the floating point save area in the >> context being examined. For the want of a better place I have in >> included it with the registers area. >> >> Changelog: added code to examine and display floating point uint >> status into be_i386.c > > your patch is definitively needed > > However, I'd rather do it the way gdb does it: > - 'info regs' shows only 'general purpose' and segment registers > - 'info all-regs' shows all the registers (including floating point ones) > > that'd mean adding an extra parameter to all be_???_print_context to > drive this. > > A+

March 20, 2006

Re: Easy applications to write automated tests for?

by Dan Kegel

On 3/19/06, Dan Kegel <dank(a)kegel.com> wrote: > [Let's use Abiword as the app to test, as I proposed long ago:] > http://www.winehq.com/hypermail/wine-users/2001/08/0086.html > Wine wasn't ready for that back then, but it is now; > abiword-2.0.8 works fine under current wine (newer versions > run into http://bugs.winehq.org/show_bug.cgi?id=4887 ). > I'll go check to see if they've got an automated regression test > of their own yet... They don't. So we'd have to write one. Shouldn't be hard to do - either as a cxtest script, or as a C program that sends Windows events and looks at the resulting files abiword creates, or some combination... - Dan -- Wine for Windows ISVs: http://kegel.com/wine/isv

March 20, 2006

Re: Easy applications to write automated tests for?

by Segin

Dan Kegel wrote: >On 3/19/06, Dimi Paun <dimi(a)lattica.com> wrote: > > >>On Sun, 2006-03-19 at 09:09 -0800, Dan Kegel wrote: >> >> >>>I tried [mauve on msys on wine] ... >>> >>> >>I personally think this is a very exciting thing to get right. >>Being able to run an emulation layer like msys/cygwin would >>stress the hell out of the fundamental APIs, and would ensure >>a solid implementation in Wine. Not to mention that: >> -- they are OSS, making debugging a bit easier >> -- they have _lots_ of tests that can be run automatically >> -- said tests could dramatically enhance and broaden the >> available regression tests we have >> >> > >Totally. FWIW, the old, minimal snapshot of cygwin in msys >is probably easier to support than the modern cygwin. (See >http://www.mingw.org/MinGWiki/index.php/mSysFromScratch for >how to build it, if you're interested.) > > > >>Adding to this mix stuff like Java can only extend coverage. >>And we would be tapping into a huge barrage of tests. >> >> > >Yes, it would be an amazing amount of leverage, test-wise. >Having msys working would make a whole new level of >dogfooding possible (e.g. building windows mozilla/firefox >on msys on wine). >- Dan > >-- >Wine for Windows ISVs: http://kegel.com/wine/isv > > > > > Well, that would be good for dogfooding, but so would getting Dev-C++ to work perfectly on Wine -- it uses MingW/gcc to compile.

March 20, 2006

Re: Easy applications to write automated tests for?

by Dan Kegel

On 3/19/06, Segin <segin2005(a)gmail.com> wrote: > ... getting Dev-C++ to work perfectly on Wine [would be good > for dogfooding] -- it uses MingW/gcc to compile. Sure, good idea. I encourage Dev-C++ users to test it with Wine and file bug reports at http://bugs.winehq.org for any problems they find. I just looked, and only found one report, http://bugs.winehq.org/show_bug.cgi?id=4483 which was really fixed already by wine-0.9.7. In my own test of dev-c++, it looks like there are a few small cosmetic problems. I didn't try it on any real apps, though. I'll let IDE users do that. - Dan -- Wine for Windows ISVs: http://kegel.com/wine/isv

March 20, 2006

Fwd: Regression: new systray implementation ... - analysis, demo, etc.

by qingdoa daoo

http://bugs.winehq.org/show_bug.cgi?id=4853 --------------------------------- Yahoo! Mail Use Photomail to share photos without annoying attachments.

March 20, 2006

function counting script, memcheck.sh

by Segin

Attached is version 0.2 of this script, with a lot of additional functionality. You will need to be able to write to /tmp and make a file /tmp/grep to use the extended functionality (default functionality needs none of that, and is unmodified.) For those that are intested, you can fetch memcheck.sh from my project CVS tree: cvs -d:pserver:anonymous(a)cvs.sourceforge.net:/cvsroot/overdose login (when propted for a password, simply push enter) cvs -z3 -d:pserver:anonymous(a)cvs.sourceforge.net:/cvsroot/overdose co overdose You'll find the memcheck.sh script in the CVS checkout. Could someone tell me how to checkout just a single CVS file? Anyways, there's the docs, which you should read (failure to do so will get a reply of RTFM): ----------------------------------8<--------------------------------- memcheck.sh version 0.2 documentation To change the functions searched for, edit the file's top line. make sure all functions are space seperated and in quotes, to search for recv() and send() make sure that top line looks like this: FUNCTIONS="recv send"; Three are 2 command line arguments supported, they must be the only argument and verbatim to work, yada yada. -l List the line number with a code sample -C Like above, but with context. You need write access to /tmp to create, read, write and destroy files. Your grep implementation needs to be GNU grep or you need to edit the script. Most systems have given up using their own grep for GNU grep cause GNU grep kicks ass. ----------------------------------8<---------------------------------

March 20, 2006

GoogleEarth

by James Courtier-Dutton

Hi, Can one run GoogleEarth under wine? It does not seem to run here under the default settings. James

March 19, 2006

Re: rpaths not working?

by Mike Hearn

On Sat, 2006-03-18 at 10:55 +0100, Alexandre Julliard wrote: > AFAIK the rpath of the main binary is supposed to apply to > dependencies too, not sure why it doesn't in your case. What libc > version is that? This is glibc 2.4 - time to consult the ELF specs I think ...

March 19, 2006

OLEAUT32: bug 4502 - request for comment before trying to fix

by Dan Kegel

Alex wrote: >It seems that I will have to wait until I code >enough of a test case for a *successful* ITypeInfo::Invoke() (there are >two tests of failing calls, but none of a successful one) I'm a complete COM newbie, but I've been reading "The Essence of COM" lately for entertainment; it almost describes that call. (FWIW, the example code for the book is at http://www.rollthunder.com/Books/OldBooksFrame.htm.) I went poking around online looking for examples of that call in C, and only found two :-( http://viewcvs.php.net/viewcvs.cgi/php-src/ext/com_dotnet/com_com.c http://dev.eclipse.org/viewcvs/index.cgi/org.eclipse.ercp/org.eclipse.ercp.… I also found a muddled discussion here: http://www.codeproject.com/atl/multidisp.asp Good luck writing that test case! - Dan -- Wine for Windows ISVs: http://kegel.com/wine/isv

March 19, 2006

Re: Prevent the use of windowsx.h with Wine source.

by Martin Fuchs

2006/3/19, Alexandre Julliard <julliard(a)winehq.org>: > I think these windowsx macros are confusing things more than helping, > especially since they don't look like macros. It's better to have > explicit SendMessage calls than some pseudo function calls, it makes > much more obvious what's going on, especially for people who try to > debug the code without being very familiar with the Windows API. The > fact that getting rid of the macros also avoids the warnings is just > icing on the cake. Just one random example out of the committed Winefile patch: - int idx = ListBox_AddString(hlbox, infoStr); - ListBox_SetItemData(hlbox, idx, pTxt); + int idx = SendMessage(hlbox, LB_ADDSTRING, 0L, (LPARAM)infoStr); + SendMessage(hlbox, LB_SETITEMDATA, idx, (LPARAM) pTxt); You can't tell us those SendMessage calls are cleaner and more easy to understand. They contain those ugly (LPARAM) type casts, unused "0L" wparam parameters and result in longer, less readable code. Regards, Martin

March 19, 2006

Re: Easy applications to write automated tests for?

by Dan Kegel

On 3/19/06, Dimi Paun <dimi(a)lattica.com> wrote: > On Sun, 2006-03-19 at 09:09 -0800, Dan Kegel wrote: > > I tried [mauve on msys on wine] ... > > I personally think this is a very exciting thing to get right. > Being able to run an emulation layer like msys/cygwin would > stress the hell out of the fundamental APIs, and would ensure > a solid implementation in Wine. Not to mention that: > -- they are OSS, making debugging a bit easier > -- they have _lots_ of tests that can be run automatically > -- said tests could dramatically enhance and broaden the > available regression tests we have Totally. FWIW, the old, minimal snapshot of cygwin in msys is probably easier to support than the modern cygwin. (See http://www.mingw.org/MinGWiki/index.php/mSysFromScratch for how to build it, if you're interested.) > Adding to this mix stuff like Java can only extend coverage. > And we would be tapping into a huge barrage of tests. Yes, it would be an amazing amount of leverage, test-wise. Having msys working would make a whole new level of dogfooding possible (e.g. building windows mozilla/firefox on msys on wine). - Dan -- Wine for Windows ISVs: http://kegel.com/wine/isv

March 19, 2006

Re: opengl32: make the old code before the "sync the dibsection to its pixmap" patch be selectable at runtime

by Lionel Ulmer

On Fri, Mar 17, 2006 at 11:47:14AM +0000, Mike Hearn wrote: > There's a new patch to try here: > > http://plan99.net/~mike/files/glteb.patch > > Does that work any better? Well, to make this work better, one would need a two-tiered approach: = use thread-local variables to check if it's a 'special' buffer or not (like this patch does) = only do this check on GL APIs that actually modify or read from the frame buffer (basically stuff like glClear, glEnd, gl(Read|Write)Buffer, ...). The last is easy to do for 'core' stuff, a bit harder for extensions though. But anyway, this is mandatory if one day we want to fix the 'windowed' OpenGL code properly (whatever the method we choose as long as we do not have the GLX extension exporting the clip list feature to the application). Lionel -- Lionel Ulmer - http://www.bbrox.org/

March 19, 2006

Re: Function counting script

by Segin

Jim White wrote: > Joris Huizer wrote: > >> Segin wrote: >> >>> It's not a C interpeter, it's literally a frint end of sorts to >>> grep. There's only one textual occurence of malloc() in the code, so >>> it only returns one. >>> >>> Think before you speak. >>> >>> P.S. I'll add a C interpeter when there becomes a need for one. >>> >> >> It was my impression that the goal was to find leaks by counting >> allocating and freeing of memory; >> My example was about that: the counts do not have to indicate correct >> usage of malloc()/free() >> Sorry if this was an incorrect assumption > > > Right. And by reading the code that is doing alloc/free you can > determine if they are balanaced. But first you have to *find* where > those calls are made. > > Jim > > > > This gives me an idea: I can add a command line flag to determine how to invoke grep (e.g. just a count, or a count plus occurences by line)

March 19, 2006

Re: Function counting script

by Segin

That's ok, I failed to document that myself. In truth, it would truthfully be inpossible to find run-time memory leaks like that using a script because of a potential unknown variable in a for loop which is derived from an argument or return from another function. I will try to add code for detecting contant for loops at one point. Also, the script is designed to be edited and whatever function you want to look for inserted into the code. Joris Huizer wrote: > Segin wrote: > >> It's not a C interpeter, it's literally a frint end of sorts to grep. >> There's only one textual occurence of malloc() in the code, so it >> only returns one. >> >> Think before you speak. >> >> P.S. I'll add a C interpeter when there becomes a need for one. >> > > It was my impression that the goal was to find leaks by counting > allocating and freeing of memory; > My example was about that: the counts do not have to indicate correct > usage of malloc()/free() > Sorry if this was an incorrect assumption > > regards, > > Joris > > >

March 19, 2006

Re: crt0.o versus crtdll.dll etc - suggestions?

by Segin

crt0.o is everything from the program's entry point until main() -- If the OS doesn't parse arguments in the way main() handles them, the crt0.o code converts them. Most unix systems have /usr/lib/crt?.o crtdll.dll is equilvant to libc.so, and therefore unrelatted Wesley Parish wrote: >Hi. > >I've got some Clipper files I want to translate to C for incorporation into >another program, and a program x2c to do the work. > >But it asks for crt0.o, which I don't have as such; I'm wondering which of the >*crt* files in Wine are most suitable for aliasing or linking as crt0.o? > >Thanks > >Wesley Parish > >"Sharpened hands are happy hands. >"Brim the tinfall with mirthful bands" >- A Deepness in the Sky, Vernor Vinge > >"I me. Shape middled me. I would come out into hot!" >I from the spicy that day was overcasked mockingly - it's a symbol of the >other horizon. - emacs : meta x dissociated-press > > > > >

March 19, 2006

Re: Function counting script

by Jim White

Joris Huizer wrote: > Segin wrote: > >> It's not a C interpeter, it's literally a frint end of sorts to grep. >> There's only one textual occurence of malloc() in the code, so it only >> returns one. >> >> Think before you speak. >> >> P.S. I'll add a C interpeter when there becomes a need for one. >> > > It was my impression that the goal was to find leaks by counting > allocating and freeing of memory; > My example was about that: the counts do not have to indicate correct > usage of malloc()/free() > Sorry if this was an incorrect assumption Right. And by reading the code that is doing alloc/free you can determine if they are balanaced. But first you have to *find* where those calls are made. Jim

March 19, 2006

Re: Prevent the use of windowsx.h with Wine source.

by Alexandre Julliard

Robert Shearman <rob(a)codeweavers.com> writes: > It seemed to be ignored by both you and Alexandre last time it was > sent, and all of your patches applied anyway despite objections from > several developers. I think these windowsx macros are confusing things more than helping, especially since they don't look like macros. It's better to have explicit SendMessage calls than some pseudo function calls, it makes much more obvious what's going on, especially for people who try to debug the code without being very familiar with the Windows API. The fact that getting rid of the macros also avoids the warnings is just icing on the cake. -- Alexandre Julliard julliard(a)winehq.org

March 19, 2006

Re: Easy applications to write automated tests for?

by Dimi Paun

On Sun, 2006-03-19 at 09:09 -0800, Dan Kegel wrote: > OK, I looked. It has a big configure script. > I tried running it under msys on wine, but that > failed miserably. So I guess it's not easy, offhand > (big surprise). I suppose there might be other ways > to run parts of the mauve test suite on wine, but I'll pass for now. I personally think this is a very exciting thing to get right. Being able to run an emulation layer like msys/cygwin would stress the hell out of the fundamental APIs, and would ensure a solid implementation in Wine. Not to mention that: -- they are OSS, making debugging a bit easier -- they have _lots_ of tests that can be run automatically -- said tests could dramatically enhance and broaden the available regression tests we have Adding to this mix stuff like Java can only extend coverage. And we would be tapping into a huge barrage of tests. -- Dimi Paun <dimi(a)lattica.com> Lattica, Inc.

March 19, 2006

Re: How hard would it be to support Java?

by Dan Kegel

On 3/19/06, Ulrich Czekalla <ulrich.czekalla(a)utoronto.ca> wrote: > > So I played around a bit with Sun's latest 1.5 JRE. > > ... it can't run applets; first, it runs into a nasty glx error, > > http://bugs.winehq.org/show_bug.cgi?id=4143 > > As a work-around you can try to force it to use gdi. Turn off ddraw. I > think their is a jvm parameter for this, can't quite recall. Good call. -Dsun.java2d.noddraw=true does the trick, and lets you get to the more serious error. - Dan -- Wine for Windows ISVs: http://kegel.com/wine/isv

March 19, 2006