January 2005 - Wine-Devel - list.winehq.org

Re: Slick build output

by Jesse Allen

On Mon, 31 Jan 2005 10:41:15 +1100, Jason But > > --------------------------------------------------------------------------- > jbut-laptop# make > Making in libs/ > Making in libs/port/ > Compiling ffs.c > Compiling fstatvfs.c > Compiling futimes.c > Compiling getopt.c > Compiling getopt1.c > Compiling getpagesize.c Abbreviated build output is nice. I personally like how the linux kernel build system uses the basic command names themselves for the abbreviation. For example, instead of "compiling", use "CC". That way it should generally be shorter in output than using the English word, and save even more diskspace. True, it may make it more cryptic again, but people who build their own wine should know what CC is for anyway.

Jan. 31, 2005

Re: Slick build output

by Jason But

First, I apologise for the patch not being here... It appears that my attachment failed, I include it inline in the mail this time.. To Make.rules.in --------------------------------------------------------------------------- 20a21,32 > # Default running of (gnu)make causes a silent make with the NICE_ECHO > # macro expanding to the echo command. > # Running (make VERBOSE=yes) causes the NICE_ECHO to expand to the NULL > # shell command and cause no output. The output will be as per the > # original incarnation of the Makefile > ifneq ($(VERBOSE), yes) > .SILENT: > NICE_ECHO = @echo -e > else > NICE_ECHO = @: > endif > 118a131 > $(NICE_ECHO) " Compiling\t\t$<" --------------------------------------------------------------------------- There has been a range of comments to my original proposal. I make the following points. - I understand that there are those who desire to see the full output, for those running "make VERBOSE=yes" will produce exactly the same output as before. - To the suggestion of "make -s", this gives no output and is pretty useless. - I have been a developer for 20 years and nothing frustrates me more than make output that is over complicated. I see the point of printing the full command line when developing and debugging the Makefile and the make process. Once this is fixed however, I prefer a simple output from make telling me what is currently being compiled, I don't need to see all output every time. Finally, I have progressed a little further, but no patches for you yet. I have modified the *.in files for Make.rules.in, and in the libs and tools subdirectories. My current output (of make) is attached below for comment. I have similar output for "make install" and "make uninstall" (output is nicely lined up on fixed-width fonts :-) Jason. --------------------------------------------------------------------------- jbut-laptop# make Making in libs/ Making in libs/port/ Compiling ffs.c Compiling fstatvfs.c Compiling futimes.c Compiling getopt.c Compiling getopt1.c Compiling getpagesize.c Compiling gettid.c Compiling interlocked.c Compiling lstat.c Compiling memcpy_unaligned.c Compiling memmove.c Compiling mkstemps.c Compiling pread.c Compiling pwrite.c Compiling readlink.c Compiling sigsetjmp.c Compiling spawn.c Compiling statvfs.c Compiling strcasecmp.c Compiling strerror.c Compiling strncasecmp.c Compiling usleep.c Creating Library libwine_port.a Making in libs/unicode/ Compiling casemap.c Compiling collation.c Compiling compose.c Compiling cptable.c Compiling fold.c Compiling mbtowc.c Compiling sortkey.c Compiling string.c Compiling utf8.c Compiling wctomb.c Compiling wctype.c Compiling c_037.c Compiling c_424.c Compiling c_437.c Compiling c_500.c Compiling c_737.c Compiling c_775.c Compiling c_850.c Compiling c_852.c Compiling c_855.c Compiling c_856.c Compiling c_857.c Compiling c_860.c Compiling c_861.c Compiling c_862.c Compiling c_863.c Compiling c_864.c Compiling c_865.c Compiling c_866.c Compiling c_869.c Compiling c_874.c Compiling c_875.c Compiling c_878.c Compiling c_932.c Compiling c_936.c Compiling c_949.c Compiling c_950.c Compiling c_1006.c Compiling c_1026.c Compiling c_1250.c Compiling c_1251.c Compiling c_1252.c Compiling c_1253.c Compiling c_1254.c Compiling c_1255.c Compiling c_1256.c Compiling c_1257.c Compiling c_1258.c Compiling c_10000.c Compiling c_10006.c Compiling c_10007.c Compiling c_10029.c Compiling c_10079.c Compiling c_10081.c Compiling c_20866.c Compiling c_20932.c Compiling c_28591.c Compiling c_28592.c Compiling c_28593.c Compiling c_28594.c Compiling c_28595.c Compiling c_28596.c Compiling c_28597.c Compiling c_28598.c Compiling c_28599.c Compiling c_28600.c Compiling c_28603.c Compiling c_28604.c Compiling c_28605.c Compiling c_28606.c Creating Library libwine_unicode.so.1 Creating Library libwine_unicode.so Making in libs/wine/ Compiling config.c config.c: In function `init_server_dir': config.c:120: warning: right shift count >= width of type config.c:125: warning: right shift count >= width of type Compiling debug.c Compiling ldt.c Compiling loader.c Compiling mmap.c Compiling port.c Creating Library libwine.so.1 Creating Library libwine.so Making in libs/wpp/ Compiling preproc.c Compiling wpp.c YACCing ppy.y Compiling y.tab.c LEXing ppl.l Compiling lex.yy.c Creating Library libwpp.a Making in tools/ Compiling bin2res.c Linking bin2res Compiling fnt2bdf.c Linking fnt2bdf Compiling fnt2fon.c Linking fnt2fon Compiling makedep.c Linking makedep Compiling sfnt2fnt.c Linking sfnt2fnt Creating wineprefixcreate Making in tools/widl/ Compiling hash.c Compiling header.c Compiling proxy.c Compiling typelib.c Compiling utils.c Compiling widl.c Compiling write_msft.c write_msft.c:584: warning: 'ctl2_alloc_importinfo' defined but not used write_msft.c:622: warning: 'ctl2_alloc_importfile' defined but not used write_msft.c:920: warning: 'ctl2_find_nth_reference' defined but not used YACCing parser.y conflicts: 25 shift/reduce Compiling y.tab.c LEXing parser.l Compiling lex.yy.c Linking widl Making in tools/winebuild/ Compiling import.c Compiling main.c Compiling parser.c Compiling relay.c Compiling res16.c Compiling res32.c Compiling spec16.c Compiling spec32.c Compiling utils.c Linking winebuild Creating winebuild.man Making in tools/winedump/ Compiling debug.c Compiling emf.c Compiling le.c Compiling main.c Compiling misc.c Compiling msmangle.c Compiling ne.c Compiling output.c Compiling pe.c Compiling search.c Compiling symbol.c Linking winedump Making in tools/winegcc/ Compiling winegcc.c Compiling utils.c Linking winegcc Making in tools/wmc/ Compiling lang.c YACCing mcy.y YACCing mcy.y Compiling mcl.c Compiling utils.c Compiling wmc.c Compiling write.c Compiling y.tab.c Linking wmc Making in tools/wrc/ Compiling dumpres.c Compiling genres.c Compiling newstruc.c Compiling readres.c Compiling translation.c Compiling utils.c Compiling wrc.c Compiling writeres.c YACCing parser.y conflicts: 5 shift/reduce Compiling y.tab.c LEXing parser.l Compiling lex.yy.c Linking wrc

Jan. 30, 2005

Re: Wine packages, universe maintainence, and myself

by Mike Hearn

On Sun, 30 Jan 2005 17:57:20 -0500, Vincent Béron wrote: > That's something you need to sort out through Debian, not Ubuntu nor > winehq. Each one of these projects have their own community and rules, > and even if some parts of them overlap, they're still different > entities. > > Any attempt to use your position in one to force another one to your > liking will result in grumbling. > > Moreover, you already know the steps to replace Ove as Debian's > maintainer: file bugs in Debian's bug system, then provide fixes for > them, one at a time. The only problem is you think that solution will > take too long to reach the goals you'd like. But it's the only way to > go. Any other way just won't work. Hmm, I think it's fine for Scott to just work around Debian here. There's no guarantee that just filing bugs one at a time will achieve anything, right? While it is rather tempting to just say that Debian should sort themselves out, unfortunately we still end up with random users running bad packages so we get to pick up the pieces. I'd rather Scott provided better packages even if it's not a part of Debian officially. >> -PAX issues will inevitably come up again. This was an issue that came >> up before, although with Ubuntu using the latest Wine it will certainly >> be an easier one to tackle. > > More Ubuntu/PAX users developing Wine would help on finding and fixing > more quickly those. But you can't force people to use a certain > distribution... Well, it's all a bit controversial isn't it. I'm absolutely not convinced PaX reveals "bugs": so far on the list of things it breaks are such fundamental programs as OpenGL and the Nautilus file manager. I for one don't care much right now if Wine is on that list too, given that I don't see how you can have a modern desktop with it enabled ... thanks -mike

Jan. 30, 2005

Re: RICHEDIT once again

by Krzysztof Foltman

Rob Shearman wrote: > There are a few HGDIOBJ casts as well as the already mentioned ALLOC_OBJ > macro. For example, in paint.c: > DeleteObject((HGDIOBJ)hbr); Yes, both are HANDLEs, so they don't really need a cast. I've probably written too much MFC code in my life :) I've deleted all HGDIOBJ casts, but I'm not sure if it's the only case of redundant casts. Krzysztof

Jan. 30, 2005

Re: Wine packages, universe maintainence, and myself

by Vincent Béron

Le sam 29/01/2005 à 20:49, Scott Ritchie a écrit : > Hello, > > I met some of you on IRC the other night. I am currently the Debian and > Ubuntu packager for the Wine project. The "official" Debian maintainer > hasn't been updating the packages and refuses to turn them over to me, > so we've setup our own apt repository at winehq.org. That's something you need to sort out through Debian, not Ubuntu nor winehq. Each one of these projects have their own community and rules, and even if some parts of them overlap, they're still different entities. Any attempt to use your position in one to force another one to your liking will result in grumbling. Moreover, you already know the steps to replace Ove as Debian's maintainer: file bugs in Debian's bug system, then provide fixes for them, one at a time. The only problem is you think that solution will take too long to reach the goals you'd like. But it's the only way to go. Any other way just won't work. > The packages have > been tested a lot, and are also in the Ubuntu backports project working > fine. I was wondering what it would take to make them the ones that sit > on Ubuntu's repository, rather than the (very old) Debian unstable ones, > and from what I heard on IRC it seems like this is a rather doable thing > for Ubuntu as we don't have to worry about Debian politics so much. > > Hence, I am writing this email. I'd be willing to maintain the Wine > packages for Ubuntu, as well as related ones such as winetools. There's > other work for me to do as well, but I suppose the first step is to > coordinate things in here and make this happen. > > There's quite a bit on my todo list for the moment [snip] > -The Winelib documentation needs updating as well. I plan on using my > experience trying to port Miranda IM to help it out. Basically, look in past postings by Dimi when he was explaining the reasoning behind winegcc (port first to mingw on Windows, then replace gcc/g++/windres by winegcc/wineg++/wrc). Of course there are other things to look for, for which winemaker is still suited (correct #include "CaPiTaLiZaTiOn.h", line endings, etc.). > -Winetools, a useful program for running Wine, also needs packaging. > I've got it almost finished at this point, although I need some help > with some issues I've been having. More on this in IRC. > > > As for the Wine package itself, the current versions of the Wine and > Winetools packages are in my webspace, here: > deb http://tuzakey.com/~scott/apt binary/ > deb-src http://tuzakey.com/~scott/apt source/ > > The Wine package at first glance seems a bit different from some Debian > standards, for various reasons. > > First off, even though Wine has some seemingly shared libraries, I > haven't split them off. This is because only wine binaries can really > use them, and they need the latest version anyway. They don't need "the latest" version, only a compatible version with the one they were compiled against, at least until DLL separation is completely sorted out (as well as probably other stuff I'm currently forgetting about). So if you install Miranda compiled against Wine 20050111, there's no guarantee (for now, this should change after Wine 0.9) that the same binary will work with Wine 200502?? or later. Commercial projects using Winelib have shipped a version of Wine with their software for this very reason (see Corel). It's something on the todo list, but it's not done yet. > Both windows apps > called with Wine and winelib apps still need to be handled by the same > wineserver (in case they message eachother, amid other reasons), and so > they are both completely dependent on the Wine binaries anyway. > Furthermore, since it's the same wineserver coordinating everything on a > system, it needs to have the same library in use - since it's basically > impossible to get use out of more than one libwine.so.x in a system, it > makes little sense to support this. No problem doing so with various LD_LIBRARY_PATH... Even doing so in pre-packaged binaries is much doable (look at Crossover Office and Cedega). > > Secondly, Wine, not being an emulator, has some rather important > differences between architectures. Wine really does need 3 different > packages for the 3 different Ubuntu arches, as they each have some > challenges. The i386 one is the simplest, and is basically standard > Wine. The PPC arch can only run winelib apps, so it may need some > trimming down and added documentation to prevent confusion. The 64 bit > version of Wine represents the most interesting challenge, as Wine will > still need the old 32 bit libraries to run 32 bit Windows applications. > According to forum posts I've read, Wine packages not currently doing > this easily is actually a blocker for some users in switching to 64 bit > Ubuntu. Use the 32bit package on 64bit Ubuntu (you'll need 32bit libraries as well). It's the only way to go for now. If the package management tools can't handle this, at least know that the files in both the 32bit and 64bit packages will be the same if you do a plain ./configure on a x86-64 computer. Unless I don't understand what you mean by "different packages"... > > Wine has some rather unique things which make it harder to maintain. > -Arch issues, like mentioned above > -PAX issues will inevitably come up again. This was an issue that came > up before, although with Ubuntu using the latest Wine it will certainly > be an easier one to tackle. More Ubuntu/PAX users developing Wine would help on finding and fixing more quickly those. But you can't force people to use a certain distribution... [snip] Vincent

Jan. 30, 2005

Re: RICHEDIT once again

by Rob Shearman

Krzysztof Foltman wrote: > Rob Shearman wrote: > >> However, there are a few superfluous typecasts. > > > Any examples ? There are a few HGDIOBJ casts as well as the already mentioned ALLOC_OBJ macro. For example, in paint.c: DeleteObject((HGDIOBJ)hbr); > >> In particular, please remove the ALLOC_OBJ macro because the name >> seems to suggest it does more than it actually does. > > > I'd prefer to rename the macro, and not remove it completely, it could > be used for tracking memory allocations one day. And I don't really > like the HeapAlloc API. > >> What is the ParaStyle structure used for? > > > Currently, it's not used. It's a placeholder for keeping real > paragraph attributes, RICHEDIT's PARAFORMAT/PARAFORMAT2, part of which > is currently stored directly in ME_Paragraph (nAlign, nLeftMargin, > nRightMargin, nFirstMargin). The whole paragraph handling (para.c) > needs lots of work. Ok. >> Each character can have a different style, so why is there a >> paragraph style? > > > See above. The current content of the structure is irrelevant, and is > a kind of legacy from my misunderstanding of the relationship between > CHARFORMAT and PARAFORMAT. Great. The code looks good so far. I look forward to being able to review a patch against Wine. Rob

Jan. 30, 2005

Re: RICHEDIT once again

by Krzysztof Foltman

Rob Shearman wrote: > What is the ParaStyle structure used for? How does this relate to the > Style structure? Each character can have a different style, so why is > there a paragraph style? Ahh, good news: the paragraph format structure (PARAFORMAT2) doesn't need any precalculation (contrary to the character style, which caches a HFONT and TEXTMETRIC). That means I can keep the paragraph format directly in the ME_Paragraph, and remove the ME_ParaStyle completely. In fact, I've just removed all the ParaStyle-related code without any negative consequences. Krzysztof

Jan. 30, 2005

Re: RICHEDIT once again

by Krzysztof Foltman

Rob Shearman wrote: > No, the LocalAlloc/LocalFree/GlobalAlloc/GlobalFree functions are relics > from the old days of Win16. You should use HeapAlloc/HeapFree. True. > Undo should be pretty easy as long as you can represent easily represent > user actions in a transactions stack. Yes, I know the undo basics. The most recent source has the basic stack structure. :) It's still a bit complex, as, first, we have formatting to store on the stack (linked actions are the way to go), and it's easy to miss something, making undo fail in unusual circumstances. > stack (although you would probably want some coalescing so that you > don't have to undo each character you typed, There's more: it's required by RICHEDIT API. > sentence). The undo command will pop a transaction of the stack and > apply the inverse. Well, it can't apply the inverse ;) You need to push the inverse. > However, there are a few superfluous typecasts. Any examples ? > In particular, please remove the ALLOC_OBJ macro because the name seems to suggest it does > more than it actually does. I'd prefer to rename the macro, and not remove it completely, it could be used for tracking memory allocations one day. And I don't really like the HeapAlloc API. > This is just a > suggestion and you may feel that it is easier to use your own. The big advantage is that it's independent from Wine-specific API. Which makes it more useful in non-Wine applications (the code is LGPLed, so why not use it somewhere else ?). > A few more comments wouldn't go amiss either. Definitely. And to make things worse, not all FIXME's and XXXKF's are still relevant. It asks for a cleanup. But, undo first (because it involves even more major changes). > What is the ParaStyle structure used for? Currently, it's not used. It's a placeholder for keeping real paragraph attributes, RICHEDIT's PARAFORMAT/PARAFORMAT2, part of which is currently stored directly in ME_Paragraph (nAlign, nLeftMargin, nRightMargin, nFirstMargin). The whole paragraph handling (para.c) needs lots of work. > Each character can have a different style, so why is > there a paragraph style? See above. The current content of the structure is irrelevant, and is a kind of legacy from my misunderstanding of the relationship between CHARFORMAT and PARAFORMAT. Krzysztof

Jan. 30, 2005

Re: KERNEL: stub implementation for ReadDirectoryChangesW

by Vincent Béron

Le dim 30/01/2005 à 13:37, Hans Leidekker a écrit : > > This prevents a crash in Picasa2. > > -Hans > > Changelog: > Stub implementation for ReadDirectoryChangesW. You forgot to remove the stub entry in kernel32.spec and replace it by a line with proper argument types. Vincent

Jan. 30, 2005

Re: SHLWAPI: implement PathIsValidChar{A,W}

by Juan Lang

Hi Hans, it looks like from values 0x7e onward the character class is always PATH_CHAR_CLASS_OTHER_VALID. If you like, for clarity you can fill in the value through 0x7f, but having a lookup table beyond this isn't necessary. Also, that means the data type can be unsigned char, not DWORD. And, it looks like the return value isn't consistent: +static BOOL WINAPI PathIsValidCharAW( unsigned char c, DWORD class ) +{ + return class & SHELL_charclass[c]; +} Here you mask class with the value in the table.. +BOOL WINAPI PathIsValidCharA( char c, DWORD class ) +{ + return PathIsValidCharAW( (unsigned char)c, class ); +} and again here, implicitly.. +BOOL WINAPI PathIsValidCharW( WCHAR c, DWORD class ) +{ + if (c > 0xff) return PATH_CHAR_CLASS_OTHER_VALID; + return PathIsValidCharAW( (unsigned char)c, class ); +} But for values of c greater than 0xff, you do not mask. This may be deliberate, I don't know, but it doesn't look correct. --Juan p.s. Have you added me to your spam list yet? ;) __________________________________ Do you Yahoo!? Yahoo! Mail - Helps protect you from nasty viruses. http://promotions.yahoo.com/new_mail

Jan. 30, 2005