- Wine-Devel - list.winehq.org

RE: Test Drive failure
by Dagan Shai Nov. 2, 2004

Nov. 2, 2004

It only generated the helloworld.exe.so file, and no others. This is the only file defined in the makefile generated by winemaker. It is listed as part of the EXES macro and not the DLLS, which is why I thought it to be an executable. Could there be some reason that no executable is generated? Shai Dagan -----Original Message----- From: Dimitrie O. Paun [mailto:dpaun(a)rogers.com] Sent: Tuesday, November 02, 2004 6:14 PM To: Dagan Shai Cc: wine-devel(a)winehq.org Subject: Re: Test Drive failure On Tue, Nov 02, 2004 at 05:53:11PM +0200, Dagan Shai wrote: > Hi, > I'm new to WINELIB. As a test drive I tried to port the Hello World > application, just to see that the environment is functioning. > I called: > winemaker --console --lower-uppercase . > In the source directory. Then I called: > make > A helloworld.exe.so file was successfully created as a result (no errors > or warnings). It should have also generated a helloworld executable file, and you should be running it as: # ./helloworld -- Dimi. ______________________________________________________________________ This email message has been scanned by PineApp Mail-Secure and has been found clean.

3 2

Re: Fix for metafile test
by Juan Lang Nov. 2, 2004

Nov. 2, 2004

Dmitry wrote: > The question is what makes the tests create invisible windows? Does > winetest run as a service on a not visible desktop? Anything else? I believe this is the reason. The shellpath tests fail on WinXP, I believe because HKCU doesn't exist because the service doesn't interact with the desktop. --Juan __________________________________ Do you Yahoo!? Check out the new Yahoo! Front Page. www.yahoo.com

1 0

Re: COM / InstallShield status
by Mike Hearn Nov. 2, 2004

Nov. 2, 2004

> Likewise, what's the current status of Installshield support, > and how much work would it be to fully support > Installshield-based installers? I don't see any > open Installshield bug reports, maybe I should file > one against the apps I have that don't install at > the moment. (Or would that be overkill?) Rob and I did some work on InstallShield for iTunes a few months ago, since then AFAIK no work has been done. Status back then was that the InstallShield 7/MSI hybrid installers worked pretty well, the bug I chased for nearly a week was refcounting related (the backend wasn't shutting down) and since that was fixed I believe it works pretty well. The other main problems I'm aware of are: - needs stdole32.tlb, we have a program to generate this in CrossOver and it needs to be pulled upstream as previously discussed. - Painting problems. I've not investigated this deeply but I'm 99% sure I know what the problem is. I've even written a patch to fix it as part of investigating iTunes, but I never tried the patch with an InstallShield that shows the issue. Apart from those two there are mostly just generic issues - InstallShield contains its own scripting language which heavily exercises the variant APIs, so it sometimes shows up problems with them. I believe Marcus found an issue with them thanks to InstallShield recently. In other words, InstallShield *should* work though it might not be pretty. There may be installers out there which don't work, I'd like to start nailing them once I get back to Wine hacking. I don't know if I'll get time however. Also, Murphy continues to smack me down w.r.t internet connection, the ISP sent me the wrong type of modem and yesterday I discovered the phone socket I was going to connect the modem to doesn't actually work :( thanks -mike

1 0

Re: wineps: better pattern brushes
by Jakob Eriksson Nov. 2, 2004

Nov. 2, 2004

Isn't 300 a bit low? Almost all lasers do 600 dpi. Huw D M Davies wrote: > Huw Davies <huw(a)codeweavers.com> > Scale the patterns so that they're rendered at 300dpi > Create the image dictionary once, rather than every time the PaintProc > is called - should speed printing up somewhat. > > >

2 1

Test Drive failure
by Dagan Shai Nov. 2, 2004

Nov. 2, 2004

Hi, I'm new to WINELIB. As a test drive I tried to port the Hello World application, just to see that the environment is functioning. I called: winemaker --console --lower-uppercase . In the source directory. Then I called: make A helloworld.exe.so file was successfully created as a result (no errors or warnings). However, when I execute this file I immediately get a segmentation fault. I tried to run it using gdb, in order to figure out what happens, and I get: Program received signal SIGSEGV, Segmentation fault. 0x00000001 in ?? () I'm sure I'm missing something simple. Can someone please point me in the right direction? Thanks, Shai Dagan

2 1

The Return of IE6 Problems
by Dan McGhee Nov. 2, 2004

Nov. 2, 2004

Hopefully, this time I have generated more specific and relevant information. I have done regressions to identify the patches that may be causing the symptoms. I have duplicated these results by using ./tools/wineinstall, make && make depends and wineprefixcreate. Although I was not able to get the help engine functional, I duplicated the IE6 not running symptom by installing IE6 manually. Additionally these symptoms are current as of a wine compiled from cvs the morning of October 30, 2004. Statement of symptoms: 1. Until the commit of 20040824 16:00:16 CDT, patch 13475, IE6, when installed using Mike Hearn's script ran and the help engine was functional. After the patch, the help engine was not functional. 2. With the commit of 20040927 15:39:42 CDT, patch 13938, IE6, installed using the script or manually, would not initialize. If I substitute system.reg and user.reg from a version of wine compiled before patch 13475 for the files of the same names in a version of wine compiled from cvs updated on the morning of 20041030, IE6 runs and the help engine is functional. The common denominator for this situation is that these patches modified some of the same files. Patch 13475 implemented itss.dll and modified wine/dlls/Makefile.in, wine/configure.ac and wine/configure. A partial implementation of advpack.RegInstall, Patch 13938 also modified wine/dlls/Makefile.in, wine/configure.ac and wine/configure in addition to adding /wine/dlls/advpack/reg.c. Although IE6 would still initialize, patch 13937 added advpack to the repository. I do not have the ability to read the changes and try to interpret them. I can only supply information that I think is relevant or for which someone specifically asks me. I have logs of installing and running IE6 before and after the patches. I have the system.reg and user.reg files also. In addtion I have diff files of the befores and afters. This is the difference between system.reg-before-patch-13475 and system.reg-after-patch-13938. This file was "egrepped" for itss|advpack: > -@="C:\\windows\\system\\itss.dll" > -@="C:\\windows\\system\\itss.dll" > -@="C:\\windows\\system\\itss.dll" > -@="C:\\windows\\system\\itss.dll" > -@="C:\\windows\\system\\itss.dll,0" > "StubPath"="rundll32.exe advpack.dll,LaunchINFSectionEx > c:\\windows\\inf\\icw.inf,PerUserStub,,36" > +"050"="rundll32.exe advpack.dll,DelNodeRunDLL32 > c:\\windows\\system\\dacui.dll" > +"054"="rundll32.exe advpack.dll,DelNodeRunDLL32 > c:\\windows\\Catroot\\icatalog.mdb" > "000"="rundll32.exe advpack.dll,LaunchINFSectionEx > c:\\windows\\system\\ieuinit.inf,BackupCryptoKeys.Win,,36" > "QuietUninstallString"="Rundll32 advpack.dll,LaunchINFSectionEx > c:\\windows\\inf\\iedom.inf,,,256" > "QuietUninstallString"="rundll32 advpack.dll,LaunchINFSectionEx > c:\\windows\\inf\\hhupdcab.inf,,,256" > "QuietUninstallString"="RunDll32 advpack.dll,LaunchINFSectionEx > c:\\windows\\inf\\icw.inf,,,256" > "QuietUninstallString"="rundll32 advpack.dll,LaunchINFSectionEx > c:\\windows\\inf\\unie5bak.inf,,,256" > "QuietUninstallString"="rundll32 advpack.dll,LaunchINFSectionEx > c:\\windows\\inf\\iereadme.inf,,,256" This is an excerpt from the difference between user.reg before and after. The whole file is 21k and I will be more than happy to supply it if someone wants the whole thing. > --- user.reg.before-13475 2004-10-25 15:56:16.000000000 -0500 > +++ user.reg.after-13938 2004-10-26 20:29:16.000000000 -0500 ................... > -[Environment] 1098735476 > +[Environment] 1098839302 > +"PATH"="c:\\windows;c:\\windows\\system;e:\\;e:\\test;f:\\" > +"Systemroot"="c:\\windows" > +"TEMP"="e:\\" > +"TMP"="e:\\" > +"USERPROFILE"="c:\\windows\\Profiles\\Administrator" > +"windir"="c:\\windows" > +"winsysdir"="c:\\windows\\system" ........................ I didn't use this section from any stance of relevance, but only to demonstrate the difference in the number strings in the [Environment] lines. 10987xxxxx changed to 10988yyyyy is typical both in the system.reg and user.reg files. This section is typical of numbers of lines either present with patch 13938 or absent with it. There are very mand "dword=.............." that are present before patch 13475 and gone after 13938. I have also attached the output of winedbg when running IE6 after patch 13938 and with the system.reg and user.reg files created from the recent version of wine. I thought that this situation could be the results of the changes in wine between now and the time that Mike Hearn wrote his script. However, I was able to duplicate the systems by installing IE6 using Method 2 from Frank's Corner. If anyone has any "hacking" they want me to try, I will be more than happy to do it. Also, if someone wants more information, I will be happy to send what I already have or generate more. Thanks, Dan

1 0

Re: Add time zone to TZ_Info
by Duane Clark Nov. 2, 2004

Nov. 2, 2004

Roger Olson wrote: > RCS file: /home/wine/wine/dlls/ntdll/time.c,v > retrieving revision 1.51 > diff -u -u -r1.51 time.c > --- dlls/ntdll/time.c 22 Oct 2004 19:54:17 -0000 1.51 > +++ dlls/ntdll/time.c 31 Oct 2004 21:18:46 -0000 > @@ -105,6 +105,9 @@ > {"AKDT", > {'A','l','a','s','k','a','n',' ','S','t','a','n','d','a','r','d',' ','T', > 'i','m','e','\0'}, 480, 1}, > + {"PST", > + {'P','a','c','i','f','i','c',' ','S','t','a','n','d','a','r','d',' ','T', > + 'i','m','e','\0'}, 480, 0}, > {"PDT", > {'P','a','c','i','f','i','c',' ','S','t','a','n','d','a','r','d',' ','T', > 'i','m','e','\0'}, 420, 1}, Hmm... I don't know if anything actually uses the names, but I doubt these are right. PDT would normally be referred to as Pacific Daylight Time. Any chance of getting you to add some tests for these?

4 4

Re: Ok, trying again
by Markus Amsler Nov. 2, 2004

Nov. 2, 2004

Hi, This patch doesn't aplly smoothly, because you did the cvs diff not from the wine-root directory. do: at ~/src/wine$ cvs diff -u dlls/msvrt/tests/file.c You can test if your patch apllies with $ patch -p0 < file.diff from the wine root. If there are no error messages the format is fine. To remove the patch do $ patch -p0 -R <file.diff I hope this helps Markus Jakob Eriksson wrote: > *src/wine/dlls/msvcrt/tests > > > * > jakov(a)toto:~/src/wine/dlls/msvcrt/tests$ cvs diff -u file.c > Index: file.c > =================================================================== > RCS file: /home/wine/wine/dlls/msvcrt/tests/file.c,v > retrieving revision 1.10 > diff -u -r1.10 file.c > --- file.c 3 Sep 2004 01:05:30 -0000 1.10 > +++ file.c 1 Nov 2004 16:24:06 -0000 > @@ -306,7 +306,25 @@ > ok(res[strlen(res)-1] != '.', "second call - last character is a > dot\n"); > } > > +static void test_access( void ) > +{ > + FILE *fp; > + > + const char filename[] = "tmpfile.tst"; > + ok(-1 == _access(filename, 0), "This file should not exist yet.\n"); > + ok(ENOENT == errno, "and errno should be ENOENT but it is %d.\n", > errno); > + > + fp = fopen(filename, "w"); > + if (NULL == fp) return; > + fclose(fp); > > + ok(0 == _access(filename, 0), "Now the file should exist.\n"); > + ok(0 == _access(filename, 2), "We should have write permission, > after all I created it. errno=%d\n", errno); > + ok(0 == _access(filename, 4), "We should have read permission. > errno=%d\n", errno); > + ok(0 == _access(filename, 6), "We should also be able to check > for read and write permission. errno=%d\n", errno); > + > + _unlink(filename); > +} > > START_TEST(file) > { > @@ -321,6 +339,7 @@ > return; > } > > + test_access(); > test_fdopen(); > test_fileops(); > test_fgetwc(); > > >

1 0

Re: Edit - wants all keys when multiline
by Dmitry Timoshkov Nov. 1, 2004

Nov. 1, 2004

"Vitaliy Margolen" <wine-patch(a)kievinfo.com> wrote: > @@ -761,6 +761,12 @@ > > case WM_GETDLGCODE: > result = DLGC_HASSETSEL | DLGC_WANTCHARS | DLGC_WANTARROWS; > + > + if (GetWindowLongW( hwnd, GWL_STYLE ) & ES_MULTILINE) > + { > + result |= DLGC_WANTALLKEYS; EDITSTATE structure already has the 'style' member for the optimization sake, so please use it instead of GetWindowLong(GWL_STYLE). > + r = SendMessage(hwEdit, WM_GETDLGCODE, 0, (LPARAM) &msMessage); > + ok(r==0x89, "Expected DLGC_WANTCHARS | DLGC_HASSETSEL | DLGC_WANTARROWS got %x\n", r); Do not use 0x89 and similar cryptic values in the test, use appropriate symbolic constants instead. And please merge your test into existing win.c tests. -- Dmitry.

3 2

Listview notify_dispinfoT Messageformat
by Thorsten Kani Nov. 1, 2004

Nov. 1, 2004

Hello, Testing showed that the current implementation of notify_dispinfoT doesnt work with W2K. (or at least not with SP4 (: ) The attached patch corrects that our Listview doesnt display anything on native. Following assumption proved to be wrong for the Message LVN_GETDISPINFOW: /* With testing on Windows 2000 it looks like the notify format has nothing to do with this message. It ALWAYS seems to be in ansi format. */ This time, only LVN_*ETDISPINFOW is patched, anything else is untouched. -Anybody please tell me if you see problems with this Fix since i dont want to break things.- Tho

3 8