Re: winex11.drv keyboard driver rewrite
I have a snapshot (although don't attach it here because of its large size) that shows a text typed in Word (MS Office 2000) sequentially in German, French, Polish, Belarusian, Ukrainian and Russian (locale is KOI8-U and supports only English, Russian and Ukrainian letters). I can say even more. Even if user have broken locale or/and broken input he can write non-English letters anyway. I think this is big improvement because there many users (at least in Russia) who have such troubles with Wine. For example user can have correct locale settings (LANG, LANGUAGE and LC_* all equals to ru_RU for example) and perfectly working locale-enabled programs like cal, nano or date but Wine sometimes cannot work correctly: it display Russian letters perfectly, notepad and others has Russian GUI but input of Russian letters doesn't work because of famous err:keyboard:X11DRV_ToUnicodeEx Please report: no char for keysym error (sometimes this is becaue user forgot to launch locale-gen but sometimes this is because of broken libc - in such case there is no simple solution, only recompiling). With this patch Wine works out-of-the-box anyway - that also means better integration with X. I found other small improvements as well (within source code). ...And of course + all major improvements listed by Oleh himself. My opinion: this patch gives better integration with X+XKB environment and probably can be useful for many users. So I think it worth trying...
Re: d3d8 2: Test refcount forwarding.
On 14/11/06, Markus Amsler [EMAIL PROTECTED] wrote: +extern int get_refcount(IUnknown *object); --- -static int get_refcount(IUnknown *object) +int get_refcount(IUnknown *object) We don't really want to do that. The idea is that a test should depend only on the .c file it's defined in. That's also why eg. the code to initialise a D3D device is duplicated everywhere.
Re: d3d8 2: Test refcount forwarding.
H. Verbeet wrote: On 14/11/06, Markus Amsler [EMAIL PROTECTED] wrote: +extern int get_refcount(IUnknown *object); --- -static int get_refcount(IUnknown *object) +int get_refcount(IUnknown *object) We don't really want to do that. The idea is that a test should depend only on the .c file it's defined in. That's also why eg. the code to initialise a D3D device is duplicated everywhere. Ok. In the following test headers are extern functions: dlls/dinput/tests/dinput_test.h dlls/dsound/tests/dsound_test.h dlls/winmm/tests/winmm_test.h so i thought it's fine. Should we remove them?
Re: winex11.drv keyboard driver rewrite
Here is full patch applied against current Wine' git-snapshot. I sending it because patch from Oleh original message isn't working out-of-the-box. winex11.drv-keyboard-rewrite.diff.bz2 Description: BZip2 compressed data
Re: RFC: d3d8 refcount implementation
On 14/11/06, Markus Amsler [EMAIL PROTECTED] wrote: After spamming wine-patches with d3d tests, I tried to implement the probed behaviour. Attached are two patches, which makes all d3d8 refcount test pass. They are small and ugly. The problems are: The implicit surfaces now gets released if the refcount is -1. Somehow we have to force releasing d3d8 sufaces from wined3d. No idea how. You could probably either force the refcount to 0 (ie, something like while(IWineD3DSurface_Release(surface));), or add an explicit destructor to the d3d8 implementation. That's not too pretty either, but I suppose it's better than releasing on -1. I added a flag to mark the implicit surfaces. It's redundant, because wined3d knows the implicit surfaces. The other idea is calling GetRenderTarget and friends in Surface_(AddRef/Release). Besides the problem of an endless recursion, it would be quite an overhead. Shouldn't we just check if the surface's container is the same as the surface's device? Totally unrelated to this, are you ever on IRC?
Re: d3d8 2: Test refcount forwarding.
On 14/11/06, Markus Amsler [EMAIL PROTECTED] wrote: so i thought it's fine. Should we remove them? Possibly.
Re: RFC: d3d8 refcount implementation
H. Verbeet wrote: On 14/11/06, Markus Amsler [EMAIL PROTECTED] wrote: The implicit surfaces now gets released if the refcount is -1. Somehow we have to force releasing d3d8 sufaces from wined3d. No idea how. You could probably either force the refcount to 0 (ie, something like while(IWineD3DSurface_Release(surface));), I'm not sure what you mean. IWineD3DSurface_Release won't release the d3d8 surface. Besides, the surface shouldn't be released with refcount==0, only on device destruction. or add an explicit destructor to the d3d8 implementation. That's not too pretty either, but I suppose it's better than releasing on -1. This would mean a wine specific d3d8 interface extension. I'm not sure whether that's acceptable. Perhaps we could misuse an existing function (e.g QueryInterface with a magic refiid, to destroy the surface, or set/get maigc private data). Or handle implicit surface destruction in IDirect3DDevice8_Release and not in IWineD3DDevice_Uninit3D. There we could use our private d3d8 destruct function. Looks for me like the way to go. I added a flag to mark the implicit surfaces. It's redundant, because wined3d knows the implicit surfaces. The other idea is calling GetRenderTarget and friends in Surface_(AddRef/Release). Besides the problem of an endless recursion, it would be quite an overhead. Shouldn't we just check if the surface's container is the same as the surface's device? For d3d8 this would be a nice solution. But in d3d9 the implicit RenderTarget's container is the swapchain. I think we should handle d3d8 and d3d9 the same way. Totally unrelated to this, are you ever on IRC? Not yet, but I could. Is it easier to discuss such stuff on IRC?
Re: RFC: d3d8 refcount implementation
On 14/11/06, Markus Amsler [EMAIL PROTECTED] wrote: H. Verbeet wrote: On 14/11/06, Markus Amsler [EMAIL PROTECTED] wrote: The implicit surfaces now gets released if the refcount is -1. Somehow we have to force releasing d3d8 sufaces from wined3d. No idea how. You could probably either force the refcount to 0 (ie, something like while(IWineD3DSurface_Release(surface));), I'm not sure what you mean. IWineD3DSurface_Release won't release the d3d8 surface. Besides, the surface shouldn't be released with refcount==0, only on device destruction. Nevermind, you're right, d3d8 releases wined3d, not the other way around. You can get to the wined3d surface's parent (ie, the d3d8 surface) from inside wined3d though. or add an explicit destructor to the d3d8 implementation. That's not too pretty either, but I suppose it's better than releasing on -1. This would mean a wine specific d3d8 interface extension. I'm not sure whether that's acceptable. Well, it wouldn't get added to the public interface, but you could eg. pass it to the wined3d surface constructor. Perhaps we could misuse an existing function (e.g QueryInterface with a magic refiid, to destroy the surface, or set/get maigc private data). That would probably be worse. Or handle implicit surface destruction in IDirect3DDevice8_Release and not in IWineD3DDevice_Uninit3D. There we could use our private d3d8 destruct function. Looks for me like the way to go. That's probably the cleanest option. I added a flag to mark the implicit surfaces. It's redundant, because wined3d knows the implicit surfaces. The other idea is calling GetRenderTarget and friends in Surface_(AddRef/Release). Besides the problem of an endless recursion, it would be quite an overhead. Shouldn't we just check if the surface's container is the same as the surface's device? For d3d8 this would be a nice solution. But in d3d9 the implicit RenderTarget's container is the swapchain. I think we should handle d3d8 and d3d9 the same way. Isn't it always the swapchain in wined3d? Anyway, that's not going to work then. Totally unrelated to this, are you ever on IRC? Not yet, but I could. Is it easier to discuss such stuff on IRC? Sometimes. Most people doing d3d stuff are on there.
Re: Wine 0.9.25 full of regressions!
Ok, i found patch which caused regression in 3DMark 2003, Flatout and some other games and apps, it is this patch: kernel32: Better workaround for the lack of locale environment variables on MacOS from Alexandre Julliard Mirek Jesse Allen napsal(a): On 11/13/06, Mirek [EMAIL PROTECTED] wrote: Yes and no, some issues was because of drivers, but some wasnt, now i have old working drivers back and there are still about 35% apps that are working significant worst in wine 0.9.25, so it is not only problem of new drivers. Mirek Please report your bugs through the proper methods. You can't just dump a list of problems, provide little information, and expect all to be addresssed at the same time and effort. I'm not going to address your bugs here and I don't recognize all of them.
Re: Wine 0.9.25 full of regressions!
Mirek [EMAIL PROTECTED] wrote: Ok, i found patch which caused regression in 3DMark 2003, Flatout and some other games and apps, it is this patch: kernel32: Better workaround for the lack of locale environment variables on MacOS from Alexandre Julliard It's already fixed in the current git. -- Dmitry.
Re: Wine 0.9.25 full of regressions!
Hi, My regression test shows same as you. Dreamfall is broken because of this patch. 2006. november 14. 16.07 dátummal Mirek ezt írta: :) No, in current git or cvs it is still not fixed, i tried it again before 10 minutes. Mirek Dmitry Timoshkov napsal(a): Mirek [EMAIL PROTECTED] wrote: Ok, i found patch which caused regression in 3DMark 2003, Flatout and some other games and apps, it is this patch: kernel32: Better workaround for the lack of locale environment variables on MacOS from Alexandre Julliard It's already fixed in the current git. -- -- andras NetClub Lamarr csevego.net [EMAIL PROTECTED] --
Re: Wine 0.9.25 full of regressions!
:) No, in current git or cvs it is still not fixed, i tried it again before 10 minutes. Mirek Dmitry Timoshkov napsal(a): Mirek [EMAIL PROTECTED] wrote: Ok, i found patch which caused regression in 3DMark 2003, Flatout and some other games and apps, it is this patch: kernel32: Better workaround for the lack of locale environment variables on MacOS from Alexandre Julliard It's already fixed in the current git.
OLE Automatization Linux's OpenOffice from wine app
I have windows application wich use OLE Automatization to fill-in
OpenOffice document It's create OleObject like
OpenOffice := CreateOleObject('com.sun.star.ServiceManager');
And then use it.
Everything is OK when I run it on windows.
How can I rewrite it, or use any tools, to work when OpenOffice is
installed on Linux, and my application runs in wine?
--
Kochmin Alexandr
re: OLE Automatization Linux's OpenOffice from wine app
Kochmin wrote:
I have windows application wich use OLE Automatization to fill-in
OpenOffice document It's create OleObject like
OpenOffice := CreateOleObject('com.sun.star.ServiceManager');
..
How can I rewrite it, or use any tools, to work when OpenOffice is
installed on Linux, and my application runs in wine?
Try installing the Windows version of OpenOffice in Wine.
- Dan
Over 500 maintainers in the applcation database
_I_ think this is news worthy. We now have over 500 individuals who have signed up to be maintainer of an applications. these maintainers are spread out over 794 entries in the AppDB. Since there are some applications with multiple maintainers and some maintainers maintain multiple apps and the fact that super maintainers are responsible for multiple versions I cannot give a accurate count on maintained applications ;^) There has not been a lot of hacking on the AppDB for a while. At least part of the reason for this is that there is a lot of work to be done just administrating it. even with all the maintainers and administrators it seems we are always a couple of days behind checking new application submissions and test results. Current active Administrators are : Chris Morgan (In charge of cvs commits) Tony Lambregts (me) Louis Lenders Alexander Nicolaysen Sørnes Killertux Molle Bestefich Jan Zerebecki Nick Law We can always use more help and even though I am kind of proud of the current status of the AppDB I have to be one of the first to admit it needs some more polish. If you know php and would like to help out you can download the source http://www.winehq.org/site/cvs There are lots of features that would enhance the AppDB please have a look at the wiki and feel free to add other stuff that you think would be good to have. http://wiki.winehq.org/AppdbInfo You can also help out by becoming an application maintainer as well or if you are a sucker for punishment then perhaps you might consider becoming a Administrator for the AppDB. -- Tony Lambregts
Re: localspl: Implement ConfigurePortW
Hi Detlef, +IDS_NOTHINGTOCONFIG This Port has no Options to configure This should be This port has no options to configure. In English, nouns are generally not capitalized - only proper nouns. Google will give many pages helping with that if you like. Thanks, --Juan Cheap talk? Check out Yahoo! Messenger's low PC-to-Phone call rates. http://voice.yahoo.com
Debugging solidworks 2006
I am currently trying Solid Works 2006 to work with wine-0.9.25. It
installed with some error, but it finished. The trouble is when it is
run. What is my next step? As this is the first time I am doing
debugging in wine and I have little experience with windows programming.
I am doing this so I can get solidworks working as I really need it. Any
help will be very much appreciated.
fixme:msvcrt:MSVCRT__wsetlocale 4 LEnglish_United States.1252
fixme:msvcrt:MSVCRT__wsetlocale 4 LC
fixme:msvcrt:MSVCRT__wsetlocale 4 LEnglish_United States.1252
fixme:msvcrt:MSVCRT__wsetlocale 4 LC
fixme:msvcrt:MSVCRT__wsetlocale 4 LEnglish_United States.1252
fixme:msvcrt:MSVCRT__wsetlocale 4 LC
fixme:msvcrt:MSVCRT__wsetlocale 4 LEnglish_United States.1252
fixme:msvcrt:MSVCRT__wsetlocale 4 LC
fixme:msvcrt:MSVCRT__wsetlocale 4 LEnglish_United States.1252
fixme:msvcrt:MSVCRT__wsetlocale 4 LC
fixme:msvcrt:MSVCRT__wsetlocale 4 LEnglish_United States.1252
err:wgl:ConvertPixelFormatWGLtoGLX Can't find a matching FBCONFIG_ID for
VISUAL_ID 0x24!
err:wgl:X11DRV_ChoosePixelFormat Can't find a matching FBCONFIG_ID for
VISUAL_ID 0x24!
fixme:toolbar:TOOLBAR_Restore send TBN_GETBUTTONINFO for each button
fixme:toolbar:TOOLBAR_Restore send TBN_GETBUTTONINFO for each button
fixme:toolbar:TOOLBAR_Restore send TBN_GETBUTTONINFO for each button
fixme:toolbar:TOOLBAR_Restore send TBN_GETBUTTONINFO for each button
fixme:toolbar:TOOLBAR_Restore send TBN_GETBUTTONINFO for each button
fixme:toolbar:TOOLBAR_Restore send TBN_GETBUTTONINFO for each button
fixme:toolbar:TOOLBAR_Restore send TBN_GETBUTTONINFO for each button
fixme:toolbar:TOOLBAR_Restore send TBN_GETBUTTONINFO for each button
fixme:toolbar:TOOLBAR_Restore send TBN_GETBUTTONINFO for each button
fixme:toolbar:TOOLBAR_Restore send TBN_GETBUTTONINFO for each button
fixme:toolbar:TOOLBAR_Restore send TBN_GETBUTTONINFO for each button
fixme:toolbar:TOOLBAR_Restore send TBN_GETBUTTONINFO for each button
fixme:toolbar:TOOLBAR_Restore send TBN_GETBUTTONINFO for each button
fixme:toolbar:TOOLBAR_Restore send TBN_GETBUTTONINFO for each button
fixme:toolbar:TOOLBAR_Restore send TBN_GETBUTTONINFO for each button
fixme:toolbar:TOOLBAR_Restore send TBN_GETBUTTONINFO for each button
fixme:toolbar:TOOLBAR_Restore send TBN_GETBUTTONINFO for each button
fixme:toolbar:TOOLBAR_Restore send TBN_GETBUTTONINFO for each button
fixme:toolbar:TOOLBAR_Restore send TBN_GETBUTTONINFO for each button
fixme:toolbar:TOOLBAR_Restore send TBN_GETBUTTONINFO for each button
fixme:toolbar:TOOLBAR_Restore send TBN_GETBUTTONINFO for each button
fixme:toolbar:TOOLBAR_Restore send TBN_GETBUTTONINFO for each button
fixme:toolbar:TOOLBAR_Restore send TBN_GETBUTTONINFO for each button
fixme:toolbar:TOOLBAR_Restore send TBN_GETBUTTONINFO for each button
fixme:toolbar:TOOLBAR_Restore send TBN_GETBUTTONINFO for each button
fixme:toolbar:TOOLBAR_Restore send TBN_GETBUTTONINFO for each button
fixme:toolbar:TOOLBAR_Restore send TBN_GETBUTTONINFO for each button
fixme:toolbar:TOOLBAR_Restore send TBN_GETBUTTONINFO for each button
fixme:toolbar:TOOLBAR_Restore send TBN_GETBUTTONINFO for each button
fixme:toolbar:TOOLBAR_Restore send TBN_GETBUTTONINFO for each button
fixme:toolbar:TOOLBAR_Restore send TBN_GETBUTTONINFO for each button
fixme:shdocvw:PersistStreamInit_InitNew (0x335d3f0)
err:shdocvw:get_typeinfo LoadRegTypeLib failed: 8002801d
err:shdocvw:get_typeinfo LoadRegTypeLib failed: 8002801d
err:shdocvw:get_typeinfo LoadRegTypeLib failed: 8002801d
err:shdocvw:get_typeinfo LoadRegTypeLib failed: 8002801d
err:shdocvw:get_typeinfo LoadRegTypeLib failed: 8002801d
err:shdocvw:get_typeinfo LoadRegTypeLib failed: 8002801d
fixme:shdocvw:navigate_url Unsupported arguments
err:ole:CoGetClassObject class {4955dd33-b159-11d0-8fcf-00aa006bcc59} not
registered
err:ole:CoGetClassObject no class object {4955dd33-b159-11d0-8fcf-00aa006bcc59}
could be created for context 0x1
fixme:shdocvw:ClOleCommandTarget_QueryStatus (0x335d48c)-((null) 1 0x33e520
(nil))
fixme:shdocvw:ClOleCommandTarget_Exec (0x335d48c)-((null) 25 2 0x33e534 (nil))
fixme:shdocvw:ClOleCommandTarget_Exec (0x335d48c)-((null) 26 2 0x33e534 (nil))
fixme:shdocvw:ClDispatch_Invoke (0x335d48c)-(-709
{----} 2048 0002 0x33e488 0x33e4d4 (nil)
0x33e498)
fixme:shdocvw:ClDispatch_Invoke (0x335d48c)-(-5512
{----} 2048 0002 0x33e448 0x33e494 (nil)
0x33e458)
fixme:shdocvw:ClDispatch_Invoke (0x335d48c)-(-5501
{----} 2048 0002 0x33e488 0x33e4d4 (nil)
0x33e498)
fixme:shdocvw:ClDispatch_Invoke (0x335d48c)-(-5512
{----} 2048 0002 0x33e448 0x33e494 (nil)
0x33e458)
fixme:shdocvw:ClDispatch_Invoke (0x335d48c)-(-5502
{----} 2048 0002 0x33e488 0x33e4d4 (nil)
0x33e498)
fixme:shdocvw:ClDispatch_Invoke (0x335d48c)-(-5513
{----} 2048 0002 0x33e488 0x33e4d4 (nil)
0x33e498)
fixme:shdocvw:ClDispatch_Invoke
Re: Wine 0.9.25 full of regressions!
Le mardi 14 novembre 2006 à 16:07 +0100, Mirek a écrit : :) No, in current git or cvs it is still not fixed, i tried it again before 10 minutes. Mirek Dmitry Timoshkov napsal(a): Mirek [EMAIL PROTECTED] wrote: Ok, i found patch which caused regression in 3DMark 2003, Flatout and some other games and apps, it is this patch: kernel32: Better workaround for the lack of locale environment variables on MacOS from Alexandre Julliard It's already fixed in the current git. Again, please open a bug about this regression. wine-devel is not bugzilla. And _please_ stop top-posting (at least on bottom-posted threads), it makes it really hard and uncomfortable to read. Thanks,
