June 2007 - Wine-Devel - list.winehq.org

OpenGL 2.3 to 3.0
by Matthew Clark June 5, 2007

June 5, 2007

I was reading the other day about the 2.3 and 3.0 versions of the OpenGL API coming out this year( http://www.theinquirer.net/default.aspx?article=39846 ) and the first thought I had was wine and DX10. I was wondering what you guys thought about this, are you excited(as I am)? are you hesitant? Knowing OpenGL it shouldn't be hard at all to port the code over, but are there plans already or are the plans to wait till it's in our faces to worry about it? Sorry for the tangent but I was just curious to hear what you guys had to say about this.^_^ Thanks for all fish, -Matt

2 1

Re: OpenGL 2.3 to 3.0
by Stefan Dösinger June 5, 2007

June 5, 2007

Am Dienstag, 5. Juni 2007 22:17 schrieb Matthew Clark: > Ah this makes perfect sense and is exactly what I was looking for, thank > you for your response! My limited understanding from the article was > that 2.3 was simply cleanup and putting some extensions in the official > API that have been in drivers for a while just not in the official API > and then 3.0 is where the real change will be, BUT that it will only > activate the 3.0 functionality if it's on supporting hardware(i.e. DX10 > cards). Please correct me if my understanding is incorrect and again I > think we all realize this is all in the future and is just fun to talk > about^_^ They're takling more about codenames rather than 2.3 and 3.0, but I don't know the names currently. 2.3 will have all the functionality of 3.0 and be fully backwards compatible. This means you can use very old things together with the very new stuff. The drawback will be that you don't get the performance improvements of 3.0. This is somehow like d3d9. with d3d9.dll you can use the new d3d9 features, those will work on d3d9 cards only. But you can also use d3d9.dll to write an app that uses only dx7(or even earlier) level features, and those apps will run on dx7 cards - an example for that is the Source engine in hl2. 3.0 will be the complete rewrite. You'll have 3.0 only on cards that support it, and afaik you can't use the 3.0 API to program older cards(like a geforce 2 that doesn't even support shaders). This is what happened in d3d10 too. The advantage of the api cleanup is that you get rid of all the legacy stuff. The API is cleaner, drivers are simpler. The code is smaller and runs faster. If you look at wined3d you'll see that it is full of stuff to support even oldest cards(theoretically, in theory unsuccessful). Even though the state management keeps the most of the code sleeping until the app actually uses this features it makes everything more complex. A performance penalty is maybe the GL_EXTCALL stuff, which we use to be able to link against old opengl libs. Calling an address inserted by the dynamic linker at load time would be cheaper than finding a function pointer in a table and calling it.

2 1

Re: widl: Fix the is_array_type function.
by Dan Hipschman June 5, 2007

June 5, 2007

On Tue, Jun 05, 2007 at 07:50:42PM +0100, Robert Shearman wrote: > > Previously, an array of pointers wouldn't be detected by this function. > --- > tools/widl/header.h | 2 +- > 1 files changed, 1 insertions(+), 1 deletions(-) > > diff --git a/tools/widl/header.h b/tools/widl/header.h > index 57ae6b4..2165db7 100644 > --- a/tools/widl/header.h > +++ b/tools/widl/header.h > @@ -69,7 +69,7 @@ static inline int is_string_type(const a > static inline int is_array_type(const attr_list_t *attrs, const type_t *type, const array_dims_t *array) > { > return ((last_ptr(type) && !array && is_attr(attrs, ATTR_SIZEIS)) || > - (!is_ptr(type) && array)); > + array); > } > > #endif This and your next patch are in the same area as the one I just sent in yesterday. Actually, my patch completely removes this function. Can you try doing whatever you're working on with my last patch applied and see if that fixes your problems? Generating the format string for arrays of pointers is going to required a little more work because FIXED_REPEAT, etc. isn't implemented yet. My last patch set: http://winehq.org/pipermail/wine-patches/2007-June/040007.html http://winehq.org/pipermail/wine-patches/2007-June/040008.html Thanks, Dan

2 2

Re: ADVAPI32: Start test for service tests
by James Hawkins June 5, 2007

June 5, 2007

On 5/20/07, Rolf Kalbermatter <r.kalbermatter(a)hccnet.nl> 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

3 4

Re: wintrust: implement WintrustGetRegPolicyFlags and WintrustSetRegPolicyFlags
by Saulius Krasuckas June 5, 2007

June 5, 2007

* On Mon, 14 May 2007, Juan Lang wrote: > > +static const WCHAR Software_Publishing[] = { > + 'S','o','f','t','w','a','r','e','\\', > + 'M','i','c','r','o','s','o','f','t','\\', > + 'W','i','n','d','o','w','s','\\', > + 'C','u','r','r','e','n','t','V','e','r','s','i','o','n','\\', > + 'W','i','n','t','r','u','s','t','\\', > + 'T','r','u','s','t',' ','P','r','o','v','i','d','e','r','s','\\', > + 'S','o','f','t','w','a','r','e',' ', > + 'P','u','b','l','i','s','h','i','n','g',0 }; > +static const WCHAR State[] = { 'S','t','a','t','e',0 }; > + > /*********************************************************************** > * WintrustGetRegPolicyFlags (WINTRUST.@) > */ > void WINAPI WintrustGetRegPolicyFlags( DWORD* pdwPolicyFlags ) > { > - FIXME("%p\n", pdwPolicyFlags); > + HKEY key; > + LONG r; > + > + TRACE("%p\n", pdwPolicyFlags); > + > *pdwPolicyFlags = 0; > + r = RegCreateKeyExW(HKEY_CURRENT_USER, Software_Publishing, 0, NULL, 0, > + KEY_READ, NULL, &key, NULL); > + if (!r) > + { > + DWORD size = sizeof(DWORD); > + > + r = RegQueryValueExW(key, State, NULL, NULL, (LPBYTE)pdwPolicyFlags, > + &size); > + RegCloseKey(key); This function tries to open Software_Publishing key. And creates it, if the key didn't exist, I suppose. It is absent in a clean $WINEPREFIX. Hence 4 test failures: $ wine dlls/wintrust/tests/wintrust_test.exe.so register register.c:327: Test failed: RegOpenKeyEx failed: 2 register.c:331: Test failed: RegQueryValueEx failed: 6 register.c:334: Test failed: Didn't get expected flags register.c:341: Test failed: Didn't get expected flags register: 43 tests executed (0 marked as todo, 4 failures), 0 skipped. During next run failures are gone, and I get this difference between two registry dumps: +[HKEY_USERS\S-1-5-4\Software\Microsoft\Windows\CurrentVersion\Wintrust] + +[HKEY_USERS\S-1-5-4\Software\Microsoft\Windows\CurrentVersion\Wintrust\Trust Providers] + +[HKEY_USERS\S-1-5-4\Software\Microsoft\Windows\CurrentVersion\Wintrust\Trust Providers\Software Publishing] +"State"=dword:00023c00 So this key should be registered during wineprefix run at some point, right?

2 3

re: Question about tracing a direct pointer call (CryptSIPLoad related)
by Dan Kegel June 5, 2007

June 5, 2007

Hook the function that returns those pointers, and have your hooked function return hooked function pointers. It's not easy, but I think it would work.

1 0

Question about tracing a direct pointer call (CryptSIPLoad related)
by Paul Vriens June 5, 2007

June 5, 2007

Hi, I'm currently (still) busy with trying to find out how certain crypt32/wintrust functions behave. One of the functions CryptSIPLoad returns a set of function pointers that maybe are called directly by an application/dll. These direct calls however don't show up in a 'normal' trace. Is there a way to see this direct pointer call with a trace or do I need to start using the debugger? The problem with tracing/debugging this is that there's a lot of calls from wintrust to crypt32 and back again. This means it's hard to put in any traces as a lot of stuff is still stubbed. It would be nice btw (and I don't know if there's more demand for this) to have a function override instead of the whole dll. I know that could be tricky but in some circumstances would help a lot in tracing/debugging. Cheers, Paul.

1 0

Re: Support for iFilter API
by Juan Lang June 4, 2007

June 4, 2007

Hi Stefan, I finally had a look at this. It looks like filter.h (where the iFilter API is defined) is generated from some IDL source. So you'd want to create your own definition of the .idl file, and generate filter.h using widl. That said, the iFilter interface is only used (in Windows) by the indexing service, which wine currently doesn't implement. So I'm not sure* it really belongs in the wine source. *Caveat: this assumes that wine is mostly about running Windows programs these days, and less about building Windows programs. --Juan ____________________________________________________________________________________ Need Mail bonding? Go to the Yahoo! Mail Q&A for great tips from Yahoo! Answers users. http://answers.yahoo.com/dir/?link=list&sid=396546091

1 0

mandriva rpm wine 0.9.38
by marco June 4, 2007

June 4, 2007

As I have still no way to upload the mandriva wine rpm to the official winehq download server. So mandriva users you can download the latest wine binaries here: http://www.xs4all.nl/~meijer2/wine/ kind regard, Marco

2 1

3DMark2001 crashes with wine-0.9.38
by Juergen Wiezorek June 4, 2007

June 4, 2007

I have just compiled & installed the new wine version on my Fedora Core 5 system (kernel-2.6.20-1.2316-1.fc5) and found that the 3DMark2001 test suite now crashes upon startup, see below enclosure. This has so far never happened with any wine-0.9.x version I've had installed. -- Juergen Wieczorek Hamburg / Germany

2 1