August 2003 - Wine-devel - list.winehq.org

IPersistFile::Load() broken ? + WineLib queries
by Subhobroto Sinha 21 Aug '03

21 Aug '03

Respected members of the forum, I have a few queries, which I have tabulated under: First: (1) With Windows apps doing smoothly on Wine, I had thought of creating a little program which would resolve Windows shortcut (.lnk) files. The program behaved perfectly with NO glitches whatsoever with the Wine package of <20030217-23> which came with my SuSE 8.2 as RPM. I had also downloaded the Wine20030408 tarball, which I duly patched upto v20030813 (the latest), removed the installed RPM package and wineinstalled the source for Wine20030813. (The improvements made was immediately apparent, and I could run Norton 2000 Update Agent as well as install my own .msi packages !) However, my program (which resolved shortcuts) failed to work anymore ! Previously, to compile the source using WineLib(from Wine<20030217-23>) I had to make the following changes in my source code: (1) Replace IShellLink with IShellLinkA (2) Include the header "shlguid.h" With the latest WineLib(from Wine20030813), I did NOT have to make ANY changes to the original source however, but though the source compiled without any issues, it failed at the IPersistFile::Load() call ! To make debugging easier for you folks, I have prepared a ZIP Package called "WineShellDriverPak.zip" which contains the following software: (1) The source code "WineShellDriver.cpp" . (This compiles on VC6 AND WineLib without ANY modification) (2) The VC6 compiled EXE file "WineShellDriver.EXE". To make this program work, just pass the .lnk filename as command line arg, and if successful, it will write out the resolved path in a text file called "WineWorksResolvedPath.dat" (This ALSO failed to work under Wine20030813) (3) The previous "working" (it does NOT work anymore..) WineLib form ("linkresolve.exe.so") of this code. This had been compiled using Wine<20030217-23> which came with SuSE 8.2. It used to work fine. (4) A shortcut (Notepad.lnk) file for testing. It should resolve to "C:\WINNT\notepad.exe" Is it due to a BUG in the latest release, or did I do something wrong ? Second: (2) How do I REDUCE the size of WineLib compiled apps ? Those source code which compile to ~35KB using VC6, compile to ~900KB using WineLib. Currently, I have to "strip" the WineLib compiled apps, but often, this breaks them ! Any suggestions ? (3) How do I log the output to a file say "Winelog.log" of a command like: "$ wine --debugmsg +all winelibapp.exe.so -- commandline args" Redirection (>>) or pipes (|less) only captues the output given by "winelibapp.exe.so" and NOT that given by Wine. (I currently run Wine from the commandline using XTerm) Thank you for your time. Please keep up the good work ! Cheers Subhobroto Sinha ---------------------------- Help us to free ourselves! __________________________________ Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software http://sitebuilder.yahoo.com

2 1

Re: [Foxgui-users]Re: Wine fixes (1)
by Dimitrie O. Paun 21 Aug '03

21 Aug '03

On August 21, 2003 12:07 am, jeroen wrote: > > Ha! Well, I can't say that I disagree with you; however, if you're > actually shipping applications for Windows, you'd better test on the > real thing..... One thing the emulation won't tell you is whether > any oddball device driver issues crop up. This particularly happens > with OpenGL. I have had to add special directives to avoid hardware > accelerated OpenGL on Windows so that broken drivers may be circumvented. > > Interactions with other applications also must be tested; for example, > clipboard support. You will discover the weirdest things... It's a nice compliment (thank you!) to assume that Wine is such a good implementation of the Win32 API that one would assume to do no testing on Windows :) Unfortunately, we haven't gone that far (yet ;) ). Wine is good enough at the moment to allow for some development, but you will definitely run into problems, and you _will_ need to test the result on Windows, as you say. But regardless of utility, I still maintain a Wine port would be cool :) -- Dimi.

1 0

Re: PATCH - winnt.h move non-standard language IDs to wine/port.h
by Jonathan Wilson 21 Aug '03

21 Aug '03

Looks good. This should enable apps like notepad to build out of the box on win32 with MingW or VC headers assuming port.h is copied over.

1 0

IPersistFile::Load() broken ? + WineLib queries
by Subhobroto Sinha 21 Aug '03

21 Aug '03

Respected members of the forum, I have a few queries, which I have tabulated under: First: (1) With Windows apps doing smoothly on Wine, I had thought of creating a little program which would resolve Windows shortcut (.lnk) files. The program behaved perfectly with NO glitches whatsoever with the Wine package of <20030217-23> which came with my SuSE 8.2 as RPM. I had also downloaded the Wine20030408 tarball, which I duly patched upto v20030813 (the latest), removed the installed RPM package and wineinstalled the source for Wine20030813. (The improvements made was immediately apparent, and I could run Norton 2000 Update Agent as well as install my own .msi packages !) However, my program (which resolved shortcuts) failed to work anymore ! Previously, to compile the source using WineLib(from Wine<20030217-23>) I had to make the following changes in my source code: (1) Replace IShellLink with IShellLinkA (2) Include the header "shlguid.h" With the latest WineLib(from Wine20030813), I did NOT have to make ANY changes to the original source however, but though the source compiled without any issues, it failed at the IPersistFile::Load() call ! To make debugging easier for you folks, I have prepared a ZIP Package called "WineShellDriverPak.zip" which contains the following software: (1) The source code "WineShellDriver.cpp" . (This compiles on VC6 AND WineLib without ANY modification) (2) The VC6 compiled EXE file "WineShellDriver.EXE". To make this program work, just pass the .lnk filename as command line arg, and if successful, it will write out the resolved path in a text file called "WineWorksResolvedPath.dat" (This ALSO failed to work under Wine20030813) (3) The previous "working" (it does NOT work anymore..) WineLib form ("linkresolve.exe.so") of this code. This had been compiled using Wine<20030217-23> which came with SuSE 8.2. It used to work fine. (4) A shortcut (Notepad.lnk) file for testing. It should resolve to "C:\WINNT\notepad.exe" Is it due to a BUG in the latest release, or did I do something wrong ? Second: (2) How do I REDUCE the size of WineLib compiled apps ? Those source code which compile to ~35KB using VC6, compile to ~900KB using WineLib. Currently, I have to "strip" the WineLib compiled apps, but often, this breaks them ! Any suggestions ? (3) How do I log the output to a file say "Winelog.log" of a command like: "$ wine --debugmsg +all winelibapp.exe.so -- commandline args" Redirection (>>) or pipes (|less) only captues the output given by "winelibapp.exe.so" and NOT that given by Wine. (I currently run Wine from the commandline using XTerm) Thank you for your time. Please keep up the good work ! Cheers Subhobroto Sinha ---------------------------- Help us to free ourselves! __________________________________ Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software http://sitebuilder.yahoo.com

1 0

Can someone take a look at msvcmaker for me?
by Steven Edwards 21 Aug '03

21 Aug '03

I have tried using MSYS perl and ActiveState perl and both give me the following error: isolation(a)PH33R /g/src/wine-dev/wine $ ./tools/winapi/msvcmaker Global symbol "$wine_dir" requires explicit package name at ./tools/winapi/msvcm aker line 52. Global symbol "$wine_dir" requires explicit package name at ./tools/winapi/msvcm aker line 116. Global symbol "$wine_dir" requires explicit package name at ./tools/winapi/msvcm aker line 440. Global symbol "$wine_dir" requires explicit package name at ./tools/winapi/msvcm aker line 1031. Global symbol "$wine_dir" requires explicit package name at ./tools/winapi/msvcm aker line 1091. Global symbol "$wine_dir" requires explicit package name at ./tools/winapi/msvcm aker line 1141. Global symbol "$wine_dir" requires explicit package name at ./tools/winapi/msvcm aker line 1180. Global symbol "$wine_dir" requires explicit package name at ./tools/winapi/msvcm aker line 1217. Global symbol "$wine_dir" requires explicit package name at ./tools/winapi/msvcm aker line 1234. Execution of ./tools/winapi/msvcmaker aborted due to compilation errors. isolation(a)PH33R /g/src/wine-dev/wine

1 0

Re: patch 6
by puoti＠inwind.it 21 Aug '03

21 Aug '03

My email will never change. My email provider is the biggest in Italy, and it's very improbable that it will ever close, and even if I don't use it as an ISP any more, I will never change my email until I can use my current one. Of course, if you don't want email addresses in the source, just ignore that part of the patch.

1 0

Re: Build broken due to -lpthread
by Gerald Pfeifer 21 Aug '03

21 Aug '03

On Thu, 21 Aug 2003, Ulrich Spoerlein wrote: >> So perhaps we ought to use -lc_r instead of -lc and omit -lpthread on >> FreeBSD (or use -pthread)? > The "best" solution IMHO would be to have configure look for -lpthread > and put the value into @PTHREAD_LIBS(a). Then the Wine port can just > s/-lpthread/${PTHREAD_LIBS}/g configure in the post-patch-target Please keep in mind that Wine should build as is (in CVS) without any FreeBSD-specific changes. I have been investing a lot of time and effort to reach that state and would like to keep it that way (and Alexandre agrees with that, as far as I know). As far as I can see, the ideal approach might be: o Check whether -lphtread exits/works and use it only, if it does. o Check whether -lc_r exists/works, and if it does, use that instead of -lc. These two are independent, and should work in general, that is, portably. Gerald -- Gerald Pfeifer (Jerry) gerald(a)pfeifer.com http://www.pfeifer.com/gerald/

1 0

Re: patch 6
by Alexandre Julliard 21 Aug '03

21 Aug '03

"puoti\(a)inwind\.it" <puoti(a)inwind.it> writes: > Added my email next to my name in cmdlgtst /It.rc It's better to avoid putting email addresses in source files, they quickly become obsolete and nobody ever bothers to update them. Just put your name there, and people who want to mail you can look up your most recent address in the Changelog. -- Alexandre Julliard julliard(a)winehq.com

1 0

RFC: evolution of file management
by Eric Pouech 21 Aug '03

21 Aug '03

in the process of separating ntdll from kernel32, one of the next hurdle if the implementation of NtCreateFile. Since it's rather a core API, some thoughts are needed. Moreover, there are a few shortcomings in current file handling we might want to address. The goal of this small RFC is to: 1/ gather all known shortcomings of current file implementation 2/ propose some solutions and roadmaps for the implementation feel free to add your own remarks to these lists. 1/ shortcomings --------------- 1.1) no dynamicity in DOS drive management: user should be able, in his/her session(1), to either change the mapping of a DOS drive letter, or mount a SMB share somewhere...) 1.2) mounting should be done session wide and not process wide, and of course shared across processes 1.3) ntdll and kernel32 are not separated regarding file management 1.4) devices (vxd and DOS) management is still a hack 1.5) it may be necessary to introduce a notion of filesystem for some operations (open, read, write, seek, close, dir_enum, ioctl) in order to support several FS (unix, smb...) 1.6) poor management of ejectable devices 1.7) short/long file name conversion should be consistent (across several processes in the same session, across several sessions) Note: (1) a session is linked to a running instance of the wineserver 2/ proposal ----------- 2.1 "path gates" (target: 1.1, 1.2, 1.3/partly, 1.4/partly, 1.6/partly) all file names will be handled using the NT-style: + DOS paths (C:\foo\bar) into \??\C:\foo\bar + network paths (\\station\foo\bar) into \??\UNC\station\foo\bar + DOS device names (CON) into \??\CON + NT device names (\\.\PhysicalDrive0) into \??\PhysicalDrive0 + a VXD ?? (normally \\.\VFD) into \??\VFD the device concept will disappear and be replaced by a "path gate": in NT-Win32 name space, point where to convert from a NT-path to a Unix-path for example, assuming we have created a path-gate from \\??\c: to /mnt/windows, the NT-path \\??\c:\foo\bar will be transformed into the unix-path /mnt/windows/foo/bar the path-gate will hold the current options that the device currently does (case sensivity, fixed/removable...) path-gates will be stored in the server (they are session wide) management of VxD and devices could benefit from it: they could be path gates pointing to them selves (or nothing ?) 2.2 FS (target: 1.4/partly, 1.5/partly, 1.6/partly) I'm still wondering if we really need a FS (even a very simplistic one) in Wine 2.3 short/long file names (target 1.7) since current short file name management seems satisfactory, there's no need IMO to move short/long names conversion in the server -- Eric Pouech

5 8

GetLastError strangeness with FindClose
by Alex Pasadyn 21 Aug '03

21 Aug '03

Hi all, I observed a program that was bailing out with an absolutely baffling error message. I have traced it to its cause, but now I'm stuck. Basically, it was telling me that it had an error in FindNextFile of "success". I did a relay trace and found out that it was calling FindFirstFile, FindNextFile a bunch of times, FindClose, and then GetLastError. So, I put together a little test: #include <windows.h> #include <stdio.h> WIN32_FIND_DATA fd; HANDLE h; int main(int argc, char *argv[]) { h = FindFirstFile("*", &fd); if (h == INVALID_HANDLE_VALUE) { printf("Error finding first file: %d\n", GetLastError()); return 1; } printf("found file: %s\n", fd.cFileName); while (FindNextFile(h, &fd)) { printf("found file: %s\n", fd.cFileName); } FindClose(h); switch (GetLastError()) { case ERROR_NO_MORE_FILES: printf("all done!\n"); return 0; default: printf("Error finding next file: %d\n", GetLastError()); return 1; } return 1; } Now, on Windows, the output is: G:\testfnf>testfnf found file: . found file: .. found file: testfnf.cpp found file: testfnf.exe all done! And with Wine the output is: [ajp(a)toaster testfnf]$ ~/wine/wine testfnf.exe found file: . found file: .. found file: testfnf.cpp found file: testfnf.exe Error finding next file: 0 So, it looks like somewhere in FindClose Wine is resetting the last error. I started digging through there and the functions it calls but I was unable to find where it was getting reset. Can anyone shed some light on this? Is there any way to break on that value changing? Thanks, -ajp

6 10