Re: mswsock:Implement 3 functions by calling through SIO_GET_EXTENSION_FUNCTION_POINTER
You should mention somewhere (FIXME or TODO or something) what the code currently rely on socket being not used by WSAIoctl. IIRC Windows won't let you call WSAIoctl(0, ...) Correct way would be to retrieve both AcceptEx and GetAcceptExSockaddrs routine addresses in AcceptEx wrapper and store lpOutputBuffer-fn mapping somewhere. Jon Griffiths wrote: Hi, This is part one of a patch set that implements TransmitFile/Transmit packets and fixes bug 5048. This first part implements AcceptEx/GetAcceptExSockaddrs TransmitFile by calling them from ws2_32 using SIO_GET_EXTENSION_FUNCTION_POINTER. Next up is the implementation itself. Cheers Jon
Re: Pipeline separation preview
Looks good to me. You should probably start submitting it bit by bit, see if any regression come up, although it looks pretty safe to me.
CreateFontIndirectEx and GetCharacterPlacement patches
Is it something wrong with these patches: http://www.winehq.org/pipermail/wine-patches/2008-June/056807.html http://www.winehq.org/pipermail/wine-patches/2008-June/056808.html They are related to bugs #13064 and #13094..
Re: test for RasEnumDevicesA [2/2]
Please use this version
Am Sunday 06 July 2008 13:49 schrieb Stefan Leichter:
ChangeLog
-
added some more tests for RasEnumDevicesA, fix wine not to crash on the
tests
--- dlls/rasapi32/rasapi.c.2 2008-07-06 13:30:22.0 +0200
+++ dlls/rasapi32/rasapi.c 2008-07-06 13:31:11.0 +0200
@@ -249,7 +249,7 @@
return ERROR_INVALID_PARAMETER;
FIXME((%p,%p,%p),stub!\n,lpRasDevinfo,lpcb,lpcDevices);
- if (*lpcb sizeof(RASDEVINFOA)) {
+ if (!lpRasDevinfo || (*lpcb sizeof(RASDEVINFOA))) {
*lpcb = sizeof(RASDEVINFOA);
return ERROR_BUFFER_TOO_SMALL;
}
--- dlls/rasapi32/tests/rasapi.c.orig 2008-07-06 11:51:19.0 +0200
+++ dlls/rasapi32/tests/rasapi.c 2008-07-06 13:33:54.0 +0200
@@ -53,14 +53,78 @@
return;
}
+/* test first parameter */
result = pRasEnumDevicesA(NULL, cb, cDevices);
trace(RasEnumDevicesA: buffersize %d\n, cb);
ok(result == ERROR_BUFFER_TOO_SMALL,
Expected ERROR_BUFFER_TOO_SMALL, got %08d\n, result);
+cb = sizeof(rasDevInfo);
+result = pRasEnumDevicesA(NULL, cb, cDevices);
+ok(result == ERROR_BUFFER_TOO_SMALL,
+Expected ERROR_BUFFER_TOO_SMALL, got %08d\n, result);
+
+rasDevInfo.dwSize = 0;
+result = pRasEnumDevicesA(rasDevInfo, cb, cDevices);
+todo_wine
+ok(result == ERROR_INVALID_SIZE,
+Expected ERROR_INVALID_SIZE, got %08d\n, result);
+
+rasDevInfo.dwSize = sizeof(rasDevInfo) -1;
+result = pRasEnumDevicesA(rasDevInfo, cb, cDevices);
+todo_wine
+ok(result == ERROR_INVALID_SIZE,
+Expected ERROR_INVALID_SIZE, got %08d\n, result);
+
+rasDevInfo.dwSize = sizeof(rasDevInfo) +1;
+result = pRasEnumDevicesA(rasDevInfo, cb, cDevices);
+todo_wine
+ok(result == ERROR_INVALID_SIZE,
+Expected ERROR_INVALID_SIZE, got %08d\n, result);
+
+/* test second parameter */
+rasDevInfo.dwSize = sizeof(rasDevInfo);
result = pRasEnumDevicesA(rasDevInfo, NULL, cDevices);
ok(result == ERROR_INVALID_PARAMETER,
Expected ERROR_INVALID_PARAMETER, got %08d\n, result);
+
+cb = 0;
+result = pRasEnumDevicesA(rasDevInfo, cb, cDevices);
+ok(result == ERROR_BUFFER_TOO_SMALL,
+Expected ERROR_BUFFER_TOO_SMALL, got %08d\n, result);
+
+cb = sizeof(rasDevInfo) -1;
+result = pRasEnumDevicesA(rasDevInfo, cb, cDevices);
+ok(result == ERROR_BUFFER_TOO_SMALL,
+Expected ERROR_BUFFER_TOO_SMALL, got %08d\n, result);
+
+cb = sizeof(rasDevInfo) +1;
+result = pRasEnumDevicesA(rasDevInfo, cb, cDevices);
+todo_wine
+ok(result == ERROR_BUFFER_TOO_SMALL,
+Expected ERROR_BUFFER_TOO_SMALL, got %08d\n, result);
+
+/* test third parameter */
+cb = sizeof(rasDevInfo);
+result = pRasEnumDevicesA(rasDevInfo, cb, NULL);
+ok(result == ERROR_INVALID_PARAMETER,
+Expected ERROR_INVALID_PARAMETER, got %08d\n, result);
+
+/* test combinations of invalid parameters */
+result = pRasEnumDevicesA(NULL, NULL, cDevices);
+ok(result == ERROR_INVALID_PARAMETER,
+Expected ERROR_INVALID_PARAMETER, got %08d\n, result);
+
+result = pRasEnumDevicesA(NULL, cb, NULL);
+ok(result == ERROR_INVALID_PARAMETER,
+Expected ERROR_INVALID_PARAMETER, got %08d\n, result);
+
+cb = 0;
+rasDevInfo.dwSize = 0;
+result = pRasEnumDevicesA(rasDevInfo, cb, cDevices);
+todo_wine
+ok(result == ERROR_INVALID_SIZE,
+Expected ERROR_INVALID_SIZE, got %08d\n, result);
}
START_TEST(rasapi)
Re: programs: add rudimentary dxdiag
On Mi, 2008-07-02 at 23:02 +, Louis Lenders wrote: so for now i'd have to guess : 1. no need for a dxdiag in wine 2. my patches are too crappy to respond to. In both cases it's useless to leave thebug i opened for missing dxdiag open, so i'll abandon it (bug 14118) Louis, please do not give up and reopen the bug. You got already some comments, and I want to give some more Ideas. - You told, that you reuse the code for the cube from the internet. That is a no-go because of copyright and license issues! Where does the code came from? What is the license for that code? - Remember, that Wine is LGPL v2.1 or later. - You can't use GPL code (That would force Wine to GPL) - You can't use LGPL v3 code (That would force Wine to LGPL v3) The code works, as show in your demonstration, but IMHO the best thing is to use the math. formula with a clean implementation from scratch. - Multiple backends with support for different color-depth should then be possible: OpenGL, GDI, DX7, DX8, DX9. - You told, that minimizing the Cube-Window does not work now, but worked in an old Wine. You think, that this is an Regression in Wine. It's also possible, that there was an bug in Wine which is now fixed and your dxdiag code is not correct. Only a Regression-Test can help for this issue. Again, a clean implementation can avoid this issue. Thanks for helping Wine -- By by ... Detlef
Patch feedback
Hello, I would really appreciate any feedback as to how these patches can be improved so that they will be accepted into Wine. regedit: Add support for importing Unicode files http://www.winehq.org/pipermail/wine-patches/2008-June/056856.html I know this patch is a little big, but I'm not sure how it could be split up without possible data loss on import. Is that acceptable? I could for instance make a first patch that merely reads the file as Uncode then converts each line to multibyte characters. user32: Always use old-style colours for Windows 3.x http://www.winehq.org/pipermail/wine-patches/2008-June/056898.html Alexander N. Sørnes
Re: richedit: do not read actual scrollbar state for scrollbar update, use internal state instead (RESEND)
On Fr, 2008-07-04 at 16:32 -0500, Alex Villacís Lasso wrote: Resending. Please comment on this patch. dlls/riched20/editor.c | 21 ++ dlls/riched20/editstr.h |3 + dlls/riched20/paint.c| 36 ++- dlls/riched20/tests/editor.c | 794 ++ 4 files changed, 844 insertions(+), 10 deletions(-) I have no Idea about riched20, but your patch is far to huge. - Do not submit dead code: * reportScrollRanges - Do not submit debugging code: * There is no need to flood the output with trace() Fine during development, but remove that before you create a Patch - The implementation is enough for a seperate Patch - Please add only a basic Test in a Patch - Add more Tests in seperate Patches: * Every DestroyWindow(hwndRichEdit) is the end of a Patch Thanks -- By by ... Detlef
Re: New winetricks 20080704: added firefox3, kde verbs (and a whole lot of other stuff)
В сообщении от 4 июля 2008 Dan Kegel написал(a):
Another week, another winetricks.
Please check attached patch with fixes agains 20080704 version of winetricks.
Changes:
- introduce WINDIR variable with Unix path to windows dir (and use it
instead $WINEPREFIX/drive_c/windows)
- wrap kdialog/xmessage using with variable to disable extra requires during
creating a rpm package
- add missed quites and remove extra spaces
Online as always at
http://kegel.com/wine/winetricks
or
http://winezeug.googlecode.com
--
Vitaly Lipatov, ALT Linux Team
Russia, Saint-Petersburg, www.etersoft.ru
--- winetricks.orig 2008-07-06 17:35:23 +0400
+++ winetricks 2008-07-06 17:35:27 +0400
@@ -14,12 +14,13 @@
# Internal variables; these locations are not too important
WINETRICKS_CACHE=$HOME/winetrickscache
# Default to hiding the directory, by popular demand
-test -d $WINETRICKS_CACHE || WINETRICKS_CACHE=$HOME/.winetrickscache
-WINETRICKS_TMP=$WINEPREFIX/drive_c/winetrickstmp
+test -d $WINETRICKS_CACHE || WINETRICKS_CACHE=$HOME/.winetrickscache
+WINDIR=$WINEPREFIX/dosdevices/c:/windows
+WINETRICKS_TMP=$WINDIR/temp/winetrickstmp
mkdir -p $WINETRICKS_TMP
-WINETRICKS_TMP_WIN='c:\winetrickstmp'
+WINETRICKS_TMP_WIN='c:\windows\temp\winetrickstmp'
-# Which sourceforge mirror to use. Rotate based on time, since
+# Which sourceforge mirror to use. Rotate based on time, since
# their mirror picker sometimes persistantly sends you to a broken
# mirror.
case `date +%S` in
@@ -174,7 +175,8 @@
args=$args $1 $1 off
shift
done
-kdialog --title $title --separate-output --checklist $text $args
+KDIALOG=kdialog
+$KDIALOG --title $title --separate-output --checklist $text $args
}
x_showmenu() {
@@ -197,7 +199,8 @@
shift
done
(echo $title; echo ; echo $text) /tmp/x_showmenu.txt
-xmessage -print -file /tmp/x_showmenu.txt -buttons Cancel,$args | sed 's/Cancel//'
+XMESSAGE=xmessage
+$XMESSAGE -print -file /tmp/x_showmenu.txt -buttons Cancel,$args | sed 's/Cancel//'
}
showmenu()
@@ -248,11 +251,11 @@
programfilesdir_unix=`$WINE winepath -u $programfilesdir_win`
# Did the user rename Fonts to fonts?
-if ! test -d $WINEPREFIX/drive_c/windows/Fonts test -d $WINEPREFIX/drive_c/windows/fonts
+if ! test -d $WINDIR/Fonts test -d $WINDIR/fonts
then
-winefontsdir=$WINEPREFIX/drive_c/windows/fonts
+winefontsdir=$WINDIR/fonts
else
-winefontsdir=$WINEPREFIX/drive_c/windows/Fonts
+winefontsdir=$WINDIR/Fonts
fi
# Mac folks tend to not have sha1sum, but we can make do with openssl
@@ -376,7 +379,7 @@
do
case $1 in
comctl32)
- rm -rf $WINEPREFIX/drive_c/windows/winsxs/manifests/x86_microsoft.windows.common-controls_6595b64144ccf1df_6.0.2600.2982_none_deadbeef.manifest
+ rm -rf $WINDIR/winsxs/manifests/x86_microsoft.windows.common-controls_6595b64144ccf1df_6.0.2600.2982_none_deadbeef.manifest
;;
esac
echo \$1\=\$mode\ $WINETRICKS_TMP/override-dll.reg
@@ -403,7 +406,7 @@
do
case $1 in
comctl32)
- rm -rf $WINEPREFIX/drive_c/windows/winsxs/manifests/x86_microsoft.windows.common-controls_6595b64144ccf1df_6.0.2600.2982_none_deadbeef.manifest
+ rm -rf $WINDIR/winsxs/manifests/x86_microsoft.windows.common-controls_6595b64144ccf1df_6.0.2600.2982_none_deadbeef.manifest
;;
esac
echo \$1\=\$mode\ $WINETRICKS_TMP/override-dll.reg
@@ -435,7 +438,7 @@
load_art2kmin() {
download . http://download.microsoft.com/download/office2000dev/art2kmin/1/win98/en-us/art2kmin.exe 73be2622254d1f857a204a03f068787542b985e9
try $WINE $WINETRICKS_CACHE/art2kmin.exe
-cd $WINEPREFIX/drive_c/ART2KMin Setup
+cd $WINDIR/../ART2KMin Setup
try $WINE Setup.exe INSTALLPFILES=1 /wait $WINETRICKS_QUIET
cd $olddir
}
@@ -455,8 +458,8 @@
try $WINE $WINETRICKS_CACHE/cc32inst.exe /T:`$WINE winepath -w $WINETRICKS_TMP` /c $WINETRICKS_QUIET
try $WINE $WINETRICKS_TMP/comctl32.exe
-try $WINE $WINEPREFIX/drive_c/windows/temp/x86/50ComUpd.Exe /T:`$WINE winepath -w $WINETRICKS_TMP` /c $WINETRICKS_QUIET
-cp $WINETRICKS_TMP/comcnt.dll $WINEPREFIX/drive_c/windows/system32/comctl32.dll
+try $WINE $WINDIR/temp/x86/50ComUpd.Exe /T:`$WINE winepath -w $WINETRICKS_TMP` /c $WINETRICKS_QUIET
+cp $WINETRICKS_TMP/comcnt.dll $WINDIR/system32/comctl32.dll
override_dlls native,builtin comctl32
}
@@ -468,8 +471,8 @@
download . http://download.microsoft.com/download/3/a/5/3a5925ac-e779-4b1c-bb01-af67dc2f96fc/VisualBasic6-KB896559-v1-ENU.exe f52cf2034488235b37a1da837d1c40eb2a1bad84
try cabextract -q --directory=$WINETRICKS_TMP $WINETRICKS_CACHE/VisualBasic6-KB896559-v1-ENU.exe
-cp $WINETRICKS_TMP/mscomctl.ocx $WINEPREFIX/drive_c/windows/system32/mscomctl.ocx
-cp $WINETRICKS_TMP/comctl32.ocx $WINEPREFIX/drive_c/windows/system32/comctl32.ocx
+cp $WINETRICKS_TMP/mscomctl.ocx
RE: Pipeline separation preview
Looks good to me. You should probably start submitting it bit by bit, see if any regression come up, although it looks pretty safe to me. Sure, that's the plan. I don't think submitting 50+ patches at once will work well. I have found 2 minor regressions, but fixed them already in my tree. (Mostly incorrect calls in some state handler, like calling across pipeline parts into a specific implementation of another pipeline part)
Re: Alternate shell?
On Do, 2008-05-22 at 15:16 -0700, Dan Kegel wrote: For a maximal dogfood experience, I was looking around for a way to use a replacement Windows shell with Wine as my desktop environment instead of gnome or kde. Wow. So far, all the ones I've found are either broken, hard to use, or just plain weird. Anyone have a favorite I should try? http://www.calmira.net Examples: http://www.calmira.net/screenshots/stephan.htm http://www.calmira.net/screenshots/chris_p.htm http://www.calmira.net/screenshots/pcfreak2.htm Related work: Calmira_XP: http://www.abzone.be/calmira_calxp Calmira_Longhorn: http://calmira.co.nr/ Example: http://www.postimage.org/image.php?v=aVBPR4r # Test Calmira_Longhorn: cd wine_c_drive wget http://calmira.kyblsoft.sk/dwnlds/callh36.zip unzip callh36.zip cd CALMIRA To avoid, that the explorer.exe from calmira is used for the desktop, you need the full path to explorer.exe.so wine your_build_path/programs/explorer/explorer.exe.so /desktop=xxx,800x600 CALMIRA.EXE Sometimes, http://www.calmira.org is referenced, but that is outdated and give you an advertising website -- By by ... Detlef
Re: New winetricks 20080704: added firefox3, kde verbs (and a whole lot of other stuff)
Vitaly Lipatov wrote: В сообщении от 4 июля 2008 Dan Kegel написал(a): Another week, another winetricks. Please check attached patch with fixes agains 20080704 version of winetricks. Changes: - introduce WINDIR variable with Unix path to windows dir (and use it instead $WINEPREFIX/drive_c/windows) - wrap kdialog/xmessage using with variable to disable extra requires during creating a rpm package - add missed quites and remove extra spaces Online as always at http://kegel.com/wine/winetricks or http://winezeug.googlecode.com Guessing windir is a bad thing. You should use this instead: WINDIR=$(wine winepath -u $(wine cmd /c echo %windir%)) Same applies to other system directories like Program Files. Vitaliy.
Re: Patch feedback
On Sun, Jul 6, 2008 at 6:55 AM, Alexander Nicolaysen Sørnes [EMAIL PROTECTED] wrote: Hello, I would really appreciate any feedback as to how these patches can be improved so that they will be accepted into Wine. regedit: Add support for importing Unicode files http://www.winehq.org/pipermail/wine-patches/2008-June/056856.html I know this patch is a little big, but I'm not sure how it could be split up without possible data loss on import. Is that acceptable? I could for instance make a first patch that merely reads the file as Uncode then converts each line to multibyte characters. Sure. How about: 1 patch for the first two utility functions. 1 patch for each W version of an existing function. 1 or 2 patches to glue it all together.
Re: mlang/tests: don't assume output of ConvertStringFromUnicode is null terminated
2008/7/6 Dan Kegel [EMAIL PROTECTED]: The mlang test assumed that the output of ConvertStringFromUnicode was null terminated, but it seems not to be. Fixes the valgrind warning: Conditional jump or move depends on uninitialised value(s) at strlen (mc_replace_strmem.c:242) by lstrlenA (string.c:364) by ConvertINetMultiByteToUnicode (mlang.c:526) by ConvertINetString (mlang.c:633) by fnIMultiLanguage2_ConvertString (mlang.c:2197) by check_convertible (mlang.c:287) by test_EnumCodePages (mlang.c:407) Uninitialised value was created by a stack allocation at check_convertible (mlang.c:270) I believe James was trying to fix this with http://www.winehq.org/pipermail/wine-patches/2008-June/056454.html but missed (he thought the problem was on the destination len, but really it was on the source len?). No, this is hiding a bug. The test code conforms with the API. The problem is that ConvertINetMultiByteToUnicode uses the value of an out-only parameter (NULL pDstStr, non-NULL pcDstSize). Check out the code block in mlang.c:632. -- James Hawkins
CUDA wrapper
As a continuation from the question on making the FAH GPU2 Nvidia client run, we have gotten past the detecting the card as we changed Wine's generic output to look like an Nvidia card thanks to a few of you. Now comes the hard part. Even when using the cudart.dll file it does not work. We get an cudastream error about it not being implemented. It then repeats these 5 lines until the client is stopped. Reading file work/wudata_07.tpr, VERSION 3.1.4 (single precision) Reading file work/wudata_07.tpr, VERSION 3.1.4 (single precision) Reading sasa-enabled ir 0 0 Initializing Nvidia gpu library cudaMalloc CUDAStream::Allocate failed feature is not yet implemented Martijn Berger said here ( http://www.winehq.org/pipermail/wine-devel/2008-July/067063.html) that all that should need to be done is right a wrapper to translate the calls from cudart.dll to libcuda.so.2.0. I suppose the place to start would be to download the SDK's and see how much documentation is available on both the Linux and Windows calls. -Seth Shelnutt
Re: Patch feedback
Lei Zhang a écrit : On Sun, Jul 6, 2008 at 6:55 AM, Alexander Nicolaysen Sørnes [EMAIL PROTECTED] wrote: Hello, I would really appreciate any feedback as to how these patches can be improved so that they will be accepted into Wine. regedit: Add support for importing Unicode files http://www.winehq.org/pipermail/wine-patches/2008-June/056856.html I know this patch is a little big, but I'm not sure how it could be split up without possible data loss on import. Is that acceptable? I could for instance make a first patch that merely reads the file as Uncode then converts each line to multibyte characters. Sure. How about: 1 patch for the first two utility functions. 1 patch for each W version of an existing function. 1 or 2 patches to glue it all together. duplicating a lot of functions for A/W compatibility just shows that the internals of regedit should be moved to unicode first then your patch will be relatively straightforward A+ -- Eric Pouech The problem with designing something completely foolproof is to underestimate the ingenuity of a complete idiot. (Douglas Adams)
Re: mpr: Add Russian translation
Aleksey Bragin wrote: All those things have been translated more than 2 years ago and submitted here (attaching again). The quality, for example in mpr.dll is even better (vs. the patch by Vitaliy Margolen which was committed 7d3a5af43ea0d66a0596a4fac22cf88ae50d2745 in april, 2008). Please, Vitaliy, or any other russian here, rework these patches so they could be applied against recent Wine head, or use them as inspiration for your work. I don't have time to do this at the moment, unfortunately. Please send one dll at a time as a patch (plain text attachment, no zips, not binaries). Also the are only few things left untranslated (crypt32 and kernel error messages). Why are you sending shdocvw which is already 100% translated? Same for shlwapi. Vitaliy.
Re: CUDA wrapper
From reading the programing guide and reference manual it seems that most of the function are the same as expected between Windows and Linux, in fact the reference manual doesn't differentiate between the two. http://developer.download.nvidia.com/compute/cuda/2.0-Beta2/docs/Programming_Guide_2.0beta2.pdf http://developer.download.nvidia.com/compute/cuda/2.0-Beta2/docs/CudaRefMan_2.0beta2.pdf Is it possible to just symbolicly link the cudart.dll file to the libcudart.so file? If they are expecting mostly the same function calls should this not work? They are going to test this now and see. I believe the main problem is just that cudart.dll is driving to access the windows nvidia driver where this is none, but libcudart.so knows how to access the linux driver.
Re: CUDA wrapper
Am Sonntag, den 06.07.2008, 18:23 -0400 schrieb Seth Shelnutt: Is it possible to just symbolicly link the cudart.dll file to the libcudart.so file? If they are expecting mostly the same function calls should this not work? They are going to test this now and see. This is not going to work. PE style dynamic linking works quite different from ELF style dynamic linking. Wine can not link native ELF libraries to windows applications. The .dll.so files from wine are special in being ELF files but containing extra information that allows the Wine dynamic linker to link it into PE processes. I believe the main problem is just that cudart.dll is driving to access the windows nvidia driver where this is none, but libcudart.so knows how to access the linux driver. This is right. You need at least a correct .spec file to make a wine dll. You still have to implement a wrapper for each function, as Windows usually uses the stdcall calling convention, whereas linux uses cdecl by default. There might be some way to automate writing the wrapper functions. Regards, Michael Karcher
Re: Crashes in winetest under wine
2008/7/3 Austin Lund [EMAIL PROTECTED]: I get a crash all the time in winetest since 1.0. Seems there is not a problem with any of the tests themselves (i.e. running make test). The last few lines of output from winetest is: fixme:xrandr:X11DRV_XRandR_SetCurrentMode Cannot change screen BPP from 32 to 8 fixme:xrandr:X11DRV_XRandR_SetCurrentMode Cannot change screen BPP from 32 to 16 err:x11settings:X11DRV_ChangeDisplaySettingsEx No matching mode found 1440x900x24 @0! (XRandR) err:ntdll:RtlpWaitForCriticalSection section 0x7bc91824 loader.c: loader_section wait timed out in thread 0039, blocked by 0036, retrying (60 sec) wine: Critical section 7bc91824 wait failed at address 0x7bc3ab60 (thread 0039), starting debugger... err:seh:raise_exception Unhandled exception code c194 flags 0 addr 0x7bc3ab60 And the output file made in /tmp has at the end: uxtheme:system start dlls/uxtheme/tests/system.c - system.c:491: Starting test_IsThemed() system.c:87: Theming is inactive system.c:495: Starting test_GetWindowTheme() system.c:499: Starting test_SetWindowTheme() system.c:503: Starting test_OpenThemeData() system.c:263: No active theme, skipping rest of OpenThemeData tests system.c:507: Starting test_GetCurrentThemeName() system.c:511: Starting test_CloseThemeData() system: 45 tests executed (11 marked as todo, 0 failures), 0 skipped. uxtheme:system done (0) It takes quite a long time to get to the point where it crashes so I'd be open to ideas as to how to narrow this down quicker. I'm running everything on a clean install with an empty ~/.wine directory. I still get this. When doing make test in uxtheme everything is fine. The next test to be run is version, but it also works fine. Does anyone have any idea how to start debuging this?
RE: CUDA wrapper
This is right. You need at least a correct .spec file to make a wine dll. You still have to implement a wrapper for each function, as Windows usually uses the stdcall calling convention, whereas linux uses cdecl by default. There might be some way to automate writing the wrapper functions. opengl32.dll has a perl script for that I think
Re: CUDA wrapper
I writing a wrapper, would it be correct to more or less follow this guide, on winelib dll's? http://www.winehq.org/site/docs/winelib-guide/bindlls I've never coded anything for Wine before so I want to make sure I do it right from the beginning instead of having to go back and make drastic changes. I'll be looking at that opengl32 perl script because there is 102 pages of functions that cudart.dll and libcudart.so both contain. On Sun, Jul 6, 2008 at 6:53 PM, Michael Karcher [EMAIL PROTECTED] wrote: This is not going to work. PE style dynamic linking works quite different from ELF style dynamic linking. Wine can not link native ELF libraries to windows applications. The .dll.so files from wine are special in being ELF files but containing extra information that allows the Wine dynamic linker to link it into PE processes. This is right. You need at least a correct .spec file to make a wine dll. You still have to implement a wrapper for each function, as Windows usually uses the stdcall calling convention, whereas linux uses cdecl by default. There might be some way to automate writing the wrapper functions. Regards, Michael Karcher
RE: CUDA wrapper
Yes, this guide is reasonable, except probably the building part. You *may* want to write this DLL as part of Wine, although I am afraid that we don't have a policy how to deal with non-Windows DLLs(since cuda is an Nvidia thing, not from MS). Of course the 5.5 part doesn't apply then as well. From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Seth Shelnutt Sent: Sunday, July 06, 2008 6:29 PM To: Michael Karcher Cc: wine-devel@winehq.org Subject: Re: CUDA wrapper I writing a wrapper, would it be correct to more or less follow this guide, on winelib dll's? http://www.winehq.org/site/docs/winelib-guide/bindlls I've never coded anything for Wine before so I want to make sure I do it right from the beginning instead of having to go back and make drastic changes. I'll be looking at that opengl32 perl script because there is 102 pages of functions that cudart.dll and libcudart.so both contain. On Sun, Jul 6, 2008 at 6:53 PM, Michael Karcher [EMAIL PROTECTED] wrote: This is not going to work. PE style dynamic linking works quite different from ELF style dynamic linking. Wine can not link native ELF libraries to windows applications. The .dll.so files from wine are special in being ELF files but containing extra information that allows the Wine dynamic linker to link it into PE processes. This is right. You need at least a correct .spec file to make a wine dll. You still have to implement a wrapper for each function, as Windows usually uses the stdcall calling convention, whereas linux uses cdecl by default. There might be some way to automate writing the wrapper functions. Regards, Michael Karcher
Re: CUDA wrapper
Ok, please forgive my naivety but this is my first attempt and all, I am lost and need come guidance, the guide is of some help and so is looking at the opengl files. I am not sure exactly what I am trying to write. What is the difference between a dll form Wine and a dll.so? I know the dll.so end up in your linux /lib folder right? How does a dll communicate to this dll.so? How am I to write this dll file so that when the fah gpu app calls for a function the cudart.dll file acts as a link to the libcudart.so.2.0? I don't want to attempt to rewrite the entire dll if I don't have to. To me it just seems like I am not getting the picture. I know we can't simply link the two files because they are in two different formats ELF vs PE. Is there a good example on how this is done? I'm sure this has been done before. Again looking to the opengl_norm.c file all it appears is that every functions has been rewritten but with wine_ in front of the function name. Is that all I need to do with the cudart? That just seem right. I probably should even be messing with this stuff, but the beautify of open source applications is that with a little help from the community I can add in support for things I need (CUDA). If this was a closed source app, I would have to just put in a request for it and maybe in a few months or so they might think about adding support. Thanks for your patience and help On Sun, Jul 6, 2008 at 10:13 PM, Stefan Dösinger [EMAIL PROTECTED] wrote: Yes, this guide is reasonable, except probably the building part. You *may* want to write this DLL as part of Wine, although I am afraid that we don't have a policy how to deal with non-Windows DLLs(since cuda is an Nvidia thing, not from MS). Of course the 5.5 part doesn't apply then as well. *From:* [EMAIL PROTECTED] [mailto: [EMAIL PROTECTED] *On Behalf Of *Seth Shelnutt *Sent:* Sunday, July 06, 2008 6:29 PM *To:* Michael Karcher *Cc:* wine-devel@winehq.org *Subject:* Re: CUDA wrapper I writing a wrapper, would it be correct to more or less follow this guide, on winelib dll's? http://www.winehq.org/site/docs/winelib-guide/bindlls I've never coded anything for Wine before so I want to make sure I do it right from the beginning instead of having to go back and make drastic changes. I'll be looking at that opengl32 perl script because there is 102 pages of functions that cudart.dll and libcudart.so both contain. On Sun, Jul 6, 2008 at 6:53 PM, Michael Karcher [EMAIL PROTECTED] wrote: This is not going to work. PE style dynamic linking works quite different from ELF style dynamic linking. Wine can not link native ELF libraries to windows applications. The .dll.so files from wine are special in being ELF files but containing extra information that allows the Wine dynamic linker to link it into PE processes. This is right. You need at least a correct .spec file to make a wine dll. You still have to implement a wrapper for each function, as Windows usually uses the stdcall calling convention, whereas linux uses cdecl by default. There might be some way to automate writing the wrapper functions. Regards, Michael Karcher
RE: CUDA wrapper
Ok, please forgive my naivety but this is my first attempt and all,
No worries. This list is here for help in such cases(although I am not that
experienced in that area)
I am lost and need come guidance, the guide is of some help and so is
looking at the
opengl files. I am not sure exactly what I am trying to write. What is the
difference
between a dll form Wine and a dll.so? I know the dll.so end up in your
linux /lib
folder right? How does a dll communicate to this dll.so?
There are 3 file extensions:
.so: Those are ELF shared object files which Linux uses. Linux apps can link
to them, Windows apps can't due to reasons pointed out earlier
.dll: Those are PE files, which Windows apps can link to, but the Linux
dynamic loader can't parse
.dll.so: Those are Wine DLLs. Technically they are .so files, but with extra
information added for linking them with Windows apps.
A Windows app classically links to .dll and .exe files(.exe is just a .dll
with a main() function in it). Wine can use its own builtin .dll.so
implementations of a DLL. Those libraries are loaded by the Linux dynamic
loader, so a .dll.so can link to other Linux libraries(e.g. libcuda.so).
That way you can write functions that serve as Win32 API entrypoints for
Windows apps and call Linux APIs themselves.
How am I to write this dll file so that when the fah gpu app calls for a
function the
cudart.dll file acts as a link to the libcudart.so.2.0? I don't want to
attempt to
rewrite the entire dll if I don't have to. To me it just seems like I am
not getting
the picture. I know we can't simply link the two files because they are in
two
different formats ELF vs PE. Is there a good example on how this is done?
I'm sure
this has been done before. Again looking to the opengl_norm.c file all it
appears is
that every functions has been rewritten but with wine_ in front of the
function
name. Is that all I need to do with the cudart? That just seem right.
You don't want to rewrite CUDA in the way we rewrite e.g. d3d9.dll, since
that would mean to talk to the GPU or driver directly without Nvidia's
libcudart.so.2.0. You just want to write functions that simply call the
function exported from the Linux library. For example, like in the opengl
stuff:
FancyCudaReturnValue wine_CudaSomeFunc(int a, int b) {
return CudaSumeFunc(a, b);
}
That's not really called a rewrite(e.g. look at ole32 to see what would be
considered a rewrite), but rather a thunk. Unfortunately it can still be a
a whole lot of typing work, unless you manage to write a script to generate
the thunks.
You have to take if there are some differences between the Linux and Windows
functions, e.g.:
Win32: CudaSomething(HWND window);
Linux: CudaSomething(XWindow window);
In this case you can't just pass the Windows specific data structure
along(Don't ask me how you would solve this exact issue here since only
winex11.drv is supposed to know about the HWND-XWindow mappings.)
You also have to take care with filenames:
Win32: CudaSomething2(const char *filename);
Linux: CudaSomething2(const char *filename);
The Linux function would not be happy if you pass it a
C:\Path\to\some\odd\place.txt, and likewise the Windows app will not be
happy if you pass it a /home/user/my/fancy/location.txt file returned from
cuda. For cases like these, Wine provides functions to translate paths.
Re: New winetricks 20080704: added firefox3, kde verbs (and a whole lot of other stuff)
On Sun, Jul 6, 2008 at 11:55 AM, Vitaliy Margolen [EMAIL PROTECTED] wrote: Vitaly Lipatov wrote: В сообщении от 4 июля 2008 Dan Kegel написал(a): Another week, another winetricks. Please check attached patch with fixes agains 20080704 version of winetricks. Changes: - introduce WINDIR variable with Unix path to windows dir (and use it instead $WINEPREFIX/drive_c/windows) - wrap kdialog/xmessage using with variable to disable extra requires during creating a rpm package - add missed quites and remove extra spaces Online as always at http://kegel.com/wine/winetricks or http://winezeug.googlecode.com Guessing windir is a bad thing. You should use this instead: WINDIR=$(wine winepath -u $(wine cmd /c echo %windir%)) Same applies to other system directories like Program Files. Vitaliy. Dan, I in no way mean to second guess your work but I checked out the diff for the most recent commit for how winetricks handled FF3. It seems all it does is download it and install it, no tricks. Do we want winetricks to become a generic application installer? I thoughts its main purpose was to perform some non-obvious tricks to get difficult things to install. --Zach
Re: New winetricks 20080704: added firefox3, kde verbs (and a whole lot of other stuff)
On Sun, Jul 6, 2008 at 11:47 PM, Zachary Goldberg [EMAIL PROTECTED] wrote: I in no way mean to second guess your work but I checked out the diff for the most recent commit for how winetricks handled FF3. It seems all it does is download it and install it, no tricks. Do we want winetricks to become a generic application installer? I thoughts its main purpose was to perform some non-obvious tricks to get difficult things to install. I suggested it to Dan and added it because winetricks is supposed to be a developers tool and I needed it for a development project. Just going to getfirefox.com on linux auto detects your platform and of course I did not want Linux but the windows builds. I thought it might be a of use if others need win32 firefox for testing, development, etc. -- Steven Edwards There is one thing stronger than all the armies in the world, and that is an idea whose time has come. - Victor Hugo
Re: New winetricks 20080704: added firefox3, kde verbs (and a whole lot of other stuff)
On Mon, Jul 7, 2008 at 12:00 AM, Steven Edwards [EMAIL PROTECTED] wrote: On Sun, Jul 6, 2008 at 11:47 PM, Zachary Goldberg [EMAIL PROTECTED] wrote: I in no way mean to second guess your work but I checked out the diff for the most recent commit for how winetricks handled FF3. It seems all it does is download it and install it, no tricks. Do we want winetricks to become a generic application installer? I thoughts its main purpose was to perform some non-obvious tricks to get difficult things to install. I suggested it to Dan and added it because winetricks is supposed to be a developers tool and I needed it for a development project. Just going to getfirefox.com on linux auto detects your platform and of course I did not want Linux but the windows builds. I thought it might be a of use if others need win32 firefox for testing, development, etc. -- Steven Edwards There is one thing stronger than all the armies in the world, and that is an idea whose time has come. - Victor Hugo Aha! I guess in this case simply downloading FF3 for windows is actually a trick. -Zach
Re: New winetricks 20080704: added firefox3, kde verbs (and a whole lot of other stuff)
On Sun, Jul 6, 2008 at 8:47 PM, Zachary Goldberg [EMAIL PROTECTED] wrote: I in no way mean to second guess your work but I checked out the diff for the most recent commit for how winetricks handled FF3. It seems all it does is download it and install it, no tricks. Do we want winetricks to become a generic application installer? I thoughts its main purpose was to perform some non-obvious tricks to get difficult things to install. I put things in there that I find myself installing often for testing purposes. Firefox is one of those things. Steven Edwards sent me a patch about the time I was thinking of adding it, so in it went. I do have two other scripts for applications. First, http://kegel.com/wine/migrating-user-1.html links to http://kegel.com/wine/migrating-user-1.sh which can install 14 random apps user #1 wanted. Second, http://code.google.com/p/winezeug/source/browse/trunk/codecdemo is a little script that installs a media player and some codecs (mostly using winetricks), and a bunch of demo videos. Those aren't ever going into winetricks. I only mention this to show that I do have *some* sense of taste. - Dan
Odd valgrind error in imm.c, possible fix
Today a test got stuck, and I had to kill wineserver.
After that, lots of tests seem to have the same
error:
+ Invalid read of size 4
+at IMM_FreeThreadData (imm.c:233)
+by DllMain (imm.c:385)
+by __wine_spec_dll_entry (dll_entry.c:40)
+by (within /home/dank/wine-git/dlls/ntdll/ntdll.dll.so)
+by MODULE_InitDLL (loader.c:910)
+by process_detach (loader.c:1081)
+by LdrShutdownProcess (loader.c:2143)
+by ExitProcess (process.c:2101)
+by service_run_main_thread (service.c:604)
+by StartServiceCtrlDispatcherW (service.c:703)
+by wmain (device.c:287)
+ Address 0x0 is not stack'd, malloc'd or (recently) free'd
Presumably this is because killing wineserver also killed
the background notepad I run to keep from having
to valgrind wineboot etc. over and over again.
If the immediate cause is something like
imm32's DllMain getting called with DLL_PROCESS_DETACH
after being called with DLL_THREAD_DETACH, the following
patch might be a sensible fix. Is it?
diff --git a/dlls/imm32/imm.c b/dlls/imm32/imm.c
index 94b7752..bcd11f1 100644
--- a/dlls/imm32/imm.c
+++ b/dlls/imm32/imm.c
@@ -230,10 +230,13 @@ static void IMM_InitThreadData(void)
static void IMM_FreeThreadData(void)
{
IMMThreadData* data = TlsGetValue(tlsIndex);
-IMM_DestroyContext(data-defaultContext);
-DestroyWindow(data-hwndDefault);
-HeapFree(GetProcessHeap(),0,data);
-TRACE(Thread Data Destroyed\n);
+if (data)
+{
+IMM_DestroyContext(data-defaultContext);
+DestroyWindow(data-hwndDefault);
+HeapFree(GetProcessHeap(),0,data);
+TRACE(Thread Data Destroyed\n);
+}
}
static HMODULE LoadDefaultWineIME(void)
Re: mlang/tests: don't assume output of ConvertStringFromUnicode is null terminated
On Sun, Jul 6, 2008 at 10:29 AM, James Hawkins [EMAIL PROTECTED] wrote: No, this is hiding a bug. The test code conforms with the API. The problem is that ConvertINetMultiByteToUnicode uses the value of an out-only parameter (NULL pDstStr, non-NULL pcDstSize). Check out the code block in mlang.c:632. Yeah, that's what I figured you thought, but your fix doesn't actually get rid of the error message, and the error is happening on *pcSrcSize = lstrlenA(pSrcStr); in ConvertINetMultiByteToUnicode. The conformance test shows on line 197 that IMultiLanguage2_ConvertStringFromUnicode doesn't null-terminate its output. So it's wrong for check_convertible to rely on it to do so. Am I missing something? I still believe in my patch... - Dan
