Re: ADVAPI32: service tests
On 5/18/07, Rolf Kalbermatter [EMAIL PROTECTED] wrote: While working on some advapi32.service functions I found that having some tests for those APIs could be very useful. However nbot having added completely new tests so far there are a few issues I feel intimidated about. The actual task of adding a new test file service.c does seem fairly straightforward to me, considering I can just take some other test file and copy the framework from it, adding the new service.c to the Makefile.in. However there are a few issues I see. First almost any test won't make much sense without at least one service installed and activated. As it is now there seem to be no services installed by default in a clean Wine install. Have you looked? regedit HKLM\System\CurrentControlSet\Services. I'm not familiar with spooler, but I assume it's installed by default on win9x, whereas msi is not. Whichever service you test, though, you can just skip if the service doesn't exist. So I guess I would also need an extra executable somehow that implements a basic service that could for instance communicate through a pipe with the service test. It could be as simple as an executable that implements all the necessary communication with the service manager and offers some sort of pipe loopback as main service activity. But how am I going to add such an extra executable to the make logic of the advapi32 test? You won't need any of this. Also under real Windows installing a service will in many cases fail since that requires administrative privileges for the current process and I'm not sure we can and want to enforce something like that especially for the unattended wine test service if that is still working. Just check the return value of OpenSCManager; skip the test if they aren't admin. msdn implies that OpenSCManager will return ERROR_ACCESS_DENIED if they don't have the correct privileges. It's a trivial issue that most tests currently don't bother with. -- James Hawkins
Success: Sim City 4 using DirectX
Hello, just wanted to let you know that with Wine 0.9.37, Sim City 4 is running successfully in DirectX mode for the first time in the 3 years I've been playing it under Wine. Previously, to be able to play at all, one had to force the game to use OpenGL calls. The visual artifacts triggered by scrolling the map under that mode are now gone under DirectX as well. So all in all great work :) The only issue remaining seems to be related to the Z-buffer. Cars and pedestrians are always drawn on top of buildings. See http://bugs.winehq.org/show_bug.cgi?id=7260#c3 Regards, -- Markus
Re: gdi32: check for null-pointer in CreateDIBSection
Hi, I am not sure at all there a link between what I say and a hiding bug somewhere around this patch, but bug 8088 is due to a problem around DIB section and bitmapinfo too. Maybe a cross analysis between those two bugs could help find this hiding bug. I hope this can help, Laurent Jesse Allen a écrit : On 5/19/07, Louis. Lenders [EMAIL PROTECTED] wrote: Hi , this fixes bug 8066, http://bugs.winehq.org/show_bug.cgi?id=8066 See the crash log here: http://bugs.winehq.org/attachment.cgi?id=5800action=view , CreateDIBSection is called with bitmapinfo = null. The program should be passing in a correctly initialized BITMAPINFO. We need to make sure this isn't hiding another bug. Could you provide a test case?
RE: ADVAPI32: service tests
James Hawkins [mailto:[EMAIL PROTECTED] wrote Have you looked? regedit HKLM\System\CurrentControlSet\Services. I'm not familiar with spooler, but I assume it's installed by default on win9x, whereas msi is not. Whichever service you test, though, you can just skip if the service doesn't exist. Well I have checked and on a clean Wine install from current git there is no service installed at all. I see a VxD/MSTCP entry in the registry but no other settings in there that would be needed for a service to be started nor any other service entry. On that account I wonder what the VxD/MSTCP entry does at all or if it could be removed? You won't need any of this. Without at least one working service entry (active or not) there won't be many meaningful tests we could do for the service API. Just check the return value of OpenSCManager; skip the test if they aren't admin. msdn implies that OpenSCManager will return ERROR_ACCESS_DENIED if they don't have the correct privileges. It's a trivial issue that most tests currently don't bother with. I thought skip would be the solution but need to read on that. Last time I did a Wine test skip didn't exist at all. Still on a clean Wine install I don't see how we can currently do many useful service API tests at all. Rolf Kalbermatter
Re: msxml3 [1/4]: Add initial implementations of IXMLElement and IXMLElementCollection
On 5/18/07, Huw Davies [EMAIL PROTECTED] wrote: On Thu, May 17, 2007 at 04:40:06PM -0500, James Hawkins wrote: Changelog: * Add initial implementations of IXMLElement and IXMLElementCollection. I can't help thinking that it would have been cleaner to implement the IXML stuff using the IXMLDOM interfaces rather than straight on top of libxml. That way we only get one set of interfaces that depend on libxml. It may not be possible, but I think it would be worth a look. I've taken a look, and I don't think it's possible. Here is a 1-to-1 matching of methods in IXMLDocument and IXMLDOMDocument, respectively: xmldoc_get_root = domdoc_documentElement xmldoc_get_fileSize xmldoc_put_fileModifiedDate xmldoc_get_fileUpdatedDate xmldoc_get_URL = domdoc_get_url xmldoc_put_URL = domdoc_load xmldoc_get_mimeType xmldoc_get_readyState = domdoc_get_readyState xmldoc_get_charset xmldoc_put_charset xmldoc_get_version xmldoc_get_doctype = domdoc_get_doctype xmldoc_get_dtdURl xmldoc_createElement = domdoc_createElement The rows with empty second columns have no matching IXMLDOMDocument method, and more precisely, can't be implemented without access to xmlDoc/NodePtr. The file* methods aren't as simple as that, but either way, they don't involve libxml2. Another problem is the discrepancies between the interface implementations. For example, IXMLDocument::get_tagName returns the name of the tag in all upper-case, while IXMLDOMDocument's equivalent method preserves the case of the tag name. The Media Player 9 requires this behavior. I understand your concerns about limiting use of libxml2, but I think that the limitation can only apply to the respective groups of interfaces, e.g., XMLDocument and co. vs. XMLDOMDocument and co. The latest version of each interface implements the interface using libxml2, and each earlier version is implemented on top of the latest version. -- James Hawkins
Re: ADVAPI32: service tests
On 5/20/07, Rolf Kalbermatter [EMAIL PROTECTED] wrote: James Hawkins [mailto:[EMAIL PROTECTED] wrote Have you looked? regedit HKLM\System\CurrentControlSet\Services. I'm not familiar with spooler, but I assume it's installed by default on win9x, whereas msi is not. Whichever service you test, though, you can just skip if the service doesn't exist. Well I have checked and on a clean Wine install from current git there is no service installed at all. I see a VxD/MSTCP entry in the registry but no other settings in there that would be needed for a service to be started nor any other service entry. On that account I wonder what the VxD/MSTCP entry does at all or if it could be removed? Then something is wrong with your setup. Both MSIServer and Spooler are registered services when you run wineprefixcreate. You won't need any of this. Without at least one working service entry (active or not) there won't be many meaningful tests we could do for the service API. Read above. Just check the return value of OpenSCManager; skip the test if they aren't admin. msdn implies that OpenSCManager will return ERROR_ACCESS_DENIED if they don't have the correct privileges. It's a trivial issue that most tests currently don't bother with. I thought skip would be the solution but need to read on that. Last time I did a Wine test skip didn't exist at all. Still on a clean Wine install I don't see how we can currently do many useful service API tests at all. On a clean install, there are two services to test. You need to figure out why you don't have those services. This is from a clean .wine: REGEDIT4 [HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services] [HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\MSIServer] DisplayName=MSIServer ErrorControl=dword:0001 ImagePath=c:\\windows\\system32\\msiexec.exe Start=dword:0003 Type=dword:0020 [HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\Spooler] Description=Loads files to memory for later printing. DisplayName=Print Spooler ErrorControl=dword:0001 Group=SpoolerGroup ImagePath=spoolsv.exe ObjectName=LocalSystem Start=dword:0002 Type=dword:0110 [HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\VxD] [HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\VxD\MSTCP] @= -- James Hawkins
Re: Wine keyboard driver+XKB. What am I to do?
Oleh R. Nykyforchyn wrote: Hello, I need an advice on what to do with some piece of code that I have written for about 3 years. I started to make changes in Wine keyboard driver because I was not able to use MS Office under it on my Linux box (3 or 4 XKB groups, 2 overlay groups used, English, Russian, Ukrainian, Belarusian, German and Polish layouts). First I submitted a patch that adds koi8-u encoding to Wine, and it was happily introduced. But my changes to X11DRV (now winex11) keyboard driver were large and I understand Wine people who didn't want to risk. Meanwhile I continued to polish my implementation to correct bugs and improve performance. I am heavily indebted to people that tested my patches, wrote me about problems with them and suggested possible solutions. I thank to L.Rahyen that supported me in my efforts. Now patched keyboard driver allows user to: 1) have up to 4 XKB groups working (current code uses 1 or 2); 2) detect and use XKB overlays to put 2 or 3 close layouts (e.g. Russian, Ukrainian and Belarusian) into one XKB group; 3) freely combine available XKB layouts in any order, e.g. en,ru,fr; 4) list all layouts available at the system, and implement ActivateKeyboardLayout(); 5) notify an application (e.g. MS Word) about change of layout, and make GetKeyboardLayout() work really, not just return LCID for current locale of Unix box; 6) input characters that do not fit into current Unix locale, e.g. German and French accented letters at a system with Cyrillic (not UTF) locale; 7) override any of detected layouts via registry, if user is not satisfied with Wine driver choice. In fact I made cosmetic changes to 3 files in winex11.drv directory: x11drv.h, x11drv_main.c, event.c, but the fourth file keyboard.c was changed much more. About half of functions in it were rewritten, and it now easier to read new keyboard.c than diff output to understand the changes. I got very reasonable advice from L.Rahyen to broke the patch into smaller parts. The problem is that I preserved the driver logic, but changed data structures, so any such patch (even very small one) will touch hundreds if lines across the whole file, probably introducing new bugs and being difficult to read and understand. Also, there is no reason to change code by a patch if we can benefit of it only after next patch. Now I will be grateful to any help. How can such big changes be introduced in Wine tree? I also attach a patch against wine-0.9.37 and copies of original and changed files. Perhaps somebody, who is interested in multilingual keyboard input, can test it and write me about results. Oleh Also, have a look at http://bugs.winehq.org/show_bug.cgi?id=735, which is an independent attempt to solve the same problem. It's a pity I didn't know about your effort. Shachar
winetest.dll (RE: ADVAPI32: service tests)
On So, 2007-05-20 at 11:23 +0200, Rolf Kalbermatter wrote: Well I have checked and on a clean Wine install from current git there is no service installed at all. We have the Spooler-Service (only as a stub, but startable), so the entries should be present in the Registry. Without at least one working service entry (active or not) there won't be many meaningful tests we could do for the service API. You can take dlls/winspool.drv/tests/info.c as example, what I did for the Monitor-Tests. (Lines starting at 155; 283; 326) Still on a clean Wine install I don't see how we can currently do many useful service API tests at all. Because we have no need for a Service in Wine yet I mentioned already the idea for a winetest.dll / winetest.drv to allow tests, that need a dll next to winetest.exe (Global Hook, Printmonitor, Printer Driver, ). A Service need also a DLL and the with the new ntoskrnl.exe, a Driver winetest.sys might be useful. It's also possible to add the new Files as a Resource in winetest.exe, to have only a single file to download / start. An Item to discuss is an Option in winetest.exe to Disable the Kernelmode-Testdriver. -- By by ... Detlef
user32: Exclude unused headers
Apologies for the duplicates: the originals were slow to arrive, so I presumed they got lost and sent them again. -- Andy.
Re: [localui} New Korean Resource
On So, 2007-05-20 at 19:54 +0900, Hwang YunSong(황윤성) wrote:
+LANGUAGE LANG_KOREAN, SUBLANG_DEFAULT
+
+STRINGTABLE DISCARDABLE
+{
+IDS_LOCALPORT Ʈ
+IDS_NOTHINGTOCONFIG Ʈ ɼ ϴ
+}
localui.dll has much more resources now.
Please update your Translation-Patch.
Thanks
--
By by ... Detlef
Re: Small Direct3D milestone
On 19.05.2007 21:55, Stefan Dösinger wrote: Did you change something affecting D3D multithreaded apps? I am currently working on this. Some fundamental work went into wine somewhen between .33 and .35, but its not active yet. It was just some data structure modifications to handle multiple contexts for one swapchain. Before that the state management rework enabled us to keep track of states for multiple contexts. But right now I am working on making things really thread safe, and after that I can debug some gl crashes with the context selection patches I posted on this list a few months ago so they can go in finally. Cool. Star Trek: Bridge Commander doesn't start for me (only blank screen) since 0.9.37. http://appdb.winehq.org/appview.php?iVersionId=4207 (AppDB) http://www.bridgecommander.com/indepth/bcdemo.htm (downloadable demo) I'm using the opensource r300 ATI drivers if that matters. No idea about that. If it worked before a regression test will help Will do a regression test and report back. Regards, Carl-Daniel
msi ole automation: where to next?
Hi everybody, Hope you are all having a nice Sunday. Since MSI OLE automation is a bit overwhelming, I have been using installers that have JScript/VBScript actions to guide me as to what specific functions/objects to implement next. I started out by implementing all the functions used by the Vector NTI installer (which is how I got into wine programming at all; and which was actually dependent on one of these actions for installing at the time), and for the past few weeks I have been following the functions required by the iTunes 7 installer. However, now that I have implemented all the functions used by both of these (yay), I am having trouble finding another installer that uses a lot of scripting, so I was wondering if anyone had any suggestions? It really helps to have something like that to guide/motivate me. (I googled UNHANDLED ACTION TYPE and tried the installers I found but all the installers I actually tried out didn't seem to use scripting or maybe just unimplmeneted scripting functions anymore). Alternately, is there any other use for MSI OLE automation besides installers with scriptable actions? If so, what functions would be important for that use? (I know Mike McCormack talked at one point about using these interfaces to run custom actions in a separate process, but I am not really clear as to why automation is really necessary for this and, if so, how exactly it would be used, since all the automation functions are just wrappers around existing functions anyway.) Thanks a lot Misha
Re: msi ole automation: where to next?
On 5/20/07, Misha Koshelev [EMAIL PROTECTED] wrote: Hi everybody, Hope you are all having a nice Sunday. Since MSI OLE automation is a bit overwhelming, I have been using installers that have JScript/VBScript actions to guide me as to what specific functions/objects to implement next. I started out by implementing all the functions used by the Vector NTI installer (which is how I got into wine programming at all; and which was actually dependent on one of these actions for installing at the time), and for the past few weeks I have been following the functions required by the iTunes 7 installer. However, now that I have implemented all the functions used by both of these (yay), I am having trouble finding another installer that uses a lot of scripting, so I was wondering if anyone had any suggestions? It really helps to have something like that to guide/motivate me. (I googled UNHANDLED ACTION TYPE and tried the installers I found but all the installers I actually tried out didn't seem to use scripting or maybe just unimplmeneted scripting functions anymore). Alternately, is there any other use for MSI OLE automation besides installers with scriptable actions? If so, what functions would be important for that use? (I know Mike McCormack talked at one point about using these interfaces to run custom actions in a separate process, but I am not really clear as to why automation is really necessary for this and, if so, how exactly it would be used, since all the automation functions are just wrappers around existing functions anyway.) I'm not sure if this is OLE or not, but AutoIt installers use a lot of scripting and can be wrapped around msi.. I would post locations of where to find quite a few here on the list, but I'm afraid of being flamed for spamming again, so look for my next email. -- Thanks Tom
Re: ADVAPI32: Start test for service tests
On 5/20/07, Rolf Kalbermatter [EMAIL PROTECTED] wrote:
Changelog
dlls/advapi32/tests/Makefile.in
dlls/advapi32/tests/service.c
Start test for service tests
License: X11/LGPL
This test will crash without the previous patch
Return error on NULL service name to GetServiceDisplayNameA/W
Rolf Kalbermatter
+ok(size = 1, size should be = 1 was %d!, size);
This is a bad test. According to msdn, GetServiceDisplayName does not
modify lpcchBuffer on error, so size should be exactly 0.
+static BOOL test_service_info(SC_HANDLE hscm)
test functions are void, not BOOL. You're never going to do anything
but return, and there's no value to check by the caller.
+ok(size, size should be returned!);
And what is the size? Tests are supposed to be exact. If our
implementation is incorrect, and we return size as 39491, that's
certainly not correct, but this test won't fail when it should.
+static BOOL test_service_enum(SC_HANDLE hscm)
+{
+return 0;
+}
Please don't add dead code.
--
James Hawkins
