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

Anyone working on ListView?
by Vitaliy Margolen 13 Mar '03

13 Mar '03

I was wondering is there is anyone working on ListView? The reason I ask? I got ACDSee 3.1 installed (see my last patch about typo) & working (well, sort of). It looks like ACDSee depends heavily relies on functionality which is missing from ListView. My question is: if I'll start hacking ListView will I be interfering with someone else's work? FYI: ACDSee - if not the best, for sure one of the best image viewers. Version 3.1 could be ran in "Sponsored mode" indefinitely as long as it connects to the I-net to get messages & banners. -- Best regards, Vitaliy Margolen

3 8

Re: Few fixes for ListView
by Dimitrie O. Paun 13 Mar '03

13 Mar '03

On March 13, 2003 01:53 am, Vitaliy Margolen wrote: > - y = (LONG)DPA_GetPtr(infoPtr->hdpaPosX, i); > + y = (LONG)DPA_GetPtr(infoPtr->hdpaPosY, i); Duh! Good spotting, I just looked at it yesterday, and I did not see it. Funny how you see what you want to see... :) -- Dimi.

1 0

Wine Makefile for Charles Petzold's Example Programs
by Dimitrie O. Paun 12 Mar '03

12 Mar '03

Hi folks, For the past few weeks, I've been working with John Kopplin on getting the Petzold examples compiling under Wine using his Gnu Makefile package, available from: http://www.computersciencelab.com/Petzold.htm It took some work, but we've done it. The good news is that all (but 3) examples compile just fine. This has been accomplished while making absolutely _no_ changes to the original source, and very few (and obvious) changes to the GNU Makefiles. This is very good news, as it shows we can have a common build system between Wine and Windows. The only samples that don't work just yet are those from Chap21 which build DLLs, and DLL creation is yet not supported by winegcc. I hope this will change in the near future. The problems that needed fixing were very simple, and quite obvious. They fall into 2 categories: 1. The samples expect to link with the msvcrt, not the Unix libc, so we had to pass the -mno-cygwin flag to the compiler/linker. Under mingw this is the default behaviour. This change is actually beneficial for the Windows port as well, as it will allow the samples to be build using Cygwin's gcc also. As such, it should be considered a portability fix, rather than a Wine specific fix. 2. The filnames used mixed case (not matching the actual name on disk), and some includes use backslash (\), intead of forward slash (/). This problem is typical and simple to address in a portable manner if you can modify the source. As we wanted to not touch the examples in any way, we had to find another way around it. Luckily, Unix accepts virtually any char in a filename (except / of course), as well as links. So we just created the appropriate symbolic links where necessary, or just renamed the file if it made more sense. All these renames / symlinks creation was collected in a nice little intallation script. So, without further delay, here are the instructions on how to try the sample under Wine. (place the Petzold CD in the CDROM drive) $ mount /mnt/cdrom $ mkdir petzold $ cd petzold $ cp -r /mnt/cdrom/* . $ wget http://www.computersciencelab.com/Petzold.zip $ unzip -a Petzold.zip $ bash Wine/install.sh $ make Enjoy! -- Dimi. P.S. As usual, comments, suggestions, and/or flames are more than welcomed!

1 0

Mutual Debugging Efforts
by James 12 Mar '03

12 Mar '03

Hi folks, I've installed Wine RPM from RH 8.0. _*Very*_ impressed with the goal, and the progress so far! (Red Hat seem only to offer an RPM of the 20020605 version, so I am hoping they'll release a newer one soon.) In trying to get applications working, I have a small number of tips, workarounds, queries about peculiar Wine behaviour, and so forth. I can't find anything relevant in the Codeweavers 'zilla database, but I'm not sure I've been very successful at asking the right questions anyway ;) Is this a reasonable place to present my findings and/or ask if others have encountered similar issues? The issues are application-related, but they often seem to be related to Wine configuration and/or anomalies (?bugs) so that's why I tried this mailing list first. (I can't get to a news feed at the moment.) -- Thanks in advance, James.

5 8

cvs and bugzilla down?
by Tony Lambregts 12 Mar '03

12 Mar '03

Is it just me... cvs diff etc gives me "Unknown host cvs.winehq.com." I have the same problem with http://bugs.winehq.com and .org. The thing is that I can see other people using Bugzilla. -- Tony Lambregts

4 6

Re: pthreads and mono
by Alexandre Julliard 12 Mar '03

12 Mar '03

Dan Kegel <dank(a)kegel.com> writes: > I wonder if it's time to consider what it would > take to truly and completely integrate winethreads > and glibc threads, to allow unfettered use of > linux shared libraries from winelib programs. That's basically what the pthreads routines in Wine are for, they provide wrappers so that pthreads calls in linux shared libraries do the right thing. We'll probably need a somewhat different implementation for the NPTL version but the idea is the same. Not every pthreads function is implemented at the moment but it wouldn't be a big deal to add the missing ones. -- Alexandre Julliard julliard(a)winehq.com

2 1

RE: SHFileOperation - add ChangeNotify events
by Rolf Kalbermatter 12 Mar '03

12 Mar '03

Hi, > The main reason why I made this patch is to make our software package work under > WINE. Our application was heavily relies on correct behavior of SHFileOperation > function. In particular: > 1. User confirmation for deleting files and folders. > 2. Ability to delete files only in any given directory. > 3. Receiving notifications for every operation to refresh screens properly. I'm going to check those things. I know that file movements did not implement SHChangeNotification, mainly because I wanted to check first that they really got genereated in Windows native. Do you mean in 2) that the user can acknowledge every single directory to be deleted? Mmmh, thinking about it I see that Windows allows to select 4 different buttons to delete all, only this, this not or cancel. Well this is sort of involved but can be implemented. > In the patch from 2/20/2003 only (1) was implemented properly. > > Yes, I could hack that patch and make it work but I used existing code as a basis > since it implements _all_ functionality of SHFileOperation except unicode. That is not exactly true. The rename operation is not fully implemented in the current code as well as some of the operations with multiple file names. > >>+/************************************************************************ > >>+ * Win32DeleteFile [SHELL32.164] > >>+ * > >>+ * Deletes a file. Also triggers a change notify if one exists. > >>+ * > >>+ * NOTES: > >>+ * Verified on Win98 / IE 5 (SHELL32 4.72, March 1999 build) to be ANSI. > >>+ * This is Unicode on NT/2000 > >>+ */ > >>+static BOOL Win32DeleteFileA(LPCSTR fName) > >>+{ > >>+ LPITEMIDLIST Pidls[1]; > >>+ DWORD dummy; > >>+ > >>+ TRACE("%p(%s)\n", fName, fName); > >>+ > >>+ SHILCreateFromPathA(fName, &Pidls[0], &dummy); > >>+ DeleteFileA(fName); > >>+ SHChangeNotify(SHCNE_DELETE, SHCNF_IDLIST, Pidls[0], NULL); > >>+ SHFree(Pidls[0]); > >>+ return TRUE; > >>+} > > The addition of SHILCreateFromPathA/W to all of these functions is superfluous > > since SHChangeNotify does this for you anyhow if you pass in a normal string > > path. So your patch adds in this respect nothing besides of duplicating already > > existing code. > Not in the placed I used this function. It is impossible to create PIDL from non-existing > path. This fact verified on windows. Whenever I tried to create PIDL of deleted file, > Windows was returning error. This means we have to get PIDL _before_ removing file. > Same goes for renaming files. > > So, after a file gets deleted it's path is no longer valid. What was happening is > application was getting notification that whole drive was deleted! Mmh, we have to investigate further in Windows. Because the Win32... functions itself in W2K do actually not take this precaution and appearently assume that SHChangeNotify does the proper action. So either W2K does something else somewhere or the Wine SHChangeNotify function is broken in that it should be able to create notifications even for just deleted directory and file paths. I guess the later as MSDN mentions nothing that the parameter needs to be an IDLIST instead of a path for those operations but rather explicitedly mentions that SHCNF_PATH is allowed for SHCNE_DELETE, SHCNE_RENAME, SHCNE_RMDIR and such. > > Also please note that there is another patch to SHFileOperation from 2/20/2003 > > pending which reimplements this function from scratch up with a different > > algorithme, which implements all of the operations and is quite thorougly > > verified to behave in all major aspects exactly like the Windows 98/2000 > > version of this function, which one can't fully say of the current function > > in Wine. It happens to use internally also additionally implemented functions > > which also set the according SHChangeNorify in most places. > > I tried using that patch before doing any hacking on my own. It fails at least half > of the conformance tests. I tried to fix few things with that patch but some will > require significant changes. And I didn't want to go that far - working on a patch > which is not even applied. I'm going at the moment through these tests and am also trying to add more tests as well, just need to get my development machine reinstalled first after a HD crash. The tests done before where not the conformation tests but some rather involved tests with multiple shell scripts doing all types of tests for the different file operations. They did indeed not test the user dialogs at all (as they were designed to be unattended tests to run and also the SHChangeNotifiers were not tested either as I wanted to find out first if they were actually done at all. I still intend to get the patch(es) to SHFileOperation applied if possible, but also want to make sure it doesn't break your application at all. Are you interested to get eventual new patches sent directly as they get verified? Rolf Kalbermatter

2 1

Re: (5th) Janitorial dlls/advapi32/registry.c W->A cleanup
by Dmitry Timoshkov 12 Mar '03

12 Mar '03

"Tony Lambregts" <tony_lambregts(a)telusplanet.net> wrote: > -IMPORTS = kernel32 ntdll > +IMPORTS = kernel32 ntdll user32 I'm not sure Alexandre will like it. Until for now, creation of the circular dependencies were prohibitted. Probably it's better to use swprintf from ntdll, or a set of calls strcpyW/ntdll._ultow/strcatW. > -LONG WINAPI RegSaveKeyW( HKEY hkey, LPCWSTR file, LPSECURITY_ATTRIBUTES sa ) > +LONG WINAPI RegSaveKeyA( HKEY hkey, LPCSTR file, LPSECURITY_ATTRIBUTES sa ) > { > - LPSTR fileA = HEAP_strdupWtoA( GetProcessHeap(), 0, file ); > - DWORD ret = RegSaveKeyA( hkey, fileA, sa ); > - if (fileA) HeapFree( GetProcessHeap(), 0, fileA ); > - return ret; > + > + UNICODE_STRING *fileW = &NtCurrentTeb()->StaticUnicodeString; > + STRING fileA; > + > + if (!file || !*file) > + { > + SetLastError(ERROR_PATH_NOT_FOUND); > + return FALSE; As Alexandre has already pointed out, registry APIs are supposed to not change last error value. > + } > + > + RtlInitAnsiString(&fileA, file); > + RtlAnsiStringToUnicodeString(fileW, &fileA, FALSE); > + if (fileW) return RegSaveKeyW(hkey, fileW->Buffer, sa); > + return FALSE; fileW is always not NULL, so, there is no need to check it. What you really need to check is a return value of RtlAnsiStringToUnicodeString. -- Dmitry.

3 6

pthreads and mono
by Mike Hearn 12 Mar '03

12 Mar '03

Hi, I'd just like to double check - will Alexandres new threading work allow Wine to be linked into a program that uses pthreads ok? In particular, the Mono guys are wondering... they were thinking of shipping a modified libwine and all kinds of things that sound bad, so it'd be good to know whether the NPTL implemention sorts this out thanks -mike -- Mike Hearn <m.hearn(a)signal.qinetiq.com> QinetiQ - Malvern Technology Center

5 10

BeOS
by George D.Plymale 12 Mar '03

12 Mar '03

Out of curiosity, has Wine ever been made to work under BeOS? I know some work was done long, long ago when BeOS was still "alive" but I wasn't sure if anything more had ever happened or changed since the news on http://bewine.loungenet.org. Thanks.

2 1