- Wine-Devel - list.winehq.org

running wineboot from the server - HELP!
by Shachar Shemesh March 13, 2003

March 13, 2003

Hi, I know I promised this over three weeks ago, but things have been very busy for me lately. This email is slightly long. Please please please read through it. I need help to get wineboot working automatically (a blocking issue for 0.9), and I need someone who understands both the server and the loading order to comment. This is the first part of the required change. Applying it at the moment does not make sense, as I am not yet sure that this is the right one (it may make more sense to point the env at the .exe.so file rather than the wrapper - more about that in a second). I am, more or less, ready to give up. Someone suggested I look at the way caching the font metrics delays normal load. Well, I tried. I'm not sure I got it right, though. If I understand correctly, the way to go for wineboot to run is this: wineboot, upon first run, will aquire a system wide named mutex that means "I am working on it". If the mutex exists, it will block on it. Once it got it it will immediatly release it and exit. If the mutext doesn't exist at all, it will aquire it and do it's magic. Once done it will release it, but not delete it, and exit. All that is left to do is that all programs must load wineboot as part of the startup. It may require modifying it to be a DLL instead of an EXE, but so be it. Can someone who understands the server, and the interaction between the server and normal apps comment on this scheme? Also, how do I at all make each and every prog load wineboot.dll? Shachar -- Shachar Shemesh Open Source integration consultant Home page & resume - http://www.shemesh.biz/ Index: programs/winelauncher.in =================================================================== RCS file: /home/sun/sources/cvs/wine/programs/winelauncher.in,v retrieving revision 1.2 diff -u -r1.2 winelauncher.in --- programs/winelauncher.in 5 Jul 2002 21:18:41 -0000 1.2 +++ programs/winelauncher.in 10 Mar 2003 21:27:27 -0000 @@ -37,6 +37,7 @@ WINEBIN=@bindir@ WINELIB=@libdir@ WINESERVER= +WINEBOOT= WINEDLLPATH=@dlldir@ #------------------------------------------------------------------------------ @@ -178,12 +179,20 @@ WINESERVER=$WINEBIN/wineserver fi +if [ -x $WINEBIN/wineboot ] ; then + WINEBOOT=$WINEBIN/wineboot +fi + #------------------------------------------------------------------------------ # Hey, if we built Wine from source, let's add a little extra fun to # mix it up a bit #------------------------------------------------------------------------------ if [ -x $WINEBIN/server/wineserver ] ; then WINESERVER=$WINEBIN/server/wineserver +fi + +if [ -x $WINEBIN/programs/wineboot/wineboot ] ; then + WINEBOOT=$WINEBIN/programs/wineboot/wineboot fi if [ -r $WINELIB/dlls/ntdll.dll.so ] ; then Index: tools/winewrapper =================================================================== RCS file: /home/sun/sources/cvs/wine/tools/winewrapper,v retrieving revision 1.3 diff -u -r1.3 winewrapper --- tools/winewrapper 25 Sep 2002 03:29:56 -0000 1.3 +++ tools/winewrapper 23 Feb 2003 13:49:11 -0000 @@ -70,8 +70,9 @@ fi WINEDLLPATH="$topdir/dlls:$topdir/programs" WINESERVER="$topdir/server/wineserver" +WINEBOOT="$topdir/programs/wineboot/wineboot" WINELOADER="$topdir/miscemu/wine" -export LD_LIBRARY_PATH WINEDLLPATH WINESERVER WINELOADER +export LD_LIBRARY_PATH WINEDLLPATH WINESERVER WINEBOOT WINELOADER # any local settings ? if [ -f "$topdir/.winewrapper" ]

12 19

Anyone working on ListView?
by Vitaliy Margolen March 13, 2003

March 13, 2003

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 March 13, 2003

March 13, 2003

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 March 12, 2003

March 12, 2003

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 March 12, 2003

March 12, 2003

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 March 12, 2003

March 12, 2003

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 March 12, 2003

March 12, 2003

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 March 12, 2003

March 12, 2003

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 March 12, 2003

March 12, 2003

"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 March 12, 2003

March 12, 2003

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