Re: [PATCH 3/4] shell32: Add IKnownFolder::SetPath() implementation
Please, ignore this single patch. This function should be implemented in other way (using redirection feature, the thing I am working on but did not submit yet). W dniu 23.06.2011 18:50, Mariusz Pluciński pisze: --- dlls/shell32/shellpath.c | 32 ++-- dlls/shell32/tests/shellpath.c |3 +-- 2 files changed, 31 insertions(+), 4 deletions(-) -- Best regards Mariusz Pluciński
Re: [PATCH 1/5] shell32: Add IKnownFolderManager::RegisterFolder implementation
Hello Would you explain me, what is wrong with this patches series? I've submitted it last week and for some reason it's status is untouched. (the failed status seems to be temporal testbot's problem rather than my patch's, so this is not the reason). I have no idea how to fix them. Best regards Mariusz Pluciński W dniu 15.06.2011 18:05, Mariusz Pluciński pisze: To not break currently working applications/tests, I decided to implement known folders using following schema: 1. implement infrastructure of known folders without breaking currently working CSIDL-based way. New code is used only for folders registered using RegisterFolder(). For all others, the older code using CSIDL_Data array is used. 2. move all folders from CSIDL_Data array to registry and remove old way of accessing them. --- dlls/shell32/shellpath.c | 70 ++- dlls/shell32/tests/shellpath.c |1 - 2 files changed, 68 insertions(+), 3 deletions(-)
Re: [PATCH 1/4] shell32/tests: basic tests of IKnownFolderManager
Thank you for suggestions. I fixed the problems. W dniu 05.06.2011 22:26, Vincent Povirk pisze: +/* try to set new path */ +hr = IKnownFolder_SetPath(folder, 0, sTempDir); +todo_wine +ok(hr == S_OK, setting path failed: 0x%08x\n, hr); I'd suggest making up + registering your own known folder to test this feature, rather than using a standard one. I worry someone could end up with a broken Windows install if we fail to put it back somehow Testing of registering custom folders is implemented in patch I did not submit yet. I think I will simply move test of setting path to (or after) that patch. -- Best regards Mariusz Pluciński
[GSoC] Continue work on Games Explorer
Hello, wine-devel In the last year's GSoC, I was working on implementation of Games Explorer features under Wine. I have successfully created it's own interfaces and made them working. However, the task proved harder than I thought before, so I did not create a user-interface part of the library. My idea for this summer is to finish the implementation of gameux.dll - writing the Shell Extension for GE. It would behave almost exact as the Windows equivalent - it should be able to display registered games as shell items, with possibility to run them, see the statistics etc. Having this should give user-experience a great deal. However, in my opinion it would be also a good way to check and extend the existing implementation of shell32. As far as I know, there is currently no real shell extension being part of Wine, so the working one would increase compatibility a much. There will be probably a problem with making my extension usable for user, as there's no working explorer currently in Wine. However, as I see, the implementation of explorer is one of popular proposal this year. In my opinion, it would be good idea to cooperate my work on GE Shell Extension with the person who will implement explorer.exe (if both ideas will be selected for realization). This would probably improve the quality of both projects. Summarizing, my project assumes following things to do: - write testing set to run under Windows. Tests will read the data from GE using it's shell interfaces. - creating stubs for shell interfaces. This will include following interfaces IShellFolder(2/3?), IShellView, IPersistFolder, IEnumIDList, IContextMenu, and probably a few other. I have created some stubs at the end of last GSoC, but never committed them, as they were requiring a few improvements. - implementing interfaces using the existing infrastructure inside of gameux.dll. Routines giving access to list of installed games were written by me last year, but there are still some missing parts which must be filled to let shell interfaces return proper data. - extending and fixing parts of shell32 (or other libraries) if required. This is mostly undefined part of task, but I've listed it here, cause I suppose this could take significant part of project's time. If there will be still time after finishing the points above, I would like to add one feature from my last-year proposal: a legacy games support. When Microsoft introduced the Games Explorer in Vista, they provided a big set of definitions of currently existing games to make them visible in GE, without requirement of modifications in games. My idea is to extend Wine's Application Database to allow it serve as legacy games database for our GE. This would increment an user experience from using the tool. My name is Mariusz Pluciński. I'm 20 years old student of Information Technology in Gdańsk University of Technology in Poland. Last year I was successfully participating in GSoC in Wine project (project name was Implementation of Windows Game Explorer equivalent ), so my knowledge seems to be enough to continue work with even better results. Comments are welcome -- Best regards Mariusz Pluciński
Re: Error path issues with gameux: Add implementation of IGameStatisticsMgr::RemoveGameStatistics.
W dniu 29.09.2010 17:15, Joris Huizer pisze: Hello, I noticed the committed patch gameux: Add implementation of IGameStatisticsMgr::RemoveGameStatistics. (5cac9d2cb2c020802a56a5b1b28348316f1087ba) The GAMEUX_getAppIdFromGDFPath() function now ends with: +HeapFree(GetProcessHeap(), 0, lpRegistryPath); + + TRACE(found app id: %s, return: %#x\n, debugstr_w(lpApplicationId), hr); +return hr; In most of the error paths, lpRegistryPath is not initialized, so it's pointing to garbage; I think just initializing to NULL should be sufficient; Similarly, in that case, lpApplicationId is not initialized, so it contains garbage; Tracing will probably print some random stack bytes before hitting a zero byte. I'm not completely sure what should be done about this issue; I think it should probably only be traced on success, perhaps tracing the error otherwise; Any ideas? HTH, Joris Hi I'm author of this patch. You're definitely right, I moved code of this function from other place, and forgot to initialize these variables properly. I'll fix that by initializing these variables (I do not want to make TRACE conditional, as it prints HRESULT value too). Anyway, thanks for your notification. -- Best regards Mariusz Pluciński
Re: [PATCH 1/4] gameux: initial implementation of loading game statistics
W dniu 28.09.2010 17:11, Alexandre Julliard pisze:
Mariusz Plucińskivsha...@gmail.com writes:
+static BOOL GAMEUX_isFileExists(LPCWSTR sFile)
+{
+HANDLE hFile;
+
+hFile = CreateFileW(sFile, GENERIC_READ, 0,
+NULL, OPEN_EXISTING, 0, NULL);
+
+if(hFile == INVALID_HANDLE_VALUE)
+return FALSE;
+
+CloseHandle(hFile);
+return TRUE;
+}
This sort of thing is not a good idea in general, even if it had a more
grammatically correct function name ;-) If you need to load a file you
have to open it anyway, so you can check for errors at that point.
Checking for existence beforehand is only doing duplicate work.
OK, I'll redesign process of loading these data. Thanks for advice.
--
Best regards
Mariusz Pluciński
Re: [PATCH 1/5] gameux: Add implementation of IGameStatistics::SetCategoryTitle
W dniu 26.09.2010 15:07, Nikolay Sivov pisze:
On 9/26/2010 16:59, Mariusz Pluciński wrote:
---
dlls/gameux/gamestatistics.c | 50 ++-
dlls/gameux/tests/gamestatistics.c | 14 +-
2 files changed, 55 insertions(+), 9 deletions(-)
@@ -177,8 +201,30 @@ static HRESULT WINAPI
GameStatisticsImpl_SetCategoryTitle(
WORD categoryIndex,
LPCWSTR title)
{
- FIXME(stub\n);
- return E_NOTIMPL;
+ HRESULT hr = S_OK;
+ DWORD dwLength;
+ GameStatisticsImpl *This = impl_from_IGameStatistics(iface);
+
+ TRACE((%p, %d, %s)\n, This, categoryIndex, debugstr_w(title));
+
+ if(!title || categoryIndex= MAX_CATEGORIES)
+ hr = E_INVALIDARG;
Just return here and be done with it, this will save you hr
initialization and unnecessary if (SUCCEEDED(hr)) after that.
You're right, I'll fix it.
+
+ if(SUCCEEDED(hr))
+ {
+ dwLength = lstrlenW(title);
+
+ if(dwLength MAX_CATEGORY_LENGTH)
+ {
+ hr = S_FALSE;
+ dwLength = MAX_CATEGORY_LENGTH;
+ }
Does it really copy with hr == S_FALSE ?
Yes, this behavior is subject of one of tests.
--
Best regards
Mariusz Pluciński
Re: Wine test bot failure?
W dniu 26.09.2010 20:27, Greg Geldorp pisze: This is now fixed. The problem occurred when your patch contained a change to tests/Makefile.in. The config.status invocation to create an updated Makefile recently changed, TestBot now calls config.status with the correct arguments again. Greg. Hi Thanks for your efforts. Good to know that bot is working well again. -- Best regards Mariusz Pluciński
Re: Wine test bot failure?
W dniu 24.09.2010 09:30, Travis Athougies pisze: Hi, I was trying to run my HLSL test suite patch through wine test bot and the build failed. However, it's not a compilation failure. Instead it complains about not being able to copy some executable file. Also, the build fails almost instantaneously. It also complains about a missing command. The results are at https://testbot.winehq.org/JobDetails.pl?Key=5449log_101=1#k101 How can I get this to builid and run? Travis Athougies. Hi I also had this problem yesterday both with patches submitted manually and my patches transferred from wine-patches. I can confirm that sending executables instead worked for me, but this is possible only when submitting own test, and not when it is loaded from wine-patches. It is also strange that as I see, only your and my patches causes this error, there's some other which works properly. I hope Greg will look at this, if he finds time. -- Best regards Mariusz Pluciński
Re: [PATCH 1/8] gameux/tests: Add test of storing and reading game statistics (try2)
W dniu 23.09.2010 15:40, (Marvin) pisze: Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at http://testbot.winehq.org/JobDetails.pl?Key=5426 Your paranoid android. === WINEBUILD (build) === Make failed This is strange and I don't see any way how it would be connected with my patch. Error message says: make: /tools/winapi/make_filter: Command not found and when I was trying to submit patch to bot manually, it caused the same error. Does anyone know what's going on here? -- Best regards Mariusz Pluciński
Re: Suggestion for the Game Explorer implementation
W dniu 10.09.2010 09:50, אלעד pisze: I have a little suggestion: integrate the Game Explorer with the Games menu of the desktop, so that games i install in wine will be added to the Games menu automaticlly. This is good idea, but it can't be done without having implemented rest of Games Explorer. I'm working on it, but it will take some time before it gets into main git tree. Anyway, thanks for the suggestion. -- Best regards Mariusz Pluciński
Problem with geting account at testbot
Hello I have a problem with my account at testbot.winehq.org. Long time ago, I registered my account. To this day I have not received an activation e-mail. I thought it was maybe rejected, because I was not well-known member of the Wine community that time. Today I noticed that I can not send request for account, because User already exists. Trying to use forgotten password feature gave me information that my account was not activated. What could I do with this? I was working on Wine some time without this, but now testbot account would be very helpful for me. Mariusz Pluciński
Re: [PATCH 2/6] gameux: initial implementation of IGameExplorer::AddGame
W dniu 03.09.2010 13:01, Nikolay Sivov pisze:
On 9/3/2010 13:25, Mariusz Pluciński wrote:
---
dlls/gameux/Makefile.in | 2 +-
dlls/gameux/gameexplorer.c | 254 +-
dlls/gameux/gameux_private.h | 63 ++
dlls/gameux/tests/gameexplorer.c | 18 ++--
4 files changed, 322 insertions(+), 15 deletions(-)
+/***
+ * _initGameData
+ *
+ * Internal helper function. Description available in
gameux_private.h file
+ */
+void _initGameData(struct GAME_DATA *GameData)
+{
+ GameData-sGDFBinaryPath = NULL;
+ GameData-sGameInstallDirectory = NULL;
+}
Do you really need another helper for that? Please use better naming
like GAMEUX_* for example.
I need this values to be initialized with NULL, to be properly freed in
my _uninit function. So, if adding helper isn't very well solution,
should I use ZeroMemory() macro, or memset() call directly?
+void _uninitGameData(struct GAME_DATA *GameData)
+{
+ CoTaskMemFree(GameData-sGDFBinaryPath);
+ CoTaskMemFree(GameData-sGameInstallDirectory);
+}
Any specific reason you need CoTaskMem* here and not a process heap?
I decided to use it, because I did not want to mix two methods of memory
management in my code (CoTaskMemFree is required in some COM related
areas, but mainly in code which I did not send yet). Is there any
disadvantage of using it?
+ WCHAR sInstanceId[40];
+ WCHAR sRegistryPath[8192];
Where does this come from? Sizes I mean.
I did a mistake. sInstanceId needs only 39 characters to store GUID and
zero byte for termination. Thanks.
In defining size of sRegistryPath, I followed suggestions from MSDN:
http://msdn.microsoft.com/en-us/library/ms724872%28v=VS.85%29.aspx
by multiplying 32*256 - maximum number of registry tree levels in single
API call and maximum number of characters in key name with following '\'
character added. I must assume, that it was a problem for me to decide
which value should I use. Is there any better way to do this?
Re: Macro names instead of numbers in logs
W dniu 07.09.2010 12:09, Florian Köberle pisze: Hello when running a program using wine it's possible to log +message to get informed about all the messages which get sent. This debug channel displays the macro names like WM_NOTIFY instead of numbers. The most other debug channels and the regression tests however display numbers. Functions like SPY_GetMsgName which can make window messages more human readable can be found in dlls/user32/spy.c. Is there a acceptable way of making functions like SPY_GetMsgName available to other libraries and tests? There are about 80 TRACE/trace lines which could be improved: egrep trace.*hwnd.*lParam dlls/ -R -i -I|grep -v user32|wc Best regards, Florian Hello In my opinion it would be good to make it available in similar way, as functions like debugstr_guid, which are defined in include/wine/debug.h Messages' names are declared as an array MessageTypeNames in spy.c . Maybe it would be enough to copy it into the header and wrap access to it into simple function like debugstr_msg()? This is easiest way, but in the result there will be copy of array in each .so library. There will be also problem with multiple reference, but this may be solved following solution used in test.h. I'm not so familiar with this, so maybe other, more experienced devs could say something about this idea. Mariusz Pluciński
Re: [PATCH 3/6] gameux: add support of loading Application Id into registry
W dniu 03.09.2010 13:13, Nikolay Sivov pisze: On 9/3/2010 13:25, Mariusz Pluciński wrote: + hr = IXMLDOMDocument_get_documentElement(lpXMLDocument,lpXMLRootElement); + if(hr == S_FALSE) + hr = E_FAIL; hr != S_OK works. I want this function to return E_FAIL in the case there's no root element, and other code error when get_documentElement encouraged other problem. If I do if(hr != S_OK) hr = E_FAIL; It will also replace other E_* codes with E_FAIL, and this will make problems discovering more complicated. P.S. it makes sense to test xml parsing part with native msxml first. This will hopefully show some problems with builtin msxml. OK, I'll this about this.
Re: [PATCH 2/6] gameux: initial implementation of IGameExplorer::AddGame
W dniu 07.09.2010 11:52, Mariusz Pluciński pisze: W dniu 03.09.2010 13:01, Nikolay Sivov pisze: On 9/3/2010 13:25, Mariusz Pluciński wrote: + WCHAR sInstanceId[40]; + WCHAR sRegistryPath[8192]; Where does this come from? Sizes I mean. I did a mistake. sInstanceId needs only 39 characters to store GUID and zero byte for termination. Thanks. In defining size of sRegistryPath, I followed suggestions from MSDN: http://msdn.microsoft.com/en-us/library/ms724872%28v=VS.85%29.aspx by multiplying 32*256 - maximum number of registry tree levels in single API call and maximum number of characters in key name with following '\' character added. I must assume, that it was a problem for me to decide which value should I use. Is there any better way to do this? Oh, and I forgot to add: my function _buildGameRegistryPath is copied directly from my previous commit, which was accepted: http://source.winehq.org/git/wine.git/?a=commitdiff;h=6cb7658377ac513e8acacd5b4eaeab4632afaadc
Re: [PATCH 1/1] gameux/tests: verifying registry values created by GameExplorer (try 4)
W dniu 26.08.2010 18:34, (Marvin) pisze: Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at http://testbot.winehq.org/JobDetails.pl?Key=4793 Your paranoid android. === W7PRO (32 bit gameexplorer) === gameexplorer.c:453: Test failed: failed while checking registry value (error 0x1) gameexplorer.c:471: Test failed: failed while checking registry value (error 0x1) === W7PROX64 (32 bit gameexplorer) === gameexplorer.c:453: Test failed: failed while checking registry value (error 0x1) gameexplorer.c:471: Test failed: failed while checking registry value (error 0x1) === W7PROX64 (64 bit gameexplorer) === gameexplorer.c:453: Test failed: failed while checking registry value (error 0x1) gameexplorer.c:471: Test failed: failed while checking registry value (error 0x1) It seems that test bot did not rebuild the .gdf.xml file which I attached as resource (I don't see call of wrc in WINEBUILD log). I also notified similar behavior on my machine. It is because there's no rule in Makefile which depends on this file. Could you tell me is there proper way to tell make to track changes in my custom file? Expected effect is running wrc while build if there was modification in my .gdf.xml file (currently, it is started only if .rc file was modified). Of course, Makefiles in Wine are auto-generated, so the solution would add code only to Makefile.in file.
Re: [PATCH 1/1] gameux/tests: verifying registry values created by GameExplorer (try 4)
W dniu 29.08.2010 18:33, Octavian Voicu pisze: 2010/8/29 Mariusz Plucińskivsha...@gmail.com: Could you tell me is there proper way to tell make to track changes in my custom file? Expected effect is running wrc while build if there was modification in my .gdf.xml file (currently, it is started only if .rc file was modified). Of course, Makefiles in Wine are auto-generated, so the solution would add code only to Makefile.in file. You need to add a @makedep directive in gameux/tests/rsrc.rc: /* @makedep: test.gdf.xml */ ID_GDF_XML DATA test.gdf.xml This should include test.gdf.xml as a dependency for rsrc.res in the automatically generated Makefile. See dlls/cards/cards.rc for more examples. Octavian Thanks Octavian, it works exactly as I expected.
Re: [PATCH 5/6] gameux: Add initial implementation of IGameExplorer2::CheckAccess method
Hello
W dniu 16.08.2010 10:00, Mariusz Pluciński pisze:
---
dlls/gameux/gameexplorer.c | 7 +--
1 files changed, 5 insertions(+), 2 deletions(-)
This is patch I sent to wine-patches yesterday. It was marked as
Pending. I know that what I sent is not proper solution. But as I
wrote in FIXME, it's in my opinion impossible to implement it properly,
cause from what I know Wine does not support parental control. So,
instead of doing real check, my function simply always grants access.
My question is: what should I do with it? It cannot be left stub, as
there's already bug caused by this (bug #23850). And probably every game
which uses Game Explorer will behave that same. Should I write test case
to demonstrate that native works that same in most cases?
From 89f720c9883ed73472c6a8e4350d911672cd8c73 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Mariusz=20Pluci=C5=84ski?= vsha...@gmail.com
Date: Sun, 1 Aug 2010 22:05:01 +0100
Subject: gameux: Add initial implementation of IGameExplorer2::CheckAccess method
To: wine-patches wine-patc...@winehq.org
Reply-To: wine-devel wine-devel@winehq.org
---
dlls/gameux/gameexplorer.c |7 +--
1 files changed, 5 insertions(+), 2 deletions(-)
diff --git a/dlls/gameux/gameexplorer.c b/dlls/gameux/gameexplorer.c
index b8f57a7..25360a8 100644
--- a/dlls/gameux/gameexplorer.c
+++ b/dlls/gameux/gameexplorer.c
@@ -206,8 +206,11 @@ static HRESULT WINAPI GameExplorer2Impl_CheckAccess(
BOOL *pHasAccess)
{
GameExplorerImpl *This = impl_from_IGameExplorer2(iface);
-FIXME(stub (%p, %s, %p)\n, This, debugstr_w(binaryGDFPath), pHasAccess);
-return E_NOTIMPL;
+TRACE((%p, %s, %p)\n, This, debugstr_w(binaryGDFPath), pHasAccess);
+FIXME(not properly implemented due to lack of parental control support in Wine\n);
+/* access is always granted, it should make all applications working */
+*pHasAccess = TRUE;
+return S_OK;
}
static HRESULT WINAPI GameExplorer2Impl_InstallGame(
--
1.7.2
Re: [PATCH 3/3] gameux/tests: verifying registry values created by GameExplorer
W dniu 18.08.2010 17:49, (Marvin) pisze: Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at http://testbot.winehq.org/JobDetails.pl?Key=4540 Your paranoid android. === W98SE (32 bit gameexplorer) === Failure running script in VM: Exceeded timeout limit of 315 sec === W2KPROSP4 (32 bit gameexplorer) === Timeout === WXPPROSP3 (32 bit gameexplorer) === Timeout This result is strange, cause routine modified by this patch (called test_add_remove_game ) is not even called on these operating systems - and test added by my previous patch demonstrates it (and it succeeded). Did I something wrong? I cannot imagine how it could fail when previous test was succeeded.
Re: [PATCH 3/3] gameux/tests: verifying registry values created by GameExplorer
W dniu 18.08.2010 18:28, Andrew Eikum pisze: This result is strange, cause routine modified by this patch (called test_add_remove_game ) is not even called on these operating systems - and test added by my previous patch demonstrates it (and it succeeded). Did I something wrong? I cannot imagine how it could fail when previous test was succeeded. You can see the error message dialog in the screenshots on the testbot result webpage. In this case, you've got missing exports, ConvertSidToSidStringW and RegGetValueW. Some solutions are to make those into function pointers (and skip appropriately if they're missing), use the A versions if they exist, or use a different function that exists on more platforms. Andrew I understand. Thank you very much for the explanation. I did not know, that new code can interfere in any way on systems where it is never called. W dniu 18.08.2010 18:33, Vincent Povirk pisze: Oh. Personally, I would ignore failures on operating systems Vista, since gameux won't be present and the tests would not normally be run. OK, I'll see if my patch is accepted despite of these results. If not, I'll modify it, to make it calling these routines through pointers.
Re: [PATCH 1/3] gameux: Add definitions of resource identifiers to header file
W dniu 18.08.2010 18:09, Vincent Povirk pisze: I think it would be helpful if you passed a string description to your _validate functions so that in case of failure, you can tell where the original call to _validateGameRegistryKey was, instead of just the line containing the ok() call. Can I do it by passing __LINE__ macro as parameter to my _validate* functions?
Re: [PATCH 1/3] gameux: Add definitions of resource identifiers to header file
W dniu 18.08.2010 19:34, GOUJON Alexandre pisze: On 08/18/2010 07:06 PM, Mariusz Pluciński wrote: Can I do it by passing __LINE__ macro as parameter to my _validate* functions? Some tests already use __LINE__ as a parameter. See http://source.winehq.org/git/wine.git/?a=blob;f=dlls/advapi32/tests/cred.c#l260 and http://source.winehq.org/git/wine.git/?a=blob;f=dlls/advapi32/tests/cred.c#l201 for instance. Thanks for these examples. I though about little different solution, but this looks really easier than my ideas.
Re: [PATCH 2/5] gameux: Add stub of IGameStatisticsMgr implementation (try 2)
W dniu 04.08.2010 20:45, Jerome Leclanche pisze: Just resend this one, it's easier that way. J. Leclanche / Adys 2010/8/3 Mariusz Plucińskivsha...@gmail.com: W dniu 03.08.2010 13:28, Nikolay Sivov pisze: On 8/3/2010 13:58, Mariusz Pluciński wrote: --- dlls/gameux/Makefile.in | 1 + dlls/gameux/factory.c | 5 ++ dlls/gameux/gamestatistics.c | 153 ++ dlls/gameux/gameux_private.h | 1 + dlls/gameux/regsvr.c | 9 +++ 5 files changed, 169 insertions(+), 0 deletions(-) create mode 100644 dlls/gameux/gamestatistics.c + TRACE((%p, %s, 0x%x, %p, %p)\n, iface, debugstr_w(GDFBinaryPath), openType, pOpenResult, ppiStats); + FIXME(stub\n); + return E_NOTIMPL; No need for duplicated traces, add one FIXME with full parameter output in it. I hope my patches are acceptable despite of this. But in the future I'll avoid it, thanks. You may be right. I'll do it, thanks.
Re: [PATCH 2/5] gameux: Add stub of IGameStatisticsMgr implementation (try 2)
W dniu 03.08.2010 13:28, Nikolay Sivov pisze: On 8/3/2010 13:58, Mariusz Pluciński wrote: --- dlls/gameux/Makefile.in | 1 + dlls/gameux/factory.c | 5 ++ dlls/gameux/gamestatistics.c | 153 ++ dlls/gameux/gameux_private.h | 1 + dlls/gameux/regsvr.c | 9 +++ 5 files changed, 169 insertions(+), 0 deletions(-) create mode 100644 dlls/gameux/gamestatistics.c + TRACE((%p, %s, 0x%x, %p, %p)\n, iface, debugstr_w(GDFBinaryPath), openType, pOpenResult, ppiStats); + FIXME(stub\n); + return E_NOTIMPL; No need for duplicated traces, add one FIXME with full parameter output in it. I hope my patches are acceptable despite of this. But in the future I'll avoid it, thanks.
Re: [1/5] gameux: Add initial implementation of gameux.dll
W dniu 19.07.2010 15:02, Henri Verbeet pisze: 2010/7/18 Mariusz Plucińskivsha...@gmail.com: +static HINSTANCE hInstance; This is unused. You're mixing tabs and spaces, and have a couple of trailing spaces. Also: + * DllRegisterServer (OLEAUT32.@) The code of my regsvr.c is almost non-modified copy of the same file in oleaut32.dll implementation. If it's bad formatted, why it exists in official Wine code? However, I modified my copy to fulfill Wine's formatting assumptions and resent it. Hope it's acceptable now.
Administrative privileges and running tests under Windows
Hi wine-devel I have problems with tests I written last time. The problem is connected with privileges levels under Windows. The method I'm testing is IGameExplorer::AddGame, which registers given game in Windows Game Explorer. One of it's parameters (installScope) defines if game should be registered for all users or only currently logged one. The problem is that routine's behaviour depends on if application was started with administrative privileges or not. If I call method with GIS_ALL_USERS parameter, it succeeds only with administrative privileges (fails if I run it as normal user). If I call it with GIS_CURRENT_USER parameter, it succeeds under normal user level, and fails (sic!) under administrative. My question is, how I should write tests to support both of these cases. Both seems to be exclusive, and I prefer first to ask, rather than trying implement it in some odd (and probably wrong) way. I also want to make it available to run under Wine project's test machines, but I don't know how they're configured and will them allow me to test administrative case.
Re: Administrative privileges and running tests under Windows
W dniu 16.07.2010 19:59, Reece Dunn pisze: Use broken() to denote the administrator case -- ok(hr == S_OK || broken(hr == E_ACCESSDENIED) /* non-Admin user */, IGameExplorer_AddGame(...)); This means that E_ACCESSDENIED is a valid case on Windows, but not on Wine. - Reece Yes, I know how broken() works, but there are two problems with it: First problem, is that this is not what I want to do. I did not wrote about it in previous mail, but I do a little more than only calling this procedure. In details, this routine writes some data into registry and after call I check these data. These data depends on the parameter I described before (installScope). The problem is that I can run these tests on Windows, manually selecting permission level (and they behave as I described before), and they behave as I expected (I described how this routine behaves on several cases). I hope that making it able to run on Windows will let me to be sure that data produced by my library are identical like this created by Windows' one. Second problem is that I cannot simply compare result with some ACCESSDENIED error code, cause this routine simply does not return it. Instead, when the access denied occurs, it returns E_FAIL, as in almost every other problem. And I cannot do broken(hr==E_FAIL), because then test will be always passed on Windows, even if completely other problem occurs. So, even if I give up with checking data, broken() won't work here.
Re: [RFC] gameux.dll partial implementation
Hello First, thank you very much for checking my code. That's good to know my design is valid and I can continue creating code in this way. Of course, I know that my code will probably be rejected on the beginning, but it's still better for me when someone reviews my code, than working completely without checking all the time. I believe that winetest.exe will not start the test on Windows systems that are missing gameux.dll, so you shouldn't have to worry about this as long as all native versions of gameux.dll contain the class. I didn't know about that. Thanks. I think you can get away with an lstrcmpW here. Yes, technically it can behave differently depending on locale, but you're doing a case-sensitive compare with a string with only ascii characters. Also, everyone else uses lstrcmpW. You're right, I'll replace it. +IMPORTS = ole32 user32 kernel32 advapi32 oleaut32 msvcrt shell32 The msvcrt import looks suspicious to me, but I can't say how you should avoid using the wtof function later. + GDFData-fPerformanceRatingMinimum = _wtof((LPCWSTR)bstrValue); Maybe you could avoid converting this to a float, or perhaps convert to ANSI first? Then you wouldn't have to import msvcrt. Why should I avoid using msvcrt, when e.g. Microsoft's implementation of gameux.dll uses it? I think you should avoid internal stub functions. Instead, you should initially leave out the code that uses your internal function, then add a partially implemented implemented internal function and code that uses it in the same patch. If not code freeze, I would know about it after sending first patch with internal stub. Now I need to fix a little more code. + LPWSTR values[5]; Can there be more than 5 genres? Perhaps you should check the length of the IXMLDOMNodeList and allocate your array first based on that length? Same applies to the other node types with unknown sizes. MSDN says that there can be maximum 5 genres. If there are more than 5 in GDF, I simply skip them. This is why I used array with fixed size. hr = DoSomething(); if (SUCCEEDED(hr)) hr = DoSomethingElse(); if (SUCCEEDED(hr)) hr = DoAnotherThing(); Thanks for great strategy. I also dislike when there's lot of indentations, but didn't know how to solve it without goto (which in my opinion is even more unreadable). (In fact, all internal functions meant to be used only in one C file should be static.) I must admit, that Wine is first code in my life where I saw wide usage of static functions in C. This is probably why I often forget about using them. Again, thanks very much. I hope that code freeze will really finish in this week, and your advices will increase chances for my code to be accepted.
Re: Creating tests with additional binary modules
Do they really need to be separate binaries? Unfortunately yes. To the function I pass only the path to binary, and it unpacks data internally, so I cannot select actual resource. One binary can contain multiple GDFs only if they are translations of the same file in few languages. And I don't know is there any way to force library to load specified language version (and it is, in my opinion, not clean way of testing). And no, it doesn't have to be a pure win-pe binary. Wine can load and parse resources just from winelib (dll.so/exe.so) binaries. That's true on Wine, but I also want to make my tests runnable under Windows, so in this case I need to create native PE modules. And as I said, my main problem is that I don't know how to write rules in Makefile.in to build what I need.
Re: Creating tests with additional binary modules
W dniu 1 lipca 2010 21:27 użytkownik Alexandre Julliard julli...@winehq.org napisał: You can't do that in the Makefile, you need to generate the files at run time. Huh, so while executing the test, I need to run at least resources compiler and linker, right? It looks really more complicated way, and I admit that I completely don't know how to do it. Which tools should I use? Can I use Mingw? Can I assume that these tools are installed on system where test is running? Or maybe I should use some tools provided by wine? And, of course, how to make it working on Windows?
Re: Creating tests with additional binary modules
W dniu 1 lipca 2010 21:55 użytkownik Alexandre Julliard julli...@winehq.org napisał: Mariusz Pluciński vsha...@gmail.com writes: W dniu 1 lipca 2010 21:27 użytkownik Alexandre Julliard julli...@winehq.org napisał: You can't do that in the Makefile, you need to generate the files at run time. Huh, so while executing the test, I need to run at least resources compiler and linker, right? It looks really more complicated way, and I admit that I completely don't know how to do it. Which tools should I use? Can I use Mingw? Can I assume that these tools are installed on system where test is running? Or maybe I should use some tools provided by wine? And, of course, how to make it working on Windows? None of that, of course. The resources are built at compile time, at run time you create a PE header and copy the needed resource data. You may even be able to use UpdateResource to make things easier. All right, now it's more clear for me. I'm not so familiar with working on resources, and I didn't know there's API call which can modify resources in existing binary. I'll try to make it this way, thanks.
Creating tests with additional binary modules
Hi, wine-devel I'm working on implementation of Windows Game Explorer interfaces for Wine. The work is in advanced stage now, but I have problem with implementation of conformance tests. Thing I want to test is loading and parsing so-called Game Definition Files. GDF are not separate files, but stored as resources in binary modules (usually in game's main executable). Using GE interfaces, programmer only needs to pass path to binary, and GE automatically loads and process embedded GDF(s). Checking results of routines execution is not problem for me. But thing I test is parser, so I need to pass various GDF files to routine. And, as GDFs are stored in binaries, I will need to create many binaries. They should be created in compile time and available for test's executable while running it. The problem is that I don't know how to do this using wine's mechanisms. How should Makefile.in file look to build additional executable files properly (they should be probably always native win32 executables, even if parameter crosstest wasn't specified)? How should I guarantee that these additional executables will be copied into winetest directory (to make them accessible while executing tests)? Thanks in advance Mariusz Pluciński
New flags in LoadLibraryEx
Hello, wine-devel
It seems, that Microsoft introduced new flags for kernel32.LoadLibraryEx
function, which are not yet available in Wine.
Those flags are: LOAD_IGNORE_CODE_AUTHZ_LEVEL,
LOAD_LIBRARY_AS_DATAFILE_EXCLUSIVE, LOAD_LIBRARY_AS_IMAGE_RESOURCE
and LOAD_LIBRARY_REQUIRE_SIGNED_TARGET. Most of them were added with
Vista introduction, and the last one is not documented in MSDN.
I don't want to implement them (at least, not now), but want to add
some stubby support. So, I added flags into winuser.h and the
following code on the beginning of kernel32.load_library routine:
if( flags LOAD_IGNORE_CODE_AUTHZ_LEVEL )
FIXME(unsupported flag: LOAD_IGNORE_CODE_AUTHZ_LEVEL\n);
if( flags LOAD_LIBRARY_AS_IMAGE_RESOURCE )
FIXME(unsupported flag: LOAD_LIBRARY_AS_IMAGE_RESOURCE\n);
if( flags LOAD_LIBRARY_AS_DATAFILE_EXCLUSIVE ) {
FIXME(unsupported flag: LOAD_LIBRARY_AS_DATAFILE_EXCLUSIVE\n);
/* temporary solution which should let some application working */
flags |= LOAD_LIBRARY_AS_DATAFILE;
}
if( flags LOAD_LIBRARY_REQUIRE_SIGNED_TARGET )
FIXME(unsupported flag: LOAD_LIBRARY_REQUIRE_SIGNED_TARGET\n);
Of course it works, but is it acceptable by Wine project?
Re: gameux: Add declaration of IGameExplorer2 interface
You're right, but I thought about numbering too late, when I noticed my patches appeared in wrong order. I attached configure files, cause they're part of main tree. I though, that if they're intended to being generated, they would already be listed in .gitignore file. So, must I avoid sending both configure and configure.ac files? Also, should I fix it, and resend these patches again now? W dniu 01.06.2010 22:26, Vincent Povirk pisze: Also, when you're sending a series where the later patches depend on the earlier patches, you should mark the correct order in your subject (i.e. start the subject with [1/5], [2/5], etc.). On Tue, Jun 1, 2010 at 3:04 PM, Vincent Povirk madewokh...@gmail.com wrote: I think you want to leave the configure change out of this patch. 2010/6/1 Mariusz Pluciński vsha...@gmail.com: --- configure |1 + configure.ac |1 + include/gameux.idl | 16 3 files changed, 18 insertions(+), 0 deletions(-)
Re: gameux: Add declaration of IGameExplorer2 interface
W dniu 02.06.2010 18:21, Vincent Povirk pisze: Your change to configure.ac appears to add gameux.dll, which you don't want to do just yet. Right, I did not notice it. This should be part of next commit in my local tree. Valid using git is still little problematic for me. The patch adding the header file looks good to me and does not depend on any other patches, so it may be accepted, or you may need to change it. Or Alexandre may just wait for you to resend the whole series correctly. I cannot guess. OK, I'll fix and resend it. Thanks for your help.
Allowed reverse engineering methods
Hello I'm working on implementation of Games Explorer for Wine (in Google Summer of Code). My work gets progress, but to finish it, I need to get more information about Windows implementation. My question is: which reverse engineering methods are legal and accepted while working in Wine project? Only information I found is located on Wine's wiki page (http://wiki.winehq.org/SummerOfCode): * You are not allowed to read or reuse Windows source code (leaked source / Windows Research Kernel* / ...) (* we are following the SFLC's advice) * You are not allowed to reverse engineer Windows files by disassembling or decompiling them * You are not allowed to analyze Windows files with the trace functions of Wine But which methods are allowed? I assume that obvious methods (reading header files, registry dumps, etc.) are acceptable, but can I e.g. analyze .pdb symbol files (availble in e.g. Microsoft's DirectX SDK)? Can I copy executable from Windows (.exe) and analyze it in Wine using winedebug's relay channel? (last point from website I linked above says that I can't analyze Windows files this way, but I'm not sure is it apply for executables in way I described). Mariusz Pluciński
re: Implementation of WIndows Gaming APIs as GSoC project
2010/3/30 Dan Kegel d...@kegel.com Sounds good to me -- and you could start right now by checking in stubs, if we don't have them already... The question is, though, how useful are these APIs (aside from needing them to play some games)? Which games make use of them? According to research made by Vincent Povirk (described at bugzilla: http://bugs.winehq.org/show_bug.cgi?id=21261), some games already use it. In my opinion, importance of this interface will be growing in the future. And MS will probably extend it to add new features. So, it would be easier to create these interfaces now, before moment they will become really big and complicated, like others Microsoft's APIs. Microsoft also solved problem with older games - they created some kind of games database which allows some older games to be visible in Games Explorer without using new APIs. Of couse, Wine project should not use Microsoft's database, but there's already Wine's Application Database, which after some extension may be used in similar way.
Re: Implementation of WIndows Gaming APIs as GSoC project
Vincent Povirk madewokherd+8...@gmail.com madewokherd%2b8...@gmail.com I suspect that once the classes exist, games will expect them to actually work, and adding the stubs will break some games that currently work. To avoid this problem, it should be possible to add option enabling these classes support in compilation configuration or Wine's config panel. Has this idea any sense? The project would potentially also include the Game Explorer shell namespace extension, which will likely be needed for shortcuts to work correctly. The control panel extension (CLSID_ControlPanel) is probably a good example. The main task there would be to implement an IShellFolder object that uses the game explorer database. This looks like good idea for me, I'll probably include it in my proposal. Thanks.
Implementation of WIndows Gaming APIs as GSoC project
Hello I'm Mariusz Pluciński, student of Information Technology in Gdańsk University of Technology (Poland). I decided to apply to Google Summer of Code in your project, cause I've been fascinated in Wine for a long time (without Wine, migration to open source OS would not be possible for me). In my opinion, one of the biggest problem for Wine is problems with support games written for MS Windows, so making progress in this area is something which I want to work on. I know C programming language very well, just as programming in Microsoft Windows APIs and Microsoft's COM technology. I also have some experience in working on open source - in Kdenlive project (video editor). I do a polish translation there, but I have also sent several patches to source code. In the past I was also reading some parts of Wine source code, so I know somewhat about how Wine's works and how it's code looks. In Google Summer of Code, I'm interested in implementation of new gaming APIs created by Microsoft for Windows Vista and enlarged in Windows 7. Main part of this is implementation of four COM interfaces: IGameExplorer, IGameExplorer2, IGameStatistics and IGameStatisticsMgr. In the bugzilla there's stub implementation of IGameExplorer interface, which may be good start point for me in development. Main parts of task will probably be creation of database to store games' data and parser of GDF files (Game Definition File). In favorable circumstances, if the APIs implementation is done fast enough, I will start work on simple equivalent of Windows Game Explorer application. It would be nice for Wine's users to control their games from one application, similar way as they do it in MS Windows. Also, application will use Game Statistics interfaces, so it will be good practical test for these interfaces. I hope my idea will get your acceptance. Thanks
