Re: WineHQ: Janitorial update
Hi Dimitrie, On Friday 22 April 2005 05:47, Dimitrie O. Paun wrote: ChangeLog ... Some W-A warnings are invalid. While you're at it, I think the CryptAcquireContextW W-A call in advapi32/crypt.c should also be considered an invalid warning. CryptAcquireContext calls the CSP dll's CPAcquireContext function, which is only present as an ASCII version. Thus, if we would get rid of this W-A call, we would get an A-W-A conversion chain in case of CryptAcquireContextA. Bye, -- Michael Jung [EMAIL PROTECTED]
Re: windows file dialogs with unix file path
Hi Troy, On Friday 22 April 2005 00:56, Troy Rollo wrote: On Thu, 21 Apr 2005 17:53, Michael Jung wrote: The functions, which do unix to wine path conversion, would try to find a path starting from a wine drive letter and if none is found, would pass through the unix path. I don't like this idea. Aside from the fact that it would slow everything down when using a UNIX path, you have case sensitivity issues (UNIX paths should be case sensitive, Windows paths should not). An app should know at compile time the path is a UNIX path or a Windows one anyway. As this is something only a WineLib app should care about it seems to me that a deterministic compile time solution is better than an heuristic run time solution. That's a good point about the heuristic. So probably unix paths should just be passed through, without searching for a valid drive letter based wine path. This would also cleanly separate case sensitive path names from case insensitive ones. (I'm assuming, but am not quite sure of, that there is a cheap and robust way to distinguish unix paths from windows paths just by inspecting the string. Might be hard especially for relative paths.) I think it would be cool if unix paths would be available to non WineLib apps also: 1.) There might be applications, which treat filenames as opaque objects and just happen to work with unix paths. 2.) People, who write Win32 programs might have wine in mind and build their programs to work with unix-paths, without going all the way to port their apps to WineLib (I do have a bunch of source code for Borland OWL based apps. They work fine with wine, but it doesn't seem easy to me to port these to gcc/WineLib.) Bye, -- Michael Jung [EMAIL PROTECTED]
Last call for PGP key signing party
Hi all, This is your last chance to get your very own PGP key signed by your community. So far, we have 6.5 participants (hoping to get it to 7 by tomorrow). This means 7 brand new signatures on your PGP key. Read the previous announcement (http://www.winehq.org/hypermail/wine-devel/2005/04/0057.html and http://www.winehq.org/hypermail/wine-devel/2005/04/0084.html) for details on what you need to do. New submissions should be possible to get right up to the party itself, assuming I can get our hosts to lend me the use of a printer (Will you?). Thanks, Shachar -- Shachar Shemesh Lingnu Open Source Consulting ltd. Have you backed up today's work? http://www.lingnu.com/backup.html
Re: USB status ...Who maintains wineserver?
I think it might be Alexander, and I think the general suggestion was avoid changes to the wineserver. Anyone else know? I'll point out to you once again that Wine is not the right place to implement drivers. Drivers that are loaded in the kernel in Windows also belong in the kernel in Linux, not in Wine. Wine cannot present a driver interface to the rest of the system, nor to other programs. If you want to get a scanner going, the best way would be to make it work with SANE or V4L, and then get SANE or V4L to work with Wine's still imaging interface. That is much better than getting it to only work in Wine, as other applications will be able to use it via SANE, etc. Have a look at the work that Maarten Lankhorst is doing on Web cameras ... he's doing things the right way. You can continue trying to modify CreateFile, ReadFile, WriteFile etc. to make it work, but you'll realize sooner or later that a handle is tied to a unix fd. This is by design. Alexandre has said time and time again that he considers Wine to be just like any other application on the system; it reads file through the 'nix FS, and through unix file descriptors. If you still want to loader the Windows driver, go and have a look at ndis wrapper. http://ndiswrapper.sourceforge.net/ If you *still* insist that you're going to load drivers in Wine, then don't be suprised if your patches are quietly dropped, and your requests for help are quietly ignored. Mike
Re: Win16 programs and Wine internal messages
Alexandre Julliard wrote:
Richard Cohen [EMAIL PROTECTED] writes:
Closing Win16 programs using the Window manager doesn't work any more,
because 16 bit programs don't recognize the WINE internal messages, so
they don't get processed.
This should be fixed now.
Almost. In PeekMessageW, the message should be removed before handling it
if (msg.message 0x8000)
{
-- handle_internal_message( msg.hwnd, msg.message, msg.wParam,
msg.lParam );
if (!(flags PM_REMOVE)) /* have to remove it explicitly */
-- peek_message( msg, msg.hwnd, msg.message, msg.message,
GET_MSG_REMOVE );
}
In 16bit SkiFree (again!), handle_internal_message() leads to
PostQuitMessage() DefWindowProc(WM_NCDESTROY), which calls
queue_cleanup_window in wineserver, which clears the queue of messages
for the window. So, when peek_message is called again it removes
WM_QUIT, which therfore never gets returned to the app.
Perhaps handling of internal messages should even be moved into
peek_message?
Richard.
shell32/shflder_unixfs: Use shell kind ITEMIDLISTs
This silences some ERROR messages when browsing in the namespace extension and
allows to apply shell32's helper functions.
Changelog:
Use the shell32 typical binary format for ITEMIDLISTs.
Bye,
--
Michael Jung
[EMAIL PROTECTED]
Index: dlls/shell32/shfldr_unixfs.c
===
RCS file: /home/wine/wine/dlls/shell32/shfldr_unixfs.c,v
retrieving revision 1.4
diff -u -p -r1.4 shfldr_unixfs.c
--- dlls/shell32/shfldr_unixfs.c 13 Apr 2005 11:01:10 - 1.4
+++ dlls/shell32/shfldr_unixfs.c 22 Apr 2005 12:38:32 -
@@ -35,6 +35,7 @@
#include shell32_main.h
#include shfldr.h
#include shresdef.h
+#include pidl.h
WINE_DEFAULT_DEBUG_CHANNEL(shell);
@@ -43,6 +44,51 @@ const GUID CLSID_UnixFolder = {0xcc702eb
#define ADJUST_THIS(c,m,p) ((c*)(((long)p)-(long)(((c*)0)-lp##m##Vtbl)))
#define STATIC_CAST(i,p) ((i*)p-lp##i##Vtbl)
+/* FileStruct reserves one byte for szNames, thus we don't need to
+ * alloc a byte for the terminating '\0' of 'name'. Two of the four
+ * additional bytes are for SHITEMID's cb field. One is for IDLDATA's
+ * type field. One is for FileStruct's szNames field, to terminate
+ * the alternate DOS name, which we don't use here.
+ */
+#define SHITEMID_LEN_FROM_NAME_LEN(n) (sizeof(USHORT)+sizeof(PIDLTYPE)+sizeof(FileStruct)+(n)+sizeof(char))
+#define NAME_LEN_FROM_LPSHITEMID(s) (((LPSHITEMID)s)-cb-sizeof(USHORT)-sizeof(PIDLTYPE)-sizeof(FileStruct)-sizeof(char))
+
+/**
+ * UNIXFS_build_shitemid [Internal]
+ *
+ * Builds a shell item for the given path. Only the part of the path up to the
+ * next '/' or to the end of the string is considered. Don't forget do append a
+ * 0 ushort value, if what you need is a ITEMIDLIST with a single entry.
+ *
+ * The signature of this function will change in the future. Better documentation
+ * to follow.
+ */
+static const char* UNIXFS_build_shitemid(const char *name, void *buffer) {
+LPPIDLDATA pIDLData;
+int cNameLen;
+char *pSlash;
+
+TRACE((name=%s, buffer=%p)\n, debugstr_a(name), buffer);
+
+pSlash = strchr(name, '/');
+cNameLen = pSlash ? pSlash - name : strlen(name);
+
+memset(buffer, 0, SHITEMID_LEN_FROM_NAME_LEN(cNameLen));
+((LPSHITEMID)buffer)-cb = SHITEMID_LEN_FROM_NAME_LEN(cNameLen) ;
+
+/* Other than the type and the name those are dummy values for now. More to come.
+ */
+pIDLData = _ILGetDataPointer((LPCITEMIDLIST)buffer);
+pIDLData-type = PT_FOLDER;
+pIDLData-u.file.dwFileSize = 0;
+pIDLData-u.file.uFileDate = 0;
+pIDLData-u.file.uFileTime = 0;
+pIDLData-u.file.uFileAttribs = 0;
+memcpy(pIDLData-u.file.szNames, name, cNameLen);
+
+return pSlash ? pSlash+1 : (name + cNameLen);
+}
+
/**
* UNIXFS_path_to_pidl [Internal]
*
@@ -59,10 +105,10 @@ const GUID CLSID_UnixFolder = {0xcc702eb
* ending with a slash ('/'). Currently, only directories (no files)
* are accepted.
*/
-static BOOL UNIXFS_path_to_pidl(char *path, LPITEMIDLIST *ppidl) {
+static BOOL UNIXFS_path_to_pidl(const char *path, LPITEMIDLIST *ppidl) {
LPITEMIDLIST pidl;
int cSubDirs, cPidlLen;
-char *pSlash, *pSubDir;
+const char *pSlash;
TRACE(path=%s, ppidl=%p, debugstr_a(path), ppidl);
@@ -71,38 +117,25 @@ static BOOL UNIXFS_path_to_pidl(char *pa
/* Count the number of sub-directories in the path */
cSubDirs = 0;
-pSlash = strchr(path, '/');
+pSlash = path;
while (pSlash) {
cSubDirs++;
pSlash = strchr(pSlash+1, '/');
}
-/* Allocate enough memory to hold the path */
-cPidlLen = strlen(path) + cSubDirs * sizeof(USHORT) + sizeof(USHORT);
+/* Allocate enough memory to hold the path. The -cSubDirs is for the '/'
+ * characters, which are not stored in the ITEMIDLIST. */
+cPidlLen = strlen(path) - cSubDirs + cSubDirs * SHITEMID_LEN_FROM_NAME_LEN(0) + sizeof(USHORT);
*ppidl = pidl = (LPITEMIDLIST)SHAlloc(cPidlLen);
if (!pidl) return FALSE;
-/* Start with a SHITEMID for the root directory */
-pidl-mkid.cb = 3;
-pidl-mkid.abID[0] = '/';
-pidl = ILGetNext(pidl);
-
-/* Append SHITEMIDs for the sub-directories */
-pSubDir = path + 1;
-pSlash = strchr(pSubDir, '/');
-while (pSlash) {
-pidl-mkid.cb = (USHORT)(pSlash+3-pSubDir);
-memcpy(pidl-mkid.abID, pSubDir, pidl-mkid.cb);
-pSubDir = pSlash + 1;
-pSlash = strchr(pSubDir, '/');
+/* Concatenate the SHITEMIDs of the sub-directories. */
+while (*path) {
+path = UNIXFS_build_shitemid(path, pidl);
pidl = ILGetNext(pidl);
}
pidl-mkid.cb = 0; /* Terminate the ITEMIDLIST */
-/* Path doesn't end with a '/' */
-if (*pSubDir)
-WARN(Path '%s' not in canonical form.\n, path);
-
return TRUE;
}
@@
Re: Last call for PGP key signing party
CRUD! LOL I have a key, but I 1) dont have a laptop and 2) dont know when or where wineconf is this year and 3) doubt I could make it even if I did. Otherwise I could be #7 lol.. Could you tell me when and where and then I can determine if I can make it.. If I can I will let you know and I will be #7, except for the whole laptop thing... Dustin Shachar Shemesh wrote: Hi all, This is your last chance to get your very own PGP key signed by your community. So far, we have 6.5 participants (hoping to get it to 7 by tomorrow). This means 7 brand new signatures on your PGP key. Read the previous announcement (http://www.winehq.org/hypermail/wine-devel/2005/04/0057.html and http://www.winehq.org/hypermail/wine-devel/2005/04/0084.html) for details on what you need to do. New submissions should be possible to get right up to the party itself, assuming I can get our hosts to lend me the use of a printer (Will you?). Thanks, Shachar
/tmp using
I suppose to make patch for using TMPDIR environment variable as temp directory if it is not empty. There is hardcoded path to /tmp for wine server directory, and I would like to use ~/tmp dir... Will it change accepted and or it is not wrong intention? -- Vitaly Lipatov, ALT Linux Team Russia, Saint-Petersburg, www.etersoft.ru
Re: Installing Mozilla
Alex wrote: I'm encountering a crash when trying to install Mozilla 1.7.7 under wine. I am using a fresh CVS checkout, but I've tried older revisions with the same result. So far, this evidence points to a bug in Mozilla rather than in Wine. It may very well be triggered by a bug in Wine.. Here is a backtrace. It's falling over trying to write to 0x99806858. Mozilla's passing an apparently invalid pointer to WideCharToMultiByte. Question is, where does this come from? Running with WINEDEBUG=nls may give a clue what string it's trying to convert, which may give some indication of the problem. Running with WINEDEBUG=relay will probably give a better clue, but be prepared for a huge log. But since the Mozilla source is available, you may be able to hunt it down more easily using that. --Juan __ Do you Yahoo!? Yahoo! Small Business - Try our new resources site! http://smallbusiness.yahoo.com/resources/
Re: Installing Mozilla
--- James Hawkins [EMAIL PROTECTED] wrote: Just because Mozilla is passing a bad memory address doesn't mean it's a bug in Mozilla. For example Mozilla could have requested some information from wine and we gave them the bad memory address. While that's certainly possible in general, that doesn't appear to be the case here. The bad pointer is the destination address of WideCharToMultiByte, not the source. Typically this will some buffer or other internal to Mozilla. I'm not claiming there isn't a bug in Wine. But I think the immediate thing we're seeing is a bug in Mozilla (likely triggered by a bug in Wine.) The nls trace might be interesting, because the source pointer appears to be valid. So, what string are they trying to translate? An error message perhaps? That might point to the cause of the problem. --Juan __ Do you Yahoo!? Yahoo! Small Business - Try our new resources site! http://smallbusiness.yahoo.com/resources/
Re: windows file dialogs with unix file path
Hi, --- Francois Gouget [EMAIL PROTECTED] wrote: Hmm, I feel like I've seen that before. Where??? Windows is supposed to be able to be able to handle anything for a drive letter now. I have seen the Euro symbol used for a drive letter. It would be more inituitive to the user to have unix:/ rather than Z: but I don't think GetLogicalDriveStrings() can handle this http://msdn.microsoft.com/library/default.asp?url=/library/en-us/fileio/fs/getlogicaldrivestrings.asp so you would need to use RtlDosFilenameToNtFilename or whatever it was called and do some magic with the object manager such as pointing to \\.\unix\ and maybe add unix: to the list of built-in device names (like LPTx, AUX, NUL, etc.). Then you might be able to hack a dialog to point to the device name. Thanks Steven __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
Re: /tmp using
Vitaly Lipatov [EMAIL PROTECTED] writes: I suppose to make patch for using TMPDIR environment variable as temp directory if it is not empty. There is hardcoded path to /tmp for wine server directory, and I would like to use ~/tmp dir... Will it change accepted and or it is not wrong intention? No, the server directory has to be in /tmp so that all instances use the same lock file. If you take into account environment variables there is no guarantee that all server invocations will use the same value. -- Alexandre Julliard [EMAIL PROTECTED]
Re: windows file dialogs with unix file path
What about writing Unix paths like an URL ? So you would have unix://path/to/file Andrew You can be the captain I will draw the chart Sailing into destiny Closer to the heart Closer to the Heart by Rush (A Farewell to Kings, 1977) ~ Alexandre Julliard wrote: Michael Jung [EMAIL PROTECTED] writes: That's a good point about the heuristic. So probably unix paths should just be passed through, without searching for a valid drive letter based wine path. This would also cleanly separate case sensitive path names from case insensitive ones. (I'm assuming, but am not quite sure of, that there is a cheap and robust way to distinguish unix paths from windows paths just by inspecting the string. Might be hard especially for relative paths.) That of course is the whole problem: you cannot reliably identify unix paths just by looking at the string.
Re: windows file dialogs with unix file path
Michael Jung [EMAIL PROTECTED] writes: That's a good point about the heuristic. So probably unix paths should just be passed through, without searching for a valid drive letter based wine path. This would also cleanly separate case sensitive path names from case insensitive ones. (I'm assuming, but am not quite sure of, that there is a cheap and robust way to distinguish unix paths from windows paths just by inspecting the string. Might be hard especially for relative paths.) That of course is the whole problem: you cannot reliably identify unix paths just by looking at the string. -- Alexandre Julliard [EMAIL PROTECTED]
Re: windows file dialogs with unix file path
On Sat, 23 Apr 2005, Andrew Neil Ramage wrote: What about writing Unix paths like an URL ? So you would have unix://path/to/file Why not write Unix paths as 'z:/path/to/file'. It's just one letter instead of four so it would be even easier. Implementation's trivial too, we would create a symbolic link to '/' called 'z:' in dosdevices... Hmm, I feel like I've seen that before. Where??? -- Francois Gouget [EMAIL PROTECTED]http://fgouget.free.fr/ The software said it requires Win95 or better, so I installed Linux.
Installing Mozilla
Hello, I'm encountering a crash when trying to install Mozilla 1.7.7 under wine. I am using a fresh CVS checkout, but I've tried older revisions with the same result. Here is a backtrace. It's falling over trying to write to 0x99806858. Backtrace: =1 0x557581df wine_cp_wcstombs(table=0x5584855c, flags=0x0, src=0x55c08a38, srclen=0x12, dst=0x99806858, dstlen=0x20, defchar=0x0, used=0x0) [/var/tmp/portage/wine-cvs-1.1/work/wine/libs/unicode/wctomb.c:161] in libwine_unicode.so.1 (0x55c08934) 2 0x55a3a4f1 WideCharToMultiByte+0xe1(page=0x0, flags=0x0, src=0x55c08a38, srclen=0x, dst=0x99806858, dstlen=0x20, defchar=0x0, used=0x0) [/var/tmp/portage/wine-cvs-1.1/work/wine/dlls/kernel/locale.c:1651] in kernel32 (0x55c08970) 3 0x60f61cfd PR_AttachThread+0x56a in nspr4 (0x55c08ae0) 4 0x60f62956 in nspr4 (+0x12956) (0x55c08b08) 5 0x61d42e13 NS_GetMemoryManager+0x1b in xpcom (0x55c08b30) 6 0x61d7680a public: virtual int __thiscall nsCaseInsensitiveCStringComparator::operator()(char,char)const +0x716 in xpcom (0x55c08b5c) 7 0x61d548ff in xpcom (+0x148ff) (0x55c08b88) 8 0x61d566ed NS_NewNativeLocalFile+0x53 in xpcom (0x55c08ce4) 9 0x00416296 in setup (+0x16296) (0x55c0cd44) 10 0x00405958 in setup (+0x5958) (0x55c0ee5c) 11 0x00415e2f in setup (+0x15e2f) (0x55c0fe94) 12 0x00424375 EntryPoint+0xce in setup (0x55c0ff20) 13 0x55a4e645 start_process+0xf5(arg=0x0) [/var/tmp/portage/wine-cvs-1.1/work/wine/dlls/kernel/process.c:1044] in kernel32 (0x55c0fff4) 14 0x55585c71 wine_switch_to_stack+0x11 in libwine.so.1 (0x) I've created a +relay trace, which shows the following stuff happening just before things go pear shaped: 0011:Ret ntdll.RtlAllocateHeap() retval=559752b0 ret=572beb67 0011:Ret msvcrt.calloc() retval=559752b0 ret=60f53690 0011:Call msvcrt._strdup(60f68130 shma) ret=60f536a2 0011:Call ntdll.RtlAllocateHeap(558c,,0005) ret=572bebe7 0011:Ret ntdll.RtlAllocateHeap() retval=559752d0 ret=572bebe7 0011:Ret msvcrt._strdup() retval=559752d0 ret=60f536a2 0011:Call msvcrt.getenv(60f664f4 NSPR_LOG_MODULES) ret=60f58ed1 0011:Ret msvcrt.getenv() retval= ret=60f58ed1 0011:Call kernel32.GetVersionExA(55c089a0) ret=60f61cbc 0011:Call ntdll.RtlGetVersion(55c0877c) ret=55a71f38 0011:Ret ntdll.RtlGetVersion() retval= ret=55a71f38 0011:Ret kernel32.GetVersionExA() retval=0001 ret=60f61cbc 0011:Call kernel32.GetTimeZoneInformation(55c08a34) ret=60f61cd6 0011:Call ntdll.RtlQueryTimeZoneInformation(55c08a34) ret=55a6fae5 0011:Ret ntdll.RtlQueryTimeZoneInformation() retval= ret=55a6fae5 0011:Call ntdll.NtQuerySystemTime(55c08874) ret=55a6ebc5 0011:Ret ntdll.NtQuerySystemTime() retval= ret=55a6ebc5 0011:Ret kernel32.GetTimeZoneInformation() retval= ret=60f61cd6 0011:Call kernel32.WideCharToMultiByte(,,55c08a38 LGMT Standard Time,,99806858,0020,,) ret=60f61cfd So, it's probably worth saying that I'm on UK time. Possibly also worth noting that I am using an x86_64, with wine -m32 compiled. Any ideas? Cheers. -- Alex
Re: Installing Mozilla
If I change my winver from winxp to win95, I don't get this problem. -- Alex
Re: Installing Mozilla
On Fri, Apr 22, 2005 at 04:31:52PM -0700, Juan Lang wrote: Alex wrote: I'm encountering a crash when trying to install Mozilla 1.7.7 under wine. I am using a fresh CVS checkout, but I've tried older revisions with the same result. So far, this evidence points to a bug in Mozilla rather than in Wine. It may very well be triggered by a bug in Wine.. Here is a backtrace. It's falling over trying to write to 0x99806858. Mozilla's passing an apparently invalid pointer to WideCharToMultiByte. Question is, where does this come from? Running with WINEDEBUG=nls may give a clue what string it's trying to convert, which may give some indication of the problem. Running with WINEDEBUG=relay will probably give a better clue, but be prepared for a huge log. But since the Mozilla source is available, you may be able to hunt it down more easily using that. Well, I included a bit of the relay trace I did in my first email, and it includes the first occurance of that strange memory address (or anything near it for that matter). Since it's being passed into wine from Mozilla, I guess you're right and it is a problem within Mozilla. -- Alex
Re: Installing Mozilla
On 4/22/05, Alex Woods [EMAIL PROTECTED] wrote: On Fri, Apr 22, 2005 at 04:31:52PM -0700, Juan Lang wrote: Alex wrote: I'm encountering a crash when trying to install Mozilla 1.7.7 under wine. I am using a fresh CVS checkout, but I've tried older revisions with the same result. So far, this evidence points to a bug in Mozilla rather than in Wine. It may very well be triggered by a bug in Wine.. Here is a backtrace. It's falling over trying to write to 0x99806858. Mozilla's passing an apparently invalid pointer to WideCharToMultiByte. Question is, where does this come from? Running with WINEDEBUG=nls may give a clue what string it's trying to convert, which may give some indication of the problem. Running with WINEDEBUG=relay will probably give a better clue, but be prepared for a huge log. But since the Mozilla source is available, you may be able to hunt it down more easily using that. Well, I included a bit of the relay trace I did in my first email, and it includes the first occurance of that strange memory address (or anything near it for that matter). Since it's being passed into wine from Mozilla, I guess you're right and it is a problem within Mozilla. While this is always a possibility, it leaves one wondering. Why does Mozilla work in Windows XP but not in xp mode in wine? Just because Mozilla is passing a bad memory address doesn't mean it's a bug in Mozilla. For example Mozilla could have requested some information from wine and we gave them the bad memory address. Then they call WideCharToMultiByte with the bad memory address we gave them. Your best bet is to find the first place this bad memory address pops up. Having a copy of the Mozilla source would probably be a good thing for this exercise. -- James Hawkins
version change broke InstMsiA.exe
Hi, The following patch broke InstMsiA.exe: Modified files: dlls/ntdll : version.c Log message: Ivan Leo Puoti [EMAIL PROTECTED] Better EXE version check in VERSION_GetLinkedDllVersion. Patch: http://cvs.winehq.org/patch.py?id=14894 Here is +ver: trace:ver:VERSION_Init getting version from LAppDefaults\\InstMsiA.exe\\Version trace:ver:VERSION_Init getting default version trace:ver:VERSION_GetLinkedDllVersion LInstMsiA.exe: 07.00/05.01/05.01/04.00 trace:ver:VERSION_GetLinkedDllVersion 07.00/05.01/05.01/04.00 trace:ver:RtlGetVersion -- Windows XP (LService Pack 2) trace:ver:RtlGetVersion -- Windows XP (LService Pack 2) trace:ver:VERSION_Init getting version from LAppDefaults\\msiinst.exe\\Version trace:ver:VERSION_Init getting default version trace:ver:VERSION_GetLinkedDllVersion Lmsiinst.exe: 07.00/05.01/05.01/04.00 trace:ver:VERSION_GetLinkedDllVersion 07.00/05.01/05.01/04.00 trace:ver:RtlGetVersion -- Windows XP (LService Pack 2) ... Before the change GetLinkedDllVersion recognized InstMsiA.exe as win98, but now it's XP SP2. I'm not sure how to change this test to make it work because both InstMsiA.exe (win9x version) and InstMsiW.exe (nt/xp version) return 07.00/05.01/05.01/04.00 for GetLinkedDllVersion. One solution is to just use the config file and specify win98, but since we are moving away from the config file I think it would be worth figuring out why this isn't working yet. -- James Hawkins
wine and gcc 4.0
Hi! I've just installed gcc 4.0 and now wine(CVS) stops compiling in ./wine/dlls/msvcrt/tests : gcc -c -I. -I. -I../../../include -I../../../include -I../../../include/msvcrt -I./.. -D_REENTRANT -fPIC -Wall -pipe -mpreferred-stack-boundary=2 -fno-strict-aliasing -gstabs+ -Wpointer-arith -O2 -o headers.o headers.c In file included from headers.c:33: ../../../include/msvcrt/wchar.h:201: warning: conflicting types for built-in function 'iswalnum' ../../../include/msvcrt/wchar.h:202: warning: conflicting types for built-in function 'iswalpha' ../../../include/msvcrt/wchar.h:204: warning: conflicting types for built-in function 'iswcntrl' ../../../include/msvcrt/wchar.h:206: warning: conflicting types for built-in function 'iswdigit' ../../../include/msvcrt/wchar.h:207: warning: conflicting types for built-in function 'iswgraph' ../../../include/msvcrt/wchar.h:208: warning: conflicting types for built-in function 'iswlower' ../../../include/msvcrt/wchar.h:209: warning: conflicting types for built-in function 'iswprint' ../../../include/msvcrt/wchar.h:210: warning: conflicting types for built-in function 'iswpunct' ../../../include/msvcrt/wchar.h:211: warning: conflicting types for built-in function 'iswspace' ../../../include/msvcrt/wchar.h:212: warning: conflicting types for built-in function 'iswupper' ../../../include/msvcrt/wchar.h:213: warning: conflicting types for built-in function 'iswxdigit' ../../../include/msvcrt/wchar.h:214: warning: conflicting types for built-in function 'towlower' ../../../include/msvcrt/wchar.h:215: warning: conflicting types for built-in function 'towupper' ../../../include/msvcrt/io.h:179: error: 'open' aliased to undefined symbol '_open' ../../../include/msvcrt/io.h:180: error: 'sopen' aliased to undefined symbol '_sopen' ../../../include/msvcrt/conio.h:57: error: 'cprintf' aliased to undefined symbol '_cprintf' ../../../include/msvcrt/conio.h:58: error: 'cscanf' aliased to undefined symbol '_cscanf' ../../../include/msvcrt/process.h:129: error: 'execl' aliased to undefined symbol '_execl' ../../../include/msvcrt/process.h:130: error: 'execle' aliased to undefined symbol '_execle' ../../../include/msvcrt/process.h:131: error: 'execlp' aliased to undefined symbol '_execlp' ../../../include/msvcrt/process.h:132: error: 'execlpe' aliased to undefined symbol '_execlpe' ../../../include/msvcrt/process.h:133: error: 'spawnl' aliased to undefined symbol '_spawnl' ../../../include/msvcrt/process.h:134: error: 'spawnle' aliased to undefined symbol '_spawnle' ../../../include/msvcrt/process.h:135: error: 'spawnlp' aliased to undefined symbol '_spawnlp' ../../../include/msvcrt/process.h:136: error: 'spawnlpe' aliased to undefined symbol '_spawnlpe' make: *** [headers.o] Error 1 make died with exit status 2
Re: windows file dialogs with unix file path
Le ven 22/04/2005 à 20:09, Francois Gouget a écrit : On Sat, 23 Apr 2005, Andrew Neil Ramage wrote: What about writing Unix paths like an URL ? So you would have unix://path/to/file Why not write Unix paths as 'z:/path/to/file'. It's just one letter instead of four so it would be even easier. Implementation's trivial too, we would create a symbolic link to '/' called 'z:' in dosdevices... People wanting access to unix paths in Wine want a normal unix path, ie /path/to/file instead of z:/path/to/file (or z:\path\to\file). The z: part is not unix, and that breaks the integration (use of a drive letter while on unix). The other thing is if/when z: doesn't map to / anymore... how do you add it back from within winecfg? Hmm, I feel like I've seen that before. Where??? No idea. Maybe you should submit a patch to Wine :) Vincent
