August 2004 - Wine-Devel - list.winehq.org

Re: E-mail adress

by Shachar Shemesh

Mike Hearn wrote: > A better technique is to the CSS unicode bi-di attributes to convert > > Mike Hearn <xc.ivan(a)ekim> > > in the webpage to > > Mike Hearn <mike(a)navi.cx> > > in the rendered image the browser shows you. I came across this trick > the other day and it's pretty neat. Boring old techniques like > "username at host" are apparently useless against modern harvester > bots, so maybe it's worth doing this. Wow. You'd expect me to think of that one...... Still, that does not allow easy copy&paste, and it has unpleasant effect on web sites that actually USE bidi. Also, in order to be really effective, you would need to use RLO (else the strong directionality of the English letters would still make it left to right), and I'm not sure how widespread a support this has. Worst, this doesn't work for automatic clicks. A better approach, in my humble opinion, is to use javascript. A simple method is visible in my site (a simple script that reorders the words, so that they do not appear as a full name anywhere unless you understand javascript). A more complex method is to RSA encode the email using a 15 bit key that is hard-wired into the decoding javascript. This method is impossible to work around without actually running a javascript engine on the harvester, which would open them to all sorts of fun abuse by us. :-) Shachar -- Shachar Shemesh Lingnu Open Source Consulting ltd. http://www.lingnu.com/

Aug. 31, 2004

Re: Binary relocatability part 1

by Alexandre Julliard

Mike Hearn <mike(a)navi.cx> writes: > +dnl This is used for binary relocatability > +if echo $libdir | grep '^\${exec_prefix}' >/dev/null; then > + RPATH="-Wl,-rpath,'\$\${ORIGIN}/..'`echo $libdir | sed 's/\${exec_prefix}//'`" > +fi This is still making assumptions about the contents of bindir and libdir. What you need is a generic way to find a relative path from any directory to any other. Also this needs to be done at make time, not in configure. -- Alexandre Julliard julliard(a)winehq.org

Aug. 31, 2004

Re: W->A calls

by James Hawkins

> However, I don't know how to make simple tests.. as I'd really need to > test wether the code I write works, and works properly :p The best way to test the functionality of a certain api function against windows is to read the msdn docs on that function. There are certain easy things to check like the error codes that are either returned or set using SetLastError (and are read using GetLastError.) The docs will also tell you pretty precisely what the function should and should not do, and you write the tests to make sure that the functions do what they're supposed to do. A lot of the times, msdn docs will have example code and will usually show the expected output (when necessary.) You can test against this output to see if the results are the same. Some api's cant really be tested with wine's testing system because the effects may be visual etc, so the way to test that is to run the program and see if the visual change coincides with the way the program runs in windows. If you dont have a windows install to run the program from, I'm sure that someone on wine-devel can run the program for you. On Tue, 31 Aug 2004 11:10:57 +0200, Joris Huizer <jorishuizer(a)planet.nl> wrote: > Hello, > > By accident, I removed the emails of the thread I started, but I'll look > it up if necessary; > I found this old wine issue of some time ago.. I think the patch it has > there could be helpfull > > http://winehq.org/?issue=229#About%20Converting%20W-%3EA%20Calls > > However, I don't know how to make simple tests.. as I'd really need to > test wether the code I write works, and works properly :p > > How do I write tests for that? I'm running linux (in practice, I never > boot into windows) so how should I do this (testing without windows > environment)? How are tests supposed to run? > > I hope you can give some clues on that; I found there are many W->A > calls in dlls/winmm/winmm.c (according to the janitorial page) so I > might start there (hoping not all of them are so tricky ;) ) > > Thanks for suggestions on this, > > Joris > > -- James Hawkins

Aug. 31, 2004

Re: Set last error values compatible with Win9x implementation of GetFileVersionInfoSize

by Dmitry Timoshkov

"Uwe Bonnes" <bon(a)elektron.ikp.physik.tu-darmstadt.de> wrote: > A test programm for our test suite will easily show (and document) that > behaviour. A test is already there (dlls/version/tests/info.c) and pretty much shows the desired behaviour. -- Dmitry.

Aug. 31, 2004

Re: [ck] Re: Threading issues? [ck-request@vds.kolivas.org: ck Digest, Vol 3, Issue 16]

by Mike Hearn

>>Other solution is just to detect this and ask the user to rerun Wine as >>root. I don't think that'd be a big deal. > > > But then that brings up the issue of users not being able to run wine > merely because they don't have root access, i.e. users on a Linux system > in a business environment, or remote X/telnet access on a server with > wine (for various reasons). These people probably wouldn't be running scheduling sensitive tasks. > The idea of having to run under root was one of the ones why people > avoid SVGAlib nowadays, and setuid/root will be a deep security risk > considering what kind of apps we're looking at here. If we say, run > notepad, we have a root editor application -- capable of messing with > config files on the Linux setup -- something that the Linux admin might > not want. You can make Wine suid root and then sandbox it back down to standard user level privs + scheduling using SELinux, so it'd only be a security "problem" for a short while. Given that we know of no Windows apps self-aware enough to escape the emulation I don't even see what security problems it can cause on home machines where the user has root access anyway. I guess if you got owned via Internet Explorer or something it would give attackers access to your configuration files but the chances of this happening and being taken advantage of are tiny. > If this is implemented, shouldn't this be a warning, not a forced thing? > So that a normal user could (try and) run wine without root access? And > I presume that this would be 2.6 specific detection - otherwise, there's > not really a need (since Wine worked OK under 2.4 and such). We could > say something like: "Wine has dectected that you are running Wine as a > normal user under Linux kernel 2.6+. Due to changes in the scheduling > mechanism in 2.6, which includes preempting and a change in the way > process priorities are handled, Wine may not work properly, or different > parts may work at different speeds, causing desyncronization of your > application and/or it's components. You are suggested to <(run wine as > root) or (downgrade and use a (2.4 kernel) AND/OR <supported kernels > list>) or (list other workaround information)>." Well, ideally it'd be only displayed when we detected a mismatch between the apps requirements and the underlying kernel scheduling. Which may not even exist: we haven't *proven* anything yet, just thrown theories around. Unfortunately the people most qualified to diagnose the problem are all as much in the dark as we are :( Random point: the wording of that warning is terrible I'm afraid :) There's no way we could ever throw such a complex message in the users face, nobody would understand it! A much better way to word such a message would be: "In order for this program to run correctly, you must run Wine with root priviledges. The program will proceed but you may notice audio stuttering or performance problems." Even that's not ideal. It requires the user to: a) Understand the concept of root == administrator user that should not normally be used, which is a non obvious mapping. It's one of those things you just "have to know", and we're trying to cut the number of these things as much as possible. b) Understand what Wine is - obviously we can't get away from this entirely but long term I'd like to see Wine become just another Linux subsystem that does its job so well the user doesn't ever notice it c) Understand *how* to run Wine with root privs. If you just su to root and run it, you can't start your app as you're now running with a different virtual Windows drive and registry. It's really not obvious how to do this even for experienced Linux users (answer, set WINEPREFIX) Anyway. That's todays usability lecture over with :) > I presume that if someone wanted to get started writing a patch now > using any one of these ideas, then we could just test it and see how it > does among us, and then if it's okay, submit it, get it through CVS, see > what happens, get it through a release if that happens, and then we can > finish this debate only when performance issues or something else needs > to be done about this. I think we should get a much clearer idea of what's going wrong here first before trying to write patches or get code into CVS. thanks -mike

Aug. 31, 2004

Re: Set last error values compatible with Win9x implementation of GetFileVersionInfoSize

by Uwe Bonnes

>>>>> "Dmitry" == Dmitry Timoshkov <dmitry(a)baikal.ru> writes: Dmitry> Hello, installer of Quicken depends on last error values set by Dmitry> GetFileVersionInfoSize and expects them to be set to something Dmitry> different than ERROR_RESOURCE_DATA_NOT_FOUND set on NT Dmitry> platforms. Dmitry> I hope that there is no need to introduce several code paths Dmitry> depending on the GetVersion return value. A test programm for our test suite will easily show (and document) that behaviour. Bye -- Uwe Bonnes bon(a)elektron.ikp.physik.tu-darmstadt.de Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt --------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------

Aug. 31, 2004

Re: more debugger issues

by Chipzz

Sorry for the late reply, but I was out of town for the weekend. Anyway, it fails to compile: Vector:/usr/src/wine/wine-0.0.20040615/dlls/dbghelp# make gcc -c -I. -I. -I../../include -I../../include -D__WINESRC__ -D_REENTRANT -fPIC -Wall -pipe -mpreferred-stack-boundary=2 -fno-strict-aliasing -gstabs+ -Wpointer-arith -O2 -g -o msc.o msc.c msc.c: In function `pe_load_debug_directory': msc.c:3049: warning: implicit declaration of function `DEBUG_Printf' ../../tools/winegcc/winegcc -B../../tools/winebuild -shared ./dbghelp.spec dbghelp.o elf_module.o image.o memory.o minidump.o module.o msc.o path.o pe_module.o source.o stabs.o stack.o storage.o symbol.o type.o dbghelp.dll.dbg.o -o dbghelp.dll.so -L../../dlls -lpsapi -lkernel32 -lntdll -L../../libs/wine -lwine -L../../libs/port -lwine_port msc.o(.text+0x4256): In function `pe_load_debug_directory': /usr/src/wine/wine-0.0.20040615/dlls/dbghelp/msc.c:3049: undefined reference to `DEBUG_Printf' collect2: ld returned 1 exit status winegcc: gcc failed. make: *** [dbghelp.dll.so] Error 2 (Don't look at the date in the directory, it actually is the cvs version as of 2004/08/26) I only changed the #if on line 3042. Anything else I need to change (or update to latest CVS)? On Fri, 27 Aug 2004, Eric Pouech wrote: > Chipzz a écrit : > > Hi all! > > > > As a saw a few updates to the debugger a couple of days ago, I decided > > to give the debugger another go. The problem with the stack trace is > > gone now, but now I get another problem when I attach to a running > > process, set a breakpoint and continue, the program crashes. When I in- > > stead don't set a breakpoint and continue, the program keeps running > > "fine": > > > > When setting the breakpoint: > > [...] > > 10 0x408d9351 MsgWaitForMultipleObjects+0x41 in user32 (0x423bd148) > > 11 0x4163b91a (0x40915980) > this looks bad as a backtrace (the bp -in parenthesis- goes south). It > could dbghelp not supporting modules with FPO (frame pointer omission). > If you recompile wine, could you change the #if 0 in dlls/dbghelp/msc.c > in function pe_load_debug_directory into a #if 1, and see what gives. > Afterwards, the stack lookup goes wrong, hence the 16 bit addresses. > > I'm don't know what goes wrong afterwards after setting the breakpoint > or not. Even the issues from above shouldn't impact the debuggee. > > > Also, ctrl-c doesn't work to stop the program being debugged. > > Wien version is wine CVS Aug 23. > I'm working on it. > > A+ kr, Chipzz AKA Jan Van Buggenhout -- ------------------------------------------------------------------------ UNIX isn't dead - It just smells funny Chipzz(a)ULYSSIS.Org ------------------------------------------------------------------------ "Baldric, you wouldn't recognize a subtle plan if it painted itself pur- ple and danced naked on a harpsicord singing 'subtle plans are here a- gain'."

Aug. 31, 2004

Re: [ck] Re: Threading issues? [ck-request@vds.kolivas.org: ck Digest, Vol 3, Issue 16]

by michael＠cherryblossom.homelinux.com

On Tue, Aug 31, 2004 at 10:54:46AM +0100, Mike Hearn wrote: Hmm, so I suppose the idea of getting all wine processes nice 19 and then doing something internally to manage win's prios when it gets the CPU is out of the question, right? It's an issue of performance vs. performance -- performance with syncronization and running priorities like Windows, and performace as in running as fast and efficcently as possible. > >2) After you've reduced a thread or process's priority, it's not > >possible to elevate it to the original level again (without being root), > >so if a thread is set to low priority temporarily, it won't be possible > >to restore it to normal priority under Linux. Under Windows it's of > >course possible. Hmm... and reinventing the wheel would be redundant, of course, I presume? Like having a sort of sub scheduler, that does Windows/Wine scheduling, within Wine, which is then scheduled in Linux? > Other solution is just to detect this and ask the user to rerun Wine as > root. I don't think that'd be a big deal. But then that brings up the issue of users not being able to run wine merely because they don't have root access, i.e. users on a Linux system in a business environment, or remote X/telnet access on a server with wine (for various reasons). The idea of having to run under root was one of the ones why people avoid SVGAlib nowadays, and setuid/root will be a deep security risk considering what kind of apps we're looking at here. If we say, run notepad, we have a root editor application -- capable of messing with config files on the Linux setup -- something that the Linux admin might not want. Personally, it would only affect me in that files generated by wine could be owned by root:root when I normally run under a user id, such as michael:michael or michael:windows or something. For the time being, of course, the theory is that run as root should work okay. If this is implemented, shouldn't this be a warning, not a forced thing? So that a normal user could (try and) run wine without root access? And I presume that this would be 2.6 specific detection - otherwise, there's not really a need (since Wine worked OK under 2.4 and such). We could say something like: "Wine has dectected that you are running Wine as a normal user under Linux kernel 2.6+. Due to changes in the scheduling mechanism in 2.6, which includes preempting and a change in the way process priorities are handled, Wine may not work properly, or different parts may work at different speeds, causing desyncronization of your application and/or it's components. You are suggested to <(run wine as root) or (downgrade and use a (2.4 kernel) AND/OR <supported kernels list>) or (list other workaround information)>." So we're looking for a user-mode mechanism of temorarily changing priority or emulating/faking it as Windows does it, and then allowing the restoration of that priority to a higher value (not normally found in Linux except as root). I presume that if someone wanted to get started writing a patch now using any one of these ideas, then we could just test it and see how it does among us, and then if it's okay, submit it, get it through CVS, see what happens, get it through a release if that happens, and then we can finish this debate only when performance issues or something else needs to be done about this. I think that finally, we should allow the user to bypass this scheduling patch for 2.6 during development if he/she really wants to, but don't make it too easy, and when he/she does, warn that things like audio and video can come out of syncronization and programs can break and such. Or do you guys already do this? Just trying my best. --Michael Chang

Aug. 31, 2004

Re: KERNEL32: implement CallNamedPipe

by Dmitry Timoshkov

"Mike McCormack" <mike(a)codeweavers.com> wrote: > + r = WaitNamedPipeW( lpNamedPipeName, nTimeout ); > + if( !r ) > + return r; win2k kernel32 does not do WaitNamedPipeW. > + handle = CreateFileW( lpNamedPipeName, GENERIC_READ|GENERIC_WRITE, > + 0, NULL, OPEN_EXISTING, 0, NULL ); > + if( !handle ) > + return FALSE; CreateFileW returns INVALID_HANDLE_VALUE on failure, not 0. > + r = WriteFile( handle, lpOutput, dwOutputSize, &count, NULL ); > + if( r ) > + r = ReadFile( handle, lpInput, dwInputSize, lpBytesRead, NULL ); win2k kernel32 calls SetNamedPipeHandleState and TransactNamedPipe (not implemented in Wine) here. > + CloseHandle( handle ); > + > + return r; > } -- Dmitry.

Aug. 31, 2004

Re: Add some padding in WINPROC_wrapper

by Mike McCormack

Uwe Bonnes wrote: > Mike> Perhaps the problem is due to a missing registry key or directory? > Mike> If you'd like I can send you a relay trace to compare. > > Please do so. Strangely enough when I try to do so, it crashes :) I'll investigate a bit. Mike

Aug. 31, 2004