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]
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: 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: 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.
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.
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/
Serious Bug
The simple test crashes wine.
And i think many other commands in constructor A() may crash wine.
test.cpp:
#include windows.h
#include stdio.h
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;
}
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_iostreamwchar_t, std::char_traitswchar_t ::~basic_iostream() () from /usr/lib/libstdc++.so.5 #3 0x40ffed0a in std::basic_iostreamwchar_t, std::char_traitswchar_t ::~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::collatechar::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 dlopen+80, 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,
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
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
Boaz Harrosh wrote: use --wrap in winemaker. Read about this option in the documentation Thanks. It is work :)
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.
Cpp_Globs_stop.cpp
#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 ;
/Cpp_Globs_stop.cpp
Makefile snippet
$(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 \
/Makefile snippet
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: 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 stdio.h
#include windows.h
#include shlobj.h
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! +++
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: 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: [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
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 LX:\\TMP18467.$$$ GENERIC_READ GENERIC_WRITE
FILE_SHARE_READ FILE_SHARE_WRITE CREATE_NEW attributes 0x0
000a:trace:dosfs:DOSFS_GetFullName LX:\\TMP18467.$$$ (last=0)
000a:trace:string:lstrcpynA (0x40f40d84, /tmp, 1024)
000a:trace:dosfs:DOSFS_FindUnixName /tmp,LTMP18467.$$$
000a:trace:dosfs:DOSFS_ToDosFCBFormat (LTMP18467.$$$, 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 LTMP18467.$$$ not found in '/tmp'
000a:trace:heap:RtlFreeHeap (0x4037,0002,415cc890): returning TRUE
000a:trace:dosfs:DOSFS_GetFullName returning /tmp/TMP18467.$$$ = LX:\\tmp18467.$$$
000a:trace:dosfs:GetDriveTypeW (LX:\\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 regards,
Valentijn
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
subhobrotosinha at yahoo.com 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 subhobrotosinha at yahoo.com.
+*/
+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: 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
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: 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]
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
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]
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: 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.
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: snip 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
