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

PRESS: run windows viruses with wine ...
by Marcus Meissner Feb. 4, 2005

Feb. 4, 2005

Hi, Fun article ... author tests various viruses with WINE. http://os.newsforge.com/article.pl?sid=05/01/25/1430222&from=rss Ciao, Marcus

8 12

Re: [user32/tests/sysparams.c] Check for availability of SPI_GETICONTITLEWRAP
by jchevrier＠nexicom.net Feb. 3, 2005

Feb. 3, 2005

> Hi, > > SPI_{GET,SET}ICONTITLEWRAP is not implemented on a standard Win98 SE. > > Changelog > Check for availability of SPI_GETICONTITLEWRAP > > Cheers, > > Paul. Hi Paul, I agree we definately should not be leaving keys/values in user's registries that weren't there originally after the test has been run. Ideally all should be returned to exactly the way it was before the test was run. Unfortunately this patch won't correct the issue. This patch implies that SPI_{GET,SET}ICONTITLEWRAP is not a supported call on Win98 which it is. As a result it will always pass and the registry will still get a new value added. Try the following patch. It was just put together quickly and only covers this one test, but testing here shows it does stop a new value from being added if it did not exist to begin with. I would like to create something that covers the entire sysparams suite of tests to stop this across the board. Thanks for the heads up on this! Justin

3 6

olepicture.c compile failure : "structure has no member named `UserData', implicit declaration of function `DGifOpen'"
by Rizwan Kassim Feb. 1, 2005

Feb. 1, 2005

This has been reported as Bugzilla 1730. " olepicture.c: In function `_gif_inputfunc': olepicture.c:834: structure has no member named `UserData' olepicture.c: In function `OLEPictureImpl_Load': olepicture.c:923: warning: implicit declaration of function `DGifOpen' olepicture.c:923: warning: assignment makes pointer from integer without a cast make[2]: *** [olepicture.o] Error 1 " configure, apparently, doesn't check that both libgif.so and libungif.so are the correct versions. This was with latest CVS 2005-01-15, in /wine/dlls/oleaut32 Some slackware and debian installs that I've found have : /usr/lib/libgif.so -> libungif.so.3.0.0 /usr/lib/libungif.so -> libungif.so.3.0.0 libungif.so.4.1.0 was available, however. Running: ln -s /usr/lib/libungif.so.4.1.0 libungif.so ln -s /usr/lib/libungif.so.4.1.0 libgif.so in the wine/dlls/oleaut32 directory fixes the compile. I've added this fix to the (Unconfirmed) bug. Any input -- whats my next step? -- Thank you, Rizwan Kassim

3 3

[AppDB] bug on links
by Raphael Feb. 1, 2005

Feb. 1, 2005

Hi, try http://appdb.winehq.org/appview.php?appId=443&versionId=627 select the www.darkageofcamelot.com link .... bug :) Regards, Raphael

2 1

Re: Slick build output
by Jason But Jan. 31, 2005

Jan. 31, 2005

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

4 6

Re: wine/dlls x11drv/x11drv.h x11drv/winpos.c x11d ...
by Dimitrie O. Paun Jan. 31, 2005

Jan. 31, 2005

On Mon, Jan 31, 2005 at 10:34:07AM -0600, Alexandre Julliard wrote: > Log message: > Only create an X window for top-level windows, not for child windows. > Get rid of the X client window too, it's no longer needed. Cool. Does this mean that the window management rewrite is done? -- Dimi.

3 5

emsabp.idl - virtually identical data structures to mapidefs.h
by Luke Kenneth Casson Leighton Jan. 31, 2005

Jan. 31, 2005

hi, here's an IDL file i'm working on for exchange 5.5 server. as you can see it's virtually identical, structure-for-structure, to those listed in mapidefs.h. at about struct MAPIERROR, the similarity stops. thoughts, anyone? l. -- -- <a href="http://lkcl.net">http://lkcl.net</a> --

1 1

[game] Running; Dark Reign - The future of war with Wine
by Joachim Schiele Jan. 31, 2005

Jan. 31, 2005

Dear Wine Developers, I've tried to get this game running with wine but after starting i get a nice main menu (sound is ok, too) but there is no mouse. You can't use the mouse altough there is a nice animated cursor. There must be something wrong with wine because in cedega it's working nice. More about this in [2] check the comment from me to dig further into this problem. My question is where should I start to search for the mouse problem? Was there a similar problem with other games in the past? Also note i've already tested the DX grab and the DGA settings with no effect. Maybe this problem is solved very fast! That would be goot because then i could start working on the network/IPX/IP things to get network play working. Dark Reign - The future of War and The Rise Of the Shadowhand is running quite nice with cedega, and I believe if only the mouse would be working it would do the same with wine! Thanks for wine, thanks for your help & and valuable time, Greets, Joachim Schiele ============================= The error message ============================= joachim(a)knabber:~/darkreign$ wine dkreign.exe Please use the registry key HKEY_CURRENT_CONFIG\Software\Fonts\LogPixels to set the screen resolution and remove the "Resolution" entry in the config file Xlib: extension "XFree86-DRI" missing on display ":0.0". fixme:ddraw:Main_DirectDraw_SetCooperativeLevel (0x77c4c018)->(00010022,00000008) fixme:ddraw:Main_DirectDraw_SetCooperativeLevel (0x77c4c018)->(00010022,00000013) fixme:x11drv:X11DRV_desktop_SetCurrentMode Cannot change screen BPP from 32 to 8 fixme:x11drv:X11DRV_desktop_SetCurrentMode Cannot change screen BPP from 32 to 8 fixme:x11drv:X11DRV_DDHAL_CreatePalette stub fixme:mmtime:timeBeginPeriod Stub; we set our timer resolution at minimum fixme:dsound:IDirectSoundImpl_SetCooperativeLevel level=DSSCL_PRIORITY not fully supported fixme:mci:MCI_LoadMciDriver Couldn't load driver for type CDAUDIO. If you don't have a windows installation accessible from Wine, you perhaps forgot to create a [mci] section in system.ini fixme:mci:MCI_LoadMciDriver Couldn't load driver for type CDAUDIO. If you don't have a windows installation accessible from Wine, you perhaps forgot to create a [mci] section in system.ini fixme:wave:DSD_CreateSecondaryBuffer (0x77c4c5e0,0x77acff20,e0,0,0x77c8b58c,0x77c8b67c,0x77c8b568): stub ============== Links ============== [1] http://appdb.winehq.org/appview.php?appId=154 [2] http://appdb.winehq.org/appview.php?appId=154&versionId=2740

3 2

Recruit regression testers?
by Ivan Leo Puoti Jan. 31, 2005

Jan. 31, 2005

I think quite a few regressions get into releases, and while a few a tracked down some stay in the code for months if not years (I've heard of at least one game that worked some 2 years ago but doesn't now), while regression testing may seem trivial to a developer, it can be a challenging task for most users, especially if they are new to wine/Linux. So maybe we should recruit some people to get regression reports from users, find the patch that caused the regression, and report back to developers. Am I just to tired at time of writing or could this be a good idea? Ivan.

8 12

Re: SHLWAPI: implement PathIsValidChar{A,W}
by Juan Lang Jan. 31, 2005

Jan. 31, 2005

Hi Hans, > Yes I contemplated that but then you reintroduce a conditional in > the ascii case ( if (c > 0x7e) ), which somewhat defeats the > purpose of using a lookup table. Defeats? I don't think so. A single comparison that covers a large number of cases is different than a cascade of comparisons. Unless the compiler inlines PathIsValidCharAW, adding a comparison to PathIsValidCharA is faster than a function call anyway. > > Also, that means the data type can be unsigned char, not DWORD. > > I don't understand you, char class values are DWORD. You're right, that's my mistake. > > 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. > > It's deliberate and correct. PATH_CHAR_CLASS_OTHER_VALID *is* a mask > so I do return the same value in both cases. Also remember that the > return type is a BOOL so we could return TRUE everywhere but I chose > to mimic Windows here and return a masked value. The tests show this > is the case. I'm still not sure it's correct. What if the call is PathIsValidCharW(0x1ff, PATH_CHAR_CLASS_LETTER) ? In this case, you return PATH_CHAR_CLASS_OTHER_VALID, which is 0x00000100. On the other hand, the call PathIsValidCharW('0', PATH_CHAR_CLASS_LETTER) returns 0. Your test cases don't capture the entire behavior, because the caller's mask and the character class are the same. But what if they are different? Test cases will show which is correct, of course. I've never used the function. I was just pointing out that the behavior for characters above 0xff is different than that for characters less than or equal to 0xff. Inconsistency usually means incorrectness. --Juan __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com

1 0