Re: Where do old rpms go
On Wed, Oct 29, 2003 at 08:25:39PM -0800, Bill Medland wrote: > I apologise for not concentrating; I'm sure that someone has already answered > this but I can't find the answer. > > Do the rpms at SourceForge expire? According to the file upload page no (or just occasionaly). But you can "hide" releases, which I do for the SUSE RPMs, to reduce the size of my part of the Download page. > I just want to know since if that is the case I will have to start taking > copies. > On the same subject, does anyone have a consistant SuSE 8.1 rpm of the > 20030618 version? I can send you the RPM I did for this release. It is still on SF, just hidden. Ciao, Marcus
Where do old rpms go
I apologise for not concentrating; I'm sure that someone has already answered this but I can't find the answer. Do the rpms at SourceForge expire? (I see that the 20030618 for RedHat are no longer there) I just want to know since if that is the case I will have to start taking copies. On the same subject, does anyone have a consistant SuSE 8.1 rpm of the 20030618 version? (That's the last version that worked well for our InstallShield and I don't have time to try to figure out what broke) -- Bill Medland mailto:[EMAIL PROTECTED] http://webhome.idirect.com/~kbmed
Re: Int21 bug
Could you retry with current CVS, or if you cant, 20031016 ? > So: file handle 0x136 translates to DOS handle 10, and int21 returns > AX=0x000a > > My newer version, Wine 20030408, does the following: > I'm not sure, but this bug could also help number 1170, that seems > related > in that there's a file that is not actually there, and 717, which > also tries > to make a file that isn't created. = Sylvain Petreolle (spetreolle_at_users_dot_sourceforge_dot_net) ICQ #170597259 Say NO to software patents Dites NON aux brevets logiciels "What if tomorrow the War could be over ?" Morpheus, in "Reloaded". ___ Do You Yahoo!? -- Une adresse @yahoo.fr gratuite et en français ! Yahoo! Mail : http://fr.mail.yahoo.com
Re: UI bugs hampering porting effort for shaped window
Rob wrote: The show stopper bugs are B1, B2, B3, B4 and B5. Issue B5, and B7 can be worked around, so they aren't as critical. B1, B2, B3, and B4 can be fixed by putting a title bar on the application. (See MAKE_IT_LOOK_LIKE_A_NORMAL_APP_AT_STARTUP in winetest.cpp.) - B1. Focus does not appear to be on the application at start-up. We do not receive keyboard messages, though we do receive many other messages, such as mouse-clicks. Clicking on the square labelled "focus:" fixes the problem, by bringing up a message box -- when the message box is dismissed, the application has focus. This appears to be the same problem as that discussed here: http://bugs.winehq.org/show_bug.cgi?id=292 - B2. No task bar item. Patch at http://www.winehq.org/hypermail/wine-patches/2003/09/0268.html can fix these problems.
UI bugs hampering porting effort for shaped window
Hello All, Apologies if I'm not posting to the correct location. I am trying to port our X-Lite (a leading free SIP softphone) application to run under WINE as a first trial before we obtain the expertise to do a native application. However, I am running into some issues because our application uses a non-standard shaped window. One of our windows developers has created a test application that demonstrates the non-compatible issues found in hopes that someone may be able to help resolve the issues. As of yet, we do not have the in-house expertise to fix the issues directly within WINE. In addition to the UI issues listed below, a fix for bug 1541 is critical. If anyone can help resolve these issues, I'd greatly appreciate the help in getting another application that can run under WINE, and we can have one of our windows developers assist in validation of any fixes. Thanks, Rob Bugzilla Bug 1541 WS2_32 version of gethostbyname with NULL argument doesn't follow specification http://bugs.winehq.org/show_bug.cgi?id=1541 ... This application demonstrates the issues we are having which will allow X-Lite to run under WINE. Source and binaries are included. Find the demo application at: http://www.xten.com/files/winetest.zip The show stopper bugs are B1, B2, B3, B4 and B5. Issue B5, and B7 can be worked around, so they aren't as critical. B1, B2, B3, and B4 can be fixed by putting a title bar on the application. (See MAKE_IT_LOOK_LIKE_A_NORMAL_APP_AT_STARTUP in winetest.cpp.) - B1. Focus does not appear to be on the application at start-up. We do not receive keyboard messages, though we do receive many other messages, such as mouse-clicks. Clicking on the square labelled "focus:" fixes the problem, by bringing up a message box -- when the message box is dismissed, the application has focus. This appears to be the same problem as that discussed here: http://bugs.winehq.org/show_bug.cgi?id=292 - B2. No task bar item. - B3. "System" commands do not appear to be working. Examples: - we do not receive WM_CLOSE when the user presses Alt+F4 - Alt+Space does not bring up the System menu - B4. We are always on top, until a screen-saver kicks in. (Also can be fixed by simply removing WS_POPUP.) This appears to be the same problem as that discussed here: http://bugs.winehq.org/show_bug.cgi?id=1288 - B5. The application window is supposed to have a non-rectangular shape. The shape is made by setting a "region" from a mask bitmap, and calling SetWindowRgn. The problem under Wine happens when converting the 2-bit color mask to a 24-bit color mask. The black 2-bit pixels are properly converted to black 24-bit pixels, but the white 2-bit pixels are converted to a near-black, rather than white. The sample app demonstrates 2 ways of working around the problem: method 1: fixes the problem by using a 16-color (4 bit per color) mask instead of a 2-color mask. This gets around the bug in a reasonable way. method 2: fixes the problem by using near-black (instead of white) for the "transparent" color. This exploits the bug and causes a bad (but correct) appearance on Windows. - B6. Copy to the clipboard doesn't work (though pasting from the clipboard does work). - B7. Attempting to bring up the right-click context menu causes the app to hang.
Re: make install problem
On Wed, 29 Oct 2003, Alexandre Julliard wrote: > My guess is that ldconfig has messed with the symlinks. Maybe because I have the old libwine*.so.1.0 in there... I'll get rid of them, sorry for the false alarm. -- Dimi.
Re: make install problem
"Dimitrie O. Paun" <[EMAIL PROTECTED]> writes: > Well, I did a standard build: > > configure --with-nptl --silent && make -s depend && make -s > > than installed it (as root): > > make -s install My guess is that ldconfig has messed with the symlinks. -- Alexandre Julliard [EMAIL PROTECTED]
Re: Installshield7 notes
On Wednesday 29 October 2003 03:29 pm, Carlos Lozano wrote: > Hello, > > Here goes some notes about how to install installshield 7 programs > with the actual wine releases (sorry, i haven't been able to install > without some natives DLLs). Could you recommend any particular installer that fails to me (preferably something I can download for free)? I'd be happy to take a look at this, although I can't make any promises as some code-paths (like stubless proxies) are not likely to be fixed anytime soon. -- gmt "To take from one, because it is thought his own industry and that of his fathers has acquired too much, in order to spare to others, who, or whose fathers, have not exercised equal industry and skill, is to violate arbitrarily the first principle of association, the guarantee to everyone the free exercise of his industry and the fruits acquired by it." --Thomas Jefferson
Re: make install problem
On Wed, 29 Oct 2003, Alexandre Julliard wrote: > Yes, and it seems to work fine here. Could you show us the exact > commands you ran and the relevant make output? Well, I did a standard build: configure --with-nptl --silent && make -s depend && make -s than installed it (as root): make -s install to fix the problem, I had to do: cd libs/; make -s install-dev -- Dimi.
Re: make install problem
"Dimitrie O. Paun" <[EMAIL PROTECTED]> writes: > That is to say, both libwine.so and libwine_unicode.so are fubared. > They point to old libs. Shouldn't they just point to the .1 versions? Yes, and it seems to work fine here. Could you show us the exact commands you ran and the relevant make output? -- Alexandre Julliard [EMAIL PROTECTED]
Installshield7 notes
Hello, Here goes some notes about how to install installshield 7 programs with the actual wine releases (sorry, i haven't been able to install without some natives DLLs). You need 3 native DLLs (ole32.dll, oleaut32.dll and rpcrt4.dll), and 2 .tlb files (stdole32.tlb and stdole2.tlb). Copy this 5 files to your windows/system directory, and edit your ~/.wine/config, using: [DllOverrides] "oleaut32" = "native" "ole32" = "native" "rpcrt4" = "native" Even using this natives dlls, you will have problems with the windows order, what you will not leave you see the windows and install the program. The easier way to install it, should be enable the Desktop mode, in ~/.wine/config: "Managed" = "N" "Desktop" = "640x480" "Desktop" = "Y" I have found some programs, what give problems with Desktop mode, exiting during install with X11 errors (Praetoriams demo for example). In this cases you can use yet another trick. Disable Desktop, and enable "Managed" = "Y", then in the file the file "dlls/x11drv/window.c", you will find the function "inline static BOOL is_window_managed( WND *win )", in the end of this function, there are this 3 lines: /* default: not managed */ return FALSE; } replace, "return FALSE;" to "return TRUE;", and run make install again. Remember after of install the program change again this line to "FALSE", because you could have problems later with other windows. Regards, Carlos. -- ___ _ \ | / Consulting | . |._ _ _| | ___ ___ ___http://www.andago.com | || ' |/ . |<_> |/ . |/ . \__ GNU/Linux |_|_||_|_|\___|<___|\_. |\___/ _ \ __|\ \ / Carlos A. Lozano <___'/ | \ -_) __/\__ \ > < -_) [ [EMAIL PROTECTED] ]\___|_| / _/\_\___| [ [EMAIL PROTECTED] ] http://www.ePSXe.com
Re: Int21 bug
On Wed, Oct 29, 2003 at 01:24:42PM +0100, Valentijn Sessink wrote: > Hi folks, > > I think I hunted down a bug in DOS int21 function 0x5b (my DOS book insists > this is 91 decimal). My older version of wine, 2000821, goes like this: > > We also checked Codeweavers Wine for this bug; it seems to be there, but > after two days of bug hunting our hunting ground is a bit of a mess, so I'm > not sure if we tested 2.0 or 2.1. I searched Bugzilla for a DOS related bug > and couldn't find one, but if it's fixed between 20030408 and now, then > please accept my apologies for wasting your precious reading time. I have read through the code and this condition should not happen. There has been some large reconstruction in that area, so please test yourself :/ Ciao, Marcus
Re: [dx88] Cull fix
Jason Edmeades <[EMAIL PROTECTED]> writes: > Michael - See if this helps with your map / figure problems... Sorry, but it doesn't helped. Also the other ones doesn't helped. The fixme's fixme:d3d_surface:IDirect3DSurface8Impl_LockRect fixme:d3d:IDirect3DDevice8Impl_SetRenderTarget fixme:d3d:IDirect3DDevice8Impl_ResourceManagerDiscardBytes also still appear as before. Do you want a new "-debugmsg +d3d8,+d3d_surface" log or pherhaps the texture snapshots? But I couldn't create any of them before next week, because I'm going sailing over the weekend. Michael
RE: How do i find the start menu path?
Robert van Herk <[EMAIL PROTECTED]> wrote: >I have a question for my start menu generator, that is almost finished >now... > >How do I find the path of the wine start menu? (for me it's >~/c/windows/Start Menu, but for someone else it does not have to be like >that...) I assume/hope you have a winelib app in which case you can just simply call ret = SHGetSpecialFolderPathW(NULL, lpString, CSIDL_PROGRAMS, FALSE); and unless SHRestricted(REST_NOCOMMONGROUPS) is true also ret = SHGetSpecialFolderPathW(NULL, lpString, CSIDL_COMMON_PROGRAMS, FALSE); Rolf Kalbermatter
RE: Forwards exports - anyone?
> -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] Behalf Of Shachar Shemesh > Sent: 29 October 2003 13:41 > To: Wine Devel > Subject: Forwards exports - anyone? > > > Hi all, > > I noticed in the code that there is a concept called "forwad_export". > Does it have anything to do with making a function in one DLL return a > function address that belongs to another? > > If that is the case, how do I activate this? Is there some spec file > magic that will do it? Yes. Example from kernel32.spec: @ stdcall RtlMoveMemory(ptr ptr long) ntdll.RtlMoveMemory This is a function called RtlMoveMemory that forwards to the ntdll function RtlMoveMemory (the names don't have to be the same). I believe this is exactly the way you want to do it as the same has been done for the *Wrap functions in SHLWAPI (which are effectively a mini-unicows.dll). Rob
Re: Forwards exports - anyone?
Shachar Shemesh <[EMAIL PROTECTED]> wrote: >I'm trying to implement unicows.dll. The theory is quite simple - since >unicows merely implements unicode functions that exist, theoretically, >only in Wine, all I have to do is create forwards (i.e. - ExtTextOutW in >unicows.dll will call ExtTextOutW in GDI). This is slightly inefficient, >but should solve our unicows.dll problems. > >If I can merely instruct the dynamic loader to return the GDI >ExtTextOutW function when someone tries to link with the unicows >ExtTextOutW, I can solve the inefficiency in a clean, working way >without further problems. I thought this was done in Wine in the spec files. Something such as: @ stdcall ExtTextOutW(params) gdi32.ExtTextOutW should do the trick. The function names need not to be the same. The only limitation I have found is that you can't forward in this way to ordinal exports but I may have missed something. Rolf Kalbermatter
WineHQ: Corrected PATCH to fix IPersistFile::Load() and associated functions.
Hello all I corrected my last patch after replacing everything C++ into C. This patch has been inlined as well as attached as a ZIP file, so suit yourself. All reports regaring this patch is to be sent to with a proper subject prefixed by "IPersistFile patch" in the subject header. This patch fixes: (1) Stream_LoadString: Conflict of unicode strings being taken as LPSTR and AGAIN being converted to Unicode due to wrong value of SCF_UNICODE .(I have preprocessed out the original code. This should remain so until SCF_UNICODE value is corrected) (2) Stream_LoadLocation: Previously the GetPath() failed. It works great now. Now IPersistFile::Load() should work as intended. Try out McCormack's 'winemenubuilder' or my WineLib 'linkresolve' (NOT my C++ version) If the diff is not proper, etc, please alert me at the mentioned address PS: As I am not a member of 'wine-patches',can the moderator be kind enough... :=) I really want these functions to get fixed. That's all. Regards Subhobroto Sinha __ Do you Yahoo!? Exclusive Video Premiere - Britney Spears http://launch.yahoo.com/promos/britneyspears/ Patch.tar.gz Description: Patch.tar.gz --- wine-20031016/dlls/shell32/shelllink.c 2003-10-29 21:07:43.0 +0530 +++ Shikayat/dlls/shell32/shelllink.c 2003-10-29 20:39:56.0 +0530 @@ -401,9 +401,49 @@ return S_OK; } +static HRESULT Stream_LoadString( IStream* stm, BOOL unicode,LPWSTR *pstr ) +{ +DWORD count=0; +USHORT len; +LPWSTR str=NULL; +HRESULT r; +/* +From Win98 upwards everything internally is maintained as unicode.(Atleast M$ says so) +Also, the value of SCF_UNICODE does NOT seem to be 0x1000, hence the bitwise '&' returns a false. +Until the correct value is found, we assume it Unicode. This should not break ANYTHING >Win95 for shortcuts +Anybody differing mail to . +*/ +TRACE("%p\n", stm); + +r = IStream_Read(stm, &len, sizeof(len), &count); +if(FAILED(r)||(count != sizeof(len))) return E_FAIL; +len *= sizeof(WCHAR); + +TRACE("reading %d\n", len); +str = HeapAlloc(GetProcessHeap(), 0, len+sizeof(WCHAR)); +if(!str) return E_OUTOFMEMORY; + +count = 0; +r = IStream_Read(stm, str, len, &count); +if( FAILED(r)||( count!=len) ) +{ +HeapFree( GetProcessHeap(), 0, str ); +return E_FAIL; +} + +str[count/2]=0; +*pstr = str; +TRACE("read %s\n", debugstr_w(str)); +return S_OK; +} + +#if 0 static HRESULT Stream_LoadString( IStream* stm, BOOL unicode, LPWSTR *pstr ) { + /*This is the original function now redirected to the above till we find out correct 'SCF_UNICODE'. + Now it's assumed that the data's unicode. (This assumption failes iff the OS was <=Win95, so I don't think it will hurt anybody)*/ + DWORD count; USHORT len; LPVOID temp; @@ -454,6 +494,7 @@ return S_OK; } +#endif static HRESULT Stream_LoadLocation( IStream* stm ) { @@ -503,9 +544,10 @@ IStream* stm) { LINK_HEADER hdr; -ULONGdwBytesRead; +ULONGdwBytesRead=0; BOOL unicode; WCHARsTemp[MAX_PATH]; +char szTemp[MAX_PATH]={0}; HRESULT r; _ICOM_THIS_From_IPersistStream(IShellLinkImpl, iface); @@ -515,7 +557,6 @@ if( !stm ) return STG_E_INVALIDPOINTER; -dwBytesRead = 0; r = IStream_Read(stm, &hdr, sizeof(hdr), &dwBytesRead); if( FAILED( r ) ) return r; @@ -533,6 +574,13 @@ if( FAILED( r ) ) return r; } + +SHGetPathFromIDListA(This->pPidl,szTemp); +This->sPath=HeapAlloc( GetProcessHeap(), 0,(strlen(szTemp)+1)*sizeof(WCHAR)); +dwBytesRead=(strlen(szTemp)+1);/*Just to hold the length of the string*/ +MultiByteToWideChar(CP_ACP,0,szTemp,dwBytesRead,This->sPath,dwBytesRead); +TRACE("%s\n",debugstr_w(This->sPath)); + This->wHotKey = hdr.wHotKey; This->iIcoNdx = hdr.nIcon; FileTimeToSystemTime (&hdr.Time1, &This->time1);
Re: How do i find the start menu path?
Hello Robert, > I have a question for my start menu generator, that is almost finished > now... > > How do I find the path of the wine start menu? (for me it's > ~/c/windows/Start Menu, but for someone else it does not have to be like > that...) > > Any help here? Ypu should use the function SHGetSpecialFolderPath(): http://msdn.microsoft.com/library/default.asp?url=/library/en-us/shellcc/platform/shell/reference/functions/shgetspecialfolderpath.asp Using CSIDL_STARTMENU and CSIDL_COMMON_STARTMENU you get the root path of the user's respective the common start menu: #include #include #include void process_startmenu(LPCTSTR path) { // process start menu entries } int main(int argc, char* argv[]) { TCHAR path[1024]; if (SHGetSpecialFolderPath(0, path, CSIDL_STARTMENU, FALSE)) { printf("user start menu root: %s\n", path); process_startmenu(path); } if (SHGetSpecialFolderPath(0, path, CSIDL_COMMON_STARTMENU, FALSE)) { printf("common start menu root: %s\n", path); process_startmenu(path); } return 0; } -- Martin Fuchs [EMAIL PROTECTED] NEU FÜR ALLE - GMX MediaCenter - für Fotos, Musik, Dateien... Fotoalbum, File Sharing, MMS, Multimedia-Gruß, GMX FotoService Jetzt kostenlos anmelden unter http://www.gmx.net +++ GMX - die erste Adresse für Mail, Message, More! +++
Int21 bug
Hi folks, I think I hunted down a bug in DOS int21 function 0x5b (my DOS book insists this is 91 decimal). My older version of wine, 2000821, goes like this: trace:int21:DOS3Call CREATE NEW FILE 0x00 for X:\TMP41.$$$ trace:file:CreateFileA X:\TMP41.$$$ GENERIC_READ GENERIC_WRITE FILE_SHARE_READ FILE_SHARE_WRITE CREATE_NEW trace:dosfs:DOSFS_GetFullName X:\TMP41.$$$ (last=0) trace:string:lstrcpynA (0x40e35fa0, "/tmp", 1024) trace:dosfs:DOSFS_FindUnixName /tmp,TMP41.$$$ trace:heap:HeapAlloc (403c,0002,022c): returning 414c9cf4 trace:heap:HeapAlloc (6543,0400,0018): returning 65432c30 warn:dosfs:DOSFS_FindUnixName 'TMP41.$$$' not found in '/tmp' trace:heap:HeapFree (6543,0400,65432c30): returning TRUE trace:heap:HeapFree (403c,0002,414c9cf4): returning TRUE trace:dosfs:DOSFS_GetFullName returning /tmp/TMP41.$$$ = X:\tmp41.$$$ 080732c8: create_file( access=c000, inherit=0, sharing=0003, create=1, attrs=, filename="/tmp/TMP41.$$$" ) 080732c8: create_file() = 0 { handle=136 } trace:file:FILE_AllocDosHandle Got 10 for h32 136 trace:int21:DOS3Call returning: AX=000a BX=5b0c CX= DX=e9a8 SI= DI=e9a8 DS=0a27 ES=0907 EFL=0202 trace:global:GlobalHandle16 0107 Ret KERNEL.102: DOS3CALL() retval=none ret=0347:2513 ds=0a27 AX=000a BX=5b0c CX= DX=e9a8 SI= DI=e9a8 ES=0907 EFL=0202 trace:global:GlobalHandle16 0107 So: file handle 0x136 translates to DOS handle 10, and int21 returns AX=0x000a My newer version, Wine 20030408, does the following: 000a:trace:int21:INT_Int21Handler CREATE NEW FILE 0x00 for X:\TMP18467.$$$ 000a:trace:heap:RtlAllocateHeap (0x4037,0002,0020): returning 415b32c0 000a:trace:file:CreateFileW L"X:\\TMP18467.$$$" GENERIC_READ GENERIC_WRITE FILE_SHARE_READ FILE_SHARE_WRITE CREATE_NEW attributes 0x0 000a:trace:dosfs:DOSFS_GetFullName L"X:\\TMP18467.$$$" (last=0) 000a:trace:string:lstrcpynA (0x40f40d84, "/tmp", 1024) 000a:trace:dosfs:DOSFS_FindUnixName /tmp,L"TMP18467.$$$" 000a:trace:dosfs:DOSFS_ToDosFCBFormat (L"TMP18467.$$$", 0x40f40ce4) 000a:trace:heap:RtlAllocateHeap (0x4037,0002,0110): returning 415cc890 000a:trace:dosfs:DOSFS_OpenDir "/tmp" 000a:trace:heap:RtlAllocateHeap (0x4037,0002,0018): returning 415cbca0 000a:trace:heap:RtlReAllocateHeap (0x4037,0002,415cc890,0210): returning 415cc890 000a:trace:heap:RtlReAllocateHeap (0x4037,0002,415cc890,0410): returning 415cc890 000a:trace:heap:RtlReAllocateHeap (0x4037,0002,415cc890,0810): returning 415cc890 000a:trace:heap:RtlReAllocateHeap (0x4037,0002,415cc890,1010): returning 415cc890 000a:trace:heap:RtlFreeHeap (0x4037,0002,415cbca0): returning TRUE 000a:trace:dosfs:DOSFS_ReadDir Read: long_name: L".", short_name: (null) 000a:trace:dosfs:DOSFS_ReadDir Read: long_name: L"..", short_name: (null) 000a:trace:dosfs:DOSFS_ReadDir Read: long_name: L".font-unix", short_name: (null) [cut directory listing] 000a:warn:dosfs:DOSFS_FindUnixName L"TMP18467.$$$" not found in '/tmp' 000a:trace:heap:RtlFreeHeap (0x4037,0002,415cc890): returning TRUE 000a:trace:dosfs:DOSFS_GetFullName returning /tmp/TMP18467.$$$ = L"X:\\tmp18467.$$$" 000a:trace:dosfs:GetDriveTypeW (L"X:\\tmp18467.$$$") 000a: create_file( access=c000, inherit=0, sharing=0003, create=1, attrs=, drive_type=3, filename="/tmp/TMP18467.$$$" ) 000a: create_file() = 0 { handle=0x98 } 000a:trace:file:CreateFileW returning 0x98 000a:trace:heap:RtlFreeHeap (0x4037,0002,415b32c0): returning TRUE 000a:trace:file:Win32HandleToDosFileHandle Got 10 for h32 0x98 000a:Ret kernel32.INT_Int21Handler() retval= ret=41560c39 000a:trace:int21:DOSVM_Int21Handler failed, error 0 000a:trace:int21:DOSVM_Int21Handler returning: AX= BX=5b0f CX= DX=e9a8 SI= DI=e9a8 DS=0a47 ES=0927 EFL=0203 000a:Ret winedos.CallBuiltinHandler() retval=007c ret=4008d9f0 000a:trace:global:GlobalHandle16 011f This seems weird: there's a file handle, there's a DOS file handle but Int21 returns AX=0, indicating an error. I did not yet check the code (will do this afternoon, but beware: I'm not much of a coder), but I think a fix should be rather easy, there's probably just a typo (or a thinko) in the Int21 handler. I'm not sure, but this bug could also help number 1170, that seems related in that there's a file that is not actually there, and 717, which also tries to make a file that isn't created. Please Cc: my e-mail-address as I'm not on the Wine-devel list. the "nospam" part has an MX record, so mailing shouldn't be a problem. We also checked Codeweavers Wine for this bug; it seems to be there, but after two days of bug hunting our hunting ground is a bit of a mess, so I'm not sure if we tested 2.0 or 2.1. I searched Bugzilla for a DOS related bug and couldn't find one, but if it's fixed between 20030408 and now, then please accept my apologies for wasting your precious reading time. Best
Re: Wine coredumps with Linux kernel 2.6.0-test9
I'm using the Wine, Slackware 9.1 and Linux 2.6.0-test9 without a problem. Slackware's glibc doesn't have NPTL enabled though. Mike bash-2.05b$ uname -a Linux kimchi 2.6.0-test9 #6 Tue Oct 28 01:23:24 KST 2003 i686 unknown unknown GNU/Linux bash-2.05b$ /lib/libc-2.3.2.so GNU C Library stable release version 2.3.2, by Roland McGrath et al. Copyright (C) 2003 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. Compiled by GNU CC version 3.2.3. Compiled on a Linux 2.4.20 system on 2003-05-18. Available extensions: GNU libio by Per Bothner crypt add-on version 2.1 by Michael Glad and others linuxthreads-0.10 by Xavier Leroy BIND-8.2.3-T5B libthread_db work sponsored by Alpha Processor Inc NIS(YP)/NIS+ NSS modules 0.19 by Thorsten Kukuk Report bugs using the `glibcbug' script to <[EMAIL PROTECTED]>. David D. Hagood wrote: Compiled via ./configure with --with-nptl, under 2.6.0-test9
Re: Serious Bug
I'm Just exactly now fighting same problems. See my last post: "Help with shared library make files" Note 2 things A. Initialization order is opposite of msvc++ Last object on the linker gets to run first. (msvc first on the command line first to initialize) B. Hard, in gdb (kdevelop), to set a break point on pre-main code. use below file to do that. Put it as last object linked and after any library. In effect it is an "int 0x03" instruction to hard code a break point. C. All DLLs linked to the MyApp.dll.so should also link to MyApp.exe.so see my wine post: "wine msvcrt on Library initialization". These are the ones that get linked through winebuild. #include "windows.h" #define _CrtDbgBreak() __asm__ ("\tint $0x3\n") class TestStaticClass { public: TestStaticClass() ; ~TestStaticClass() ; } ; TestStaticClass::TestStaticClass() { MessageBox(NULL ,"Constructor" ,"Cpp_Globs_stop" ,MB_OK) ; _CrtDbgBreak(); } TestStaticClass::~TestStaticClass() { MessageBox(NULL ,"Destructor" ,"Cpp_Globs_stop" ,MB_OK) ; } TestStaticClass g_StaticClass ; $(mfctest_dll_MODULE).so: $(mfctest_dll_MODULE).spec.o $(mfctest_dll_OBJS) Cpp_Globs_stop.o $(LDXXSHARED) $(LDDLLFLAGS) -o $@ \ $(mfctest_dll_MODULE).spec.o \ $(mfctest_dll_OBJS) \ $(mfctest_dll_LIBRARY_PATH) \ $(mfctest_dll_LIBRARIES:%=-l%) \ $(ALL_LIBRARIES) \ Cpp_Globs_stop.o \ Now you can single step the initialization chain. flyker wrote: Boaz Harrosh wrote: use --wrap in winemaker. Read about this option in the documentation Thanks. It is work :)
Re: Serious Bug
Boaz Harrosh wrote: use --wrap in winemaker. Read about this option in the documentation Thanks. It is work :)
Re: Serious Bug
Vincent Béron wrote: Huh? Works fine here cross-compiled with mingw. Even added 2 printf (one to the constructor, the other in WinMain), and the constructor one is called first (as it should be). Vincent RedHat 9.0, gcc and winelib. Of course constructor first.
Re: Serious Bug
Le mer 29/10/2003 à 09:02, flyker a écrit : > > The simple test crashes wine. > And i think many other commands in constructor A() may crash wine. Huh? Works fine here cross-compiled with mingw. Even added 2 printf (one to the constructor, the other in WinMain), and the constructor one is called first (as it should be). Vincent
Help with shared library make files
I have the following setup mfctest/Makefile - Main make file mfctest.exe.so - is the wrapper for an mfc gui application mfctest.dll.so - is the mfc gui application (as generated by the msvc++ wizard and than winemaker) msvc/Makefile - make file for mfc & stuff missing from msvcrt.dll libmsvc.a - is all the cpp files archived by [ ar -rs $(ALL_OBJECT_FILES) ] libmsvc.so - same object files but linked with [ gcc --shared ] Now I link mfctest.dll.so with libmsvc.a. (-l) The spec.c I prepare by including all the object files of the msvc project since winebuild does not work with libraries. It all runs fine. Now I try to link with libmsvc.so ( exact same way as before with the -l option linux style, not as a DLL as usually done in wine ). At the beginning it would not link because of undefined symbols. ( before with the .a option not all files get pulled in by the linker). So I fix the undefined s. The spec.c file I have tried in to ways. 1) a libmsvc.spec.c for libmsvc.so and a small one for mfctest.dll.spec.c - and 2) A big mfctest.dll.spec.c that includes all objects same as above libmsvc.a . In both cases I had the same exact problem. It would not run. I get a SIGSEGV. On the (gdb) back-trace it is directly from "dlopen" (from BUILTIN32_dlopen) it SIGs 10 functions deep into dlopen. The last function that makes any sense is _dl_init in ld-linux.so.2 from than on I get un-logical symbols that should not be in the init path. Including undefined s like 0x0094 (see complete back-trace below) the SIGSEGV itself is reported at "dllname" which is not a function but an array in dll.spec.c . So we can see that the debug info got totally screwed up. Big help!!! Any body got any ideas? Do you think I need to fix the start address of libmsvc.so some how? What is the command line option for that? The reason I need the libYYY.so option to work is because I have a big (1900 files) C++ project divided into 36 libraries. On the windows side it is dlls & static libs, all automatically exported by msvc++ (#define class class declspec(dllexport) ). Since we do not have a good C++ way for pure dlls in wine (yet) and the 1900 files on one gcc link will not work. ( truncated by the linker) .And I have more Applications in the future that use the same libraries. The .so option looks best. One more question: What do the gurus say? In theory, if I have a XXX.dll.so linked Linux style to libYYY.so both have calls into wine. what is best method (XXX.dll.so is only because of the wrapper no real exports here) A. XXX.dll.so has an XXX.spec.c && libYYY.so has a YYY.spec.c of its own each linked to their respective .spec.c . (Note that those are only imports since export symbols from libYYY.so are linked against - Linux style). B. one big XXX+YYY.spec.c linked against XXX.dll.so (very very slow, it looks like winebuild has an o(n^2) efficiency ) C. Both are good if no exports are made. (or exports only at the top lib) Thanks for any help or pointer. Please share past experience for good or for worse Free Life Boaz some info: <(gdb) backtrace> #0 0x40cb3a4d in dllname () from /home/wine/lib/wine/mfctest.dll.so #1 0x0094 in ?? () #2 0x40ffec8e in std::basic_iostream >::~basic_iostream() () from /usr/lib/libstdc++.so.5 #3 0x40ffed0a in std::basic_iostream >::~basic_iostream() () from /usr/lib/libstdc++.so.5 #4 0x4104dbb7 in __cxa_dyn_string_eq () from /usr/lib/libstdc++.so.5 #5 0x40feea11 in std::collate::id () from /usr/lib/libstdc++.so.5 #6 0x4000aa4c in _dl_init (main_map=0x3c02eaf0, argc=4, argv=0xb454, env=0xb468) at dl-init.c:68 #7 0x4030a51e in _dl_open () from /lib/i686/libc.so.6 #8 0x4000a828 in _dl_catch_error (objname=0x406d28e0, errstring=0x406d28e4, operate=0x4030a120 <_dl_open+432>, args=0x406d28e8) at dl-error.c:162 #9 0x40309fcf in _dl_open () from /lib/i686/libc.so.6 #10 0x40352f21 in dlopen () from /lib/libdl.so.2 #11 0x4000a828 in _dl_catch_error (objname=0x3c0017e0, errstring=0x3c0017e4, operate=0x40352ef0 , args=0x406d2a68) at dl-error.c:162 #12 0x40353294 in dlerror () from /lib/libdl.so.2 #13 0x40352ed3 in dlopen () from /lib/libdl.so.2 #14 0x40107abc in wine_dlopen (filename=0x3c02eaa0 "/home/wine/lib/wine/mfctest.dll.so", flag=2, error=0x406d2b08 " ¨<@[EMAIL PROTECTED],[EMAIL PROTECTED]@", errorsize=256) at loader.c:577 #15 0x40107420 in dlopen_dll (name=0x406d2c2c "mfctest.dll", error=0x406d2b08 " ¨<@[EMAIL PROTECTED],[EMAIL PROTECTED]@", errorsize=256, test_only=0) at loader.c:156 #16 0x4010795b in wine_dll_load (filename=0x406d2c2c "mfctest.dll", error=0x406d2b08 " ¨<@[EMAIL PROTECTED],[EMAIL PROTECTED]@", errorsize=256) at loader.c:390 #17 0x4009b537 in BUILTIN32_dlopen (name=0x406d2c2c "mfctest.dll", handle=0x406d2c28) at ../../relay32/builtin32.c:63 #18 0x4009b94c in BUILTIN32_LoadLibraryExA (path=0x403ca710 "C:\\WINDOWS\\SYSTEM\\mfctest.dll", flags=0, pwm=0x406d2cc4) at ../../relay32/builtin32
Serious Bug
The simple test crashes wine. And i think many other commands in constructor A() may crash wine. test.cpp: #include #include class A { public: A(); }; A::A() { LoadLibrary("user32.dll"); // all ok user32.dll is present } A a; int WinMain(HINSTANCE hInst, HINSTANCE, LPSTR szCmdLine, int nCmdShow) { return 0; }
Re: French keyboard layout with Euro symbol
Dmitry Timoshkov wrote: "Shachar Shemesh" <[EMAIL PROTECTED]> wrote: The reason I listed it here is because in order for Wine to know what language the current keyboard is, it will also need to know what's the current keyboard. I have thought of two ways for Wine to do that - either it checks what name the symbol files is loaded as, or it scans the keymap (as it does today). Either way - it will have to have some mapping between currently loaded keymap and language. Hence the affect it has over X keyboard detection. I would appretiate it if you tell me if you think this logic is wrong. I see nothing wrong with your logic after that explanation. Yes, we do really want to know the language of the current X keyboard layout, but unfortunately I don't know a way to query this information from X, and all we have now is only the current layout detection scheme with LCID attached to each layout. I was thinking of one of two options. Unfortunetly, both require us to know each keyboard layout we support (though, not necessarily know exactly). 1. Use the current scheme. LCID is all we really need, IIRC. 2. Use the XKB name 2 will mean that we reduce the keyboard source to a table of names, and their respective language IDs. I.e - "us" means English, "fr" means French, "he" means Hebrew etc. This will probably make adding new keyboard easier (and less error prone), but will ONLY work on XKB. Then again, keyboard selection (also part of the currently missing APIs) will only work on XKB anyways, so wer'e probably going to have to soft-depend on XKB whatever we do. Shachar -- Shachar Shemesh Open Source integration consultant Home page & resume - http://www.shemesh.biz/
Re: French keyboard layout with Euro symbol
"Shachar Shemesh" <[EMAIL PROTECTED]> wrote: > The reason I listed it here is because in order for Wine to know what > language the current keyboard is, it will also need to know what's the > current keyboard. > > I have thought of two ways for Wine to do that - either it checks what > name the symbol files is loaded as, or it scans the keymap (as it does > today). Either way - it will have to have some mapping between currently > loaded keymap and language. Hence the affect it has over X keyboard > detection. > > I would appretiate it if you tell me if you think this logic is wrong. I see nothing wrong with your logic after that explanation. Yes, we do really want to know the language of the current X keyboard layout, but unfortunately I don't know a way to query this information from X, and all we have now is only the current layout detection scheme with LCID attached to each layout. -- Dmitry.
New tarball of valgrind for WINE available
A new tarball of valgrind modified to work with WINE is available from the valgrind home page: http://developer.kde.org/~sewardj/ http://developer.kde.org/~sewardj/valgrind-20031012-wine.tar.bz2 this is based on the latest stable valgrind release. use a current CVS or the latest snapshot of WINE. Seeya, Adam -- Real Programmers don't comment their code. If it was hard to write, it should be hard to read, and even harder to modify. These are all my own opinions.
Forwards exports - anyone?
Hi all, I noticed in the code that there is a concept called "forwad_export". Does it have anything to do with making a function in one DLL return a function address that belongs to another? If that is the case, how do I activate this? Is there some spec file magic that will do it? I'm trying to implement unicows.dll. The theory is quite simple - since unicows merely implements unicode functions that exist, theoretically, only in Wine, all I have to do is create forwards (i.e. - ExtTextOutW in unicows.dll will call ExtTextOutW in GDI). This is slightly inefficient, but should solve our unicows.dll problems. If I can merely instruct the dynamic loader to return the GDI ExtTextOutW function when someone tries to link with the unicows ExtTextOutW, I can solve the inefficiency in a clean, working way without further problems. I considered various loader tricks, but I'm afraid the closest I'm willing to come is assembler tricks, and those won't work on other platforms (then again - other platforms are highly unlikely to require unicows - hmm). Shachar -- Shachar Shemesh Open Source integration consultant Home page & resume - http://www.shemesh.biz/
Re: French keyboard layout with Euro symbol
Dmitry Timoshkov wrote: "Shachar Shemesh" <[EMAIL PROTECTED]> wrote: 5. In the future, windows keyboard language APIs will need to be handled. For those to work, we must be aware of which is the current keyboard. This one is just a missing functionality (support for keyboard layouts), and has nothing to do with detection mismatches IMO. The reason I listed it here is because in order for Wine to know what language the current keyboard is, it will also need to know what's the current keyboard. I have thought of two ways for Wine to do that - either it checks what name the symbol files is loaded as, or it scans the keymap (as it does today). Either way - it will have to have some mapping between currently loaded keymap and language. Hence the affect it has over X keyboard detection. I would appretiate it if you tell me if you think this logic is wrong. Shachar -- Shachar Shemesh Open Source integration consultant Home page & resume - http://www.shemesh.biz/
Re: French keyboard layout with Euro symbol
"Shachar Shemesh" <[EMAIL PROTECTED]> wrote: > 5. In the future, windows keyboard language APIs will need to be > handled. For those to work, we must be aware of which is the current > keyboard. This one is just a missing functionality (support for keyboard layouts), and has nothing to do with detection mismatches IMO. -- Dmitry.
How do i find the start menu path?
Hi people, I have a question for my start menu generator, that is almost finished now... How do I find the path of the wine start menu? (for me it's ~/c/windows/Start Menu, but for someone else it does not have to be like that...) Any help here? Grtz, Robert
Re: French keyboard layout with Euro symbol
Dmitry Timoshkov wrote: "Sylvain Petreolle" <[EMAIL PROTECTED]> wrote: At least, the detection mismatches should be fixed/explained IMHO. I think that this topic was explained many times already. Anyway, here is yet another attempt. 1. Keyboard detection code was introduced in order to make some picky DOS games (expecting key presses to have fixed scan codes) work with different X keyboard layouts. Since win32 apps do not depend on it that's not a problem at all for them. 2. Another problem was that each keyboard layout in x11drv had its own code page for X event to unicode translations. That's now solved as well by introducing CP_UNIXCP support. Once the underlying system has a correctly configured locale, keyboard input in Wine (as well as a general locale support) should work just fine. 3. Another (existing) problem is that each keyboard layout still has a virtual keyboard map attached to it. It's unavoidable and needed for correct support for QWERTY/AZERTY/etc. keyboard layouts, when some applications really depend on it. 4. And the last problem I'm aware of is that we need to revamp the keyboard detection code to fill the real keyboard map first, and only then create keyc2vkey array depending on the real mapping, not a hardcoded one. That's a minor problem, which I discovered recently while debugging one of my supported apps. 5. In the future, windows keyboard language APIs will need to be handled. For those to work, we must be aware of which is the current keyboard. Shachar -- Shachar Shemesh Open Source integration consultant Home page & resume - http://www.shemesh.biz/
Re: DINPUT device unacquire (mouse) fix
Andreas Mohr wrote: But don't you think keyboard and joystick might need the same code?? (keyboard has it as well, but with completely different code --> mess) Umm correction to my last post, keyboard already has this working with different code just like you said. (I initially didn't see the implementation, sloppy work) That leaves just the joystick to be fixed. - Hannu Valtonen [EMAIL PROTECTED]
Re: Conformance tests fail with 20031016 build
Hi Sylvain, Sami, What settings are you using for wine? I don't see this problem with WRT, but I've only recently got it back up and running again. On a seperate note, some other strange things I've noticed: One of Monday night's patches seems to have broken a conformance test in listbox.c (line 123) but only for wine in win3.1-mode! Win3.1-mode also passes two todo tests (lines 129 and 134 both in the user/listbox.c). See http://www.astro.gla.ac.uk/users/paulm/WRT/buildinfo.php?id=400#tests-win31 Also, does anyone else get orphaned zombie processes after running the regression tests? (which is moderately impressive: I thought init was supposed to clean these up) I get about six zombies per regression test. I tracked one of these zombies down to the kernel/test/process.c test_DebuggingFlag()'s ContinueDebugEvent() call, which disappears into wineserver. If it helps, the list of installed RPMs is here: http://www.astro.gla.ac.uk/users/paulm/WRT/RPMs Any ideas? Ta, Paul. On Tue, 28 Oct 2003, [iso-8859-1] Sylvain Petreolle wrote: > Hi, got the same errors here with Wine today CVS, > updated RedHat & Gnome system. > > --- Sami Aario <[EMAIL PROTECTED]> a écrit : > > The conformance tests fail for the 20031016 build on my system with > > the following error message: [...] > > msg.c:333: Test failed: ShowWindow:overlapped: in msg 0x0047 > > expecting wParam 0x47 got 0x0 Paul Millar
WinE-Bug? InternetCrackUrl incorrectly sets dwUrlPathLength
Hi, During some application testing, we discovered that WinE does not correctly mimic the WinINet function InternetCrackUrl. The real WinAPI sets the dwUrlPathLength member of the URL_COMPONENTS structure to additionally hold the extra info of the given URL if the extra info is not requested as a separate component. Although this behaviour is not well documented by the Win SDK, it is for instance implemented on WinXP, Win2000 and WinME and therefore might be considered to be intended by Microsoft. The following lines of code demonstrate the problem: LPCTSTR lpszURL = _T("http://www.myserver.com/myscript.php?arg=1";); URL_COMPONENTS url; // call 1: crack out url path and extra info ::ZeroMemory(&url, sizeof(url)); url.dwStructSize = sizeof(url); url.dwHostNameLength = 1; url.dwUrlPathLength = 1; url.dwExtraInfoLength = 1; ::InternetCrackUrl(lpszURL, 0, 0, &url); // dwUrlPathLength is 13, holding "/myscript.php" // call 2: only crack out url path ::ZeroMemory(&url, sizeof(url)); url.dwStructSize = sizeof(url); url.dwHostNameLength = 1; url.dwUrlPathLength = 1; ::InternetCrackUrl(lpszURL, 0, 0, &url); // now, dwUrlPathLength should be 19, holding "/myscript.php?arg=1", // while WinE still sets it to 13 OK, it is of course no great deal to write code that correctly runs on real Win systems and on WinE (2-3 lines did it). But programers who rely on this behaviour will for example wonder why their applications don't transmit any HTTP GET parameters when they call HttpOpenRequest with lpszObjectName set to the URL path component returned by InternetCrackUrl... This applies to Wine 20031016, haven't found any recent report on this though. /jan.
Re: DINPUT device unacquire (mouse) fix
Andreas Mohr wrote: But don't you think keyboard and joystick might need the same code?? (keyboard has it as well, but with completely different code --> mess) This could probably be cleaned up. I have a patch semi-ready which does the same for keyboard/joystick using the existing scheme.. but I was wondering whether or not we should clean up this mess? Any opinions? Should I a) send the fixes for keyboard/joystick using the existing scheme or b) should we start reusing/cleaning the code? If the answer turns out to be b) and you/someone else doesn't want to take the job I'm going to need a bit of handholding as I'm rather new to Wine development. - Hannu Valtonen [EMAIL PROTECTED]