September 2003 - Wine-Devel

Re: decompiling

by Alexandre Julliard

"Ivan Leo Murray-Smith" <puoti(a)inwind.it> writes: > to translate the wine dlls to italian, my idea was to just get the strings from > a disassembled m$ dll. Also, the text strings in wine dlls are a little different > here and there respect to windows, and I was thinking that it would be a good > idea to uniform them, can I do this or would it be a DMCA violation (Not that I > care about the DMCA but the main cvs server is in the US)? It's a copyright violation. Don't do that. -- Alexandre Julliard julliard(a)winehq.com

Sept. 29, 2003

Re: wine & ccache

by Alexandre Julliard

"Dimitrie O. Paun" <dimi(a)intelliware.ca> writes: > A nice thing would be to also be able to generate a top > Makefile that knows all about the project, and we > no longer do the recursive descent. It takes my box > almost 20 seconds to do a 'make -s' after a full build. > Not sure how doable this is, but I'm sure that things > would be way faster if everything would be in one big > Makefile. Probably I'm just going to end up buying a > faster box before this gets implemented though :) Some time ago I looked into hacking make_dlls to do this, but there were too many special cases to make it worthwhile. And on my new box the recursion takes less than 2 seconds so I no longer care <g> -- Alexandre Julliard julliard(a)winehq.com

Sept. 29, 2003

Re: decompiling

by Dimitrie O. Paun

On Tue, 30 Sep 2003, Ivan Leo Murray-Smith wrote: > to translate the wine dlls to italian, my idea was to just get the strings from > a disassembled m$ dll. Also, the text strings in wine dlls are a little different > here and there respect to windows, and I was thinking that it would be a good > idea to uniform them, can I do this or would it be a DMCA violation (Not that I > care about the DMCA but the main cvs server is in the US)? Please don't -- there is no reason to do so, just translate the strings in the .rc files. -- Dimi.

Sept. 29, 2003

Re: Start menu (especially for Alexandre Julliard)

by Mike McCormack

Robert van Herk wrote: > Mike McCormack wrote: > >> Ideally, you'd want to write a Gnome VFS module that calls shell32.dll >> and queries the shell name space to generate the start menu the same >> way Windows does. You need to use some RPC mechanism to do that, as >> you can't link wine dlls directly into your gnome vfs module. > > > Oof, that sounds hard to do ;-). > > Does this mean that this module would rather be a "Windows" program (or > Wine program if you like), than a Linux programme? Because I guess that > with a Win32 program it would be easier to access shell32.dll. Although > that would not blend so well into your Linux environment I guess... > > Or maybe it is possible to write a thin Windows deamon that kinda serves > the icons and links to a Linux program? Maybe they can talk though > std/in std/out so that they could be piped together? > > Any ideas on that? What I'm talking about would be, like you say, a Windows daemon that servers the icons and pathes. The client and server would communicate with each other via a pipe or something like that. The client(s) would be a gnome vfs library, the KDE equivilent, or perhaps even plugins for other desktops. To make it easier, i guess you could just make the windows daemon enumerate the .lnk files in Windows/Start Menu first, then once you have that working, make it query the shell instead. The appropriate code from Gnome to look at is in the gnome cvs: :pserver:anonymous(a)anoncvs.gnome.org:/cvs/gnome the module names are: gnome-vfs gnome-vfs-extras gnome-panel I was looking at xml-rpc for the protocol to use on the pipe, but that might be a bit of an overkill, and it could be easier to write the protocol yourself. http://www.xmlrpc.com/directory/1568/implementations If you are going to use xml-rpc, make sure to choose an implementation that is LGPL compatible. Mike

Sept. 29, 2003

decompiling

by Ivan Leo Murray-Smith

Hi list, to translate the wine dlls to italian, my idea was to just get the strings from a disassembled m$ dll. Also, the text strings in wine dlls are a little different here and there respect to windows, and I was thinking that it would be a good idea to uniform them, can I do this or would it be a DMCA violation (Not that I care about the DMCA but the main cvs server is in the US)?

Sept. 29, 2003

Re: [ANN] Conformance testing campaign

by Ferenc Wagner

"Dimitrie O. Paun" <dimi(a)intelliware.ca> writes: > On Sat, 27 Sep 2003, Ferenc Wagner wrote: > >> For the console test, yes. I just did not care, because I >> was promised a better run. > > In other words, he is supposed to detect a hanged test, > and report an error? Now I lost you here. Who is he? The setting is this: if a test simply crashes, the framework goes on and the failure will be obvious. If a test hangs, the user can kill it and we have the same. Or the timeout can kill it and maybe note this in the log. This all depends on the framework, but we only have serious trouble if the user kills the framework itself, which happened in the case of the ME tests. >> Or simply append a number if the submission is done by >> email. > > For sure we need to append a number, but my point is that > once we generate that name dinamically, it's ugly and it > shouldn't be displayed. An occasional 1, 2 or 3 at the end of your tag? Why not? > As for who submitted it, we already have that, so we're > good. But it can not possibly be displayed (a name is too wide and you may have submitted several tests), while it seems useful for quick visual identication, if you want to concentrate on a single test run. Or do you simply not want to do this? I do. >> But I have a real problem here: which results to put in the >> main summary if there are many reports for a version? The >> one submitted first? The one with the most/least successes? >> Or maybe a mixture? Now it is the one with no tag, which is >> practically the first submission. > > What about the max number of errors in all tests? Possible, but it would destroy the consistency of the links in the column. May be worth it, though. >>> How come? I thought Jakob includes a dump of the OS version >>> structure, like so: >> >> Yes, he does. But except for one result submitted by Jakob, >> all the results are from my .bat-driven zip file. > > In other words, for stuff that includes that info, you > parse it out? Maybe you should stop distributing the > .bat file, we need to figure out how well do the two > things work together, no? Oh yes, I have not got any more reports for a while, and do not intend to distribute newer versions of my package. We had some discussion with Jakob on the format already, but not finished yet. Especially not with the master file... Feri.

Sept. 29, 2003

Re: Updated winetests.exe

by Ferenc Wagner

Jakob Eriksson <jakob(a)vmlinux.org> writes: > On Sat, Sep 27, 2003 at 02:29:48PM +0200, Ferenc Wagner wrote: > >> Tester= field should be given slightly more emphasis, and > > How can I add more emphasis to it? Sorry for my vague language, is reflects my vague thoughts. Currently, it is amongst cryptic looking lines with a strong don't-touch-me feel. This is right, nobody should tinker with most of the output, which should probably be static for this reason. But let's not care about the submission form for now. What I mean is the tester name and contact address should be explicitly asked for (with a warning that it will appear on the Web, munge if you want). Like the comment. >> the comment could be perhaps part of the report? > > Ahh.. ok, I'll fix that. I will probably fix it in a few > days, unless current situation is OK: I made a temporary > fix by putting the comment at the bottom of the report, > but I guess you want it at the top. I do not care too much, but the top would be nicer, really. Close it with something distinctive. >> It also seems like one architectural change will be >> necessary: when you build a test suite, the names of the >> included tests, their source directories and CVS revision >> numbers should be written into a separate file, and copied > > Names... ok, these are known. Source directories? Ahh, > that is harder. Could be done though, with some trickery. Strange, the source directories were the first thing I determined when I built my test package. First of all, I could not collect the tests short of this... > CVS revision number? How do I even find that? It is in the CVS directory, look at the Entries file. >> straight onto the processing site. This is necessary for > > And now I am lost again. What is the processing site? WineHQ.org. See my response to Dimi. > Do you want a second file generated apart from the mail sent > to wine-tests-report? (If yes, where should this file be sent?) Yes, but this second file is generated when you build and publish the new tests binary, and sent straight to WineHQ, possible together with some other information, like build error logs. > If you give a specification, as exact as possible, I can > probably create the file. It should be something along build unit directory (excuse if not built) test revision test revision [...] unit directory (excuse if not built) test revision test revision [...] etc. Maybe something more expandable, I am rather poor at designing file formats. But do not be too fast, Dimi opposes the whole idea, let's see what comes out at the end. Feri.

Sept. 29, 2003

Re: Fix for bug 640 - moving thin frames leaves mess

by Pavel Roskin

On Sun, 28 Sep 2003, Alexandre Julliard wrote: > Pavel Roskin <proski(a)gnu.org> writes: > > > Patch for cmdlgtst.c to produce those pictures is attached. before.png > > was taken with current Wine. after.png is with the fix that removes the > > special procession of R2_XORPEN. I would not say that nobody will use > > this effect. Anyway, the whole thing is not worth arguing about. > > I think it's definitely worth arguing about, and you are right that > there are cases where the hack is wrong, I missed the opaque > background issue. Still, the hack was added for a reason, so I don't > think we want to remove it completely; but it should be improved to > check for the pen and background types. Too bad I cannot reproduce any problem with Paintbrush. I even put FIXME to the code but it's never activated if DrawFocusRect() is fixed (see patch). I have no idea what "rubber-drawings" mean. I have tried all tools in 8 and 24 bpp and the problems I see are not affected by the code in question. The problems are: Paintbrush won't exit without saving. Flood fill takes a wrong point as reference and paints with the same incorrect offset. The horizontal offset (63) is almost equal to the width of the toolbox (64). The vertical offset is 3 pixels high. http://www.red-bean.com/~proski/wine/pbrush.png One-color eraser (left, third from top) is a terrible CPU hog. Selection lines are not redrawn after being covered by the menu. After the selection is canceled, the obscured part becomes visible and remains in the picture. Saving images crashes with: Unhandled exception: unimplemented function olesvr.dll.OLERENAMESERVERDOC called in 32-bit code (0x413b6250). -- Regards, Pavel Roskin

Sept. 29, 2003

wine & ccache

by Dimitrie O. Paun

Hi folks, Just wanted to let people know that ccache works rather well with wine. On my lowly 600MHz Pentium box, it takes about 1h to compile, after a make clean. Second time through it takes about 1/4h to do the same thing, 75% faster! (As an added bonus, CPU utilization dropped from 86% to 60%) A nice thing would be to also be able to generate a top Makefile that knows all about the project, and we no longer do the recursive descent. It takes my box almost 20 seconds to do a 'make -s' after a full build. Not sure how doable this is, but I'm sure that things would be way faster if everything would be in one big Makefile. Probably I'm just going to end up buying a faster box before this gets implemented though :) How long does it take to do a 'time make -s' after a full build on one of the beefier boxes? -- Dimi.

Sept. 29, 2003

Re: shlwapi 405/406

by Jon Griffiths

Hi, --- Alexandre Julliard <julliard(a)winehq.com> wrote: > Precisely, this way it's obvious which functions are meant to be > used by Win32 apps and which are internal to Wine. Hmm, I think any programmer who thinks a static function in one of the implementation files of a given dll can possibly be part of the exported Win32 API has larger problems than just confusion over what the API covers ... and I believe the documentation sitting right above the protoypes of exported functions should suffice to distinguish for those who want to learn Win32 programming by scanning the Wine source tree. But since you're adament, this should probably be made a janitorial task; internal stdcall functions are currently used in other places (5 other files in shlwapi, for example). I'll resend. Cheers, Jon ===== "Don't wait for the seas to part, or messiahs to come; Don't you sit around and waste this chance..." - Live jon_p_griffiths(a)yahoo.com __________________________________ Do you Yahoo!? The New Yahoo! Shopping - with improved product search http://shopping.yahoo.com

Sept. 29, 2003