Re: Some notes from wineconf about the 1.4 release -- are we on track?
Scott Ritchie scott at open-vote.org writes: According to Alexandre... 1.4 will be out sometime in 2011 . . . Plus, of course, the general goal of making more applications work :) It seems like we're making serious progress. Have any of these stalled or become less important? Has any new big feature not listed above been done that's worth listing? If I may suggest another thing worth fixing: bug http://bugs.winehq.org/show_bug.cgi?id=18640 This would allow a whole bunch of apps running in wine again. According to Hans' comment here (http://bugs.winehq.org/show_bug.cgi?id=25060#c10) the .Net 3.5 should be able to finish fine as well in current git (haven't tested that yet myself), so by fixing the aforementioned bug we could make a lot of WPF-apps in .Net 3.0 and .Net 3.5 running in wine. ATM Mono is no go for these applications. I also tested a few .Net 4.0 apps in wine recently and most of them also seem to choke in the same bug. I'm not sure how difficult this bug is to fix, but the d3d9 part seems rather easy to fix, not sure how hard the rest of the bug is to solve. Is sometime in 2011 still the best guess for 1.4's release? Thanks, Scott Ritchie
Re: kernel32/tests: remove a few CloseHandle calls on a HMODULE that don't make any sense
Marvin testbot at testbot.winehq.org writes: Full results can be found at http://testbot.winehq.org/JobDetails.pl?Key=12163 Your paranoid android. === WNT4WSSP6 (32 bit module) === module.c:356: Test failed: Expected ERROR_FILE_NOT_FOUND, got 1006 Hi, is there anyone who can tell me why the test now fails in WinNT? Maybe I'm completely off and not understanding the tests for LoadLibraryEx, and the CloseHandle calls _are_ needed? If someone could explain me why they are there that would be great. regards louis
msvcrt: Add tests to show that utime() can take a NULL-pointer for the utimbuf structure field
See http://www.winehq.org/pipermail/wine-patches/2011-April/101371.html Anything i could do to improve to get it in?
ntdll/tests: add tests for NtQueryVolumeInformationFile with FileFsVolumeInformation class
You should take that info from the volume (as it's done now in GetVolumeInformation) instead of hard-coded invalid values. I guess you're right, I wasn't aware of the fact that GetVolumeInformation already does such a job. I'm guessing some of that kernel32 functionality will need to be moved to ntdll. yes, i had a quick look at GetVolumeInformation , seems to me it'll be quite a massive change. maybe someone more familiar with GetVolumeInformation code is more suitable to do this job
Re: dogfood report: Safari runs youtube, firefox doesn't
Dan Kegel dank at kegel.com writes: So I wanted to quickly try youtube in wine to verify sound was working. I think I used to use Firefox for this, so I did sh winetricks firefox flash This is a regression, this used to work a couple of months/ 1 year (?) ago, but it hangs. If someone with a fast computer is bored, plz carry out regression test. (My computer is really getting too slow for this as wine's amount of codelines is growing and growing)
Re:kernel32: Add tests for SetHandleCount + make tests pass for winversions WINNT
It's pretty unlikely that count would be larger than 0x. I agree, but i thought we should mimic Windows-behaviour, and the tests showed that such large values are at least allowed. If this value is too large could you suggest another one? Also I don't think we need a version check. The check is there as the tests show that there is a difference between ver win98 and ver WINNT. I don't know if there a are applications that depend on this difference really. Anyway, i could return something like min(65536,count) for all versions, is that ok? (i'll strip out the tests then, as they won't be passing then anymore)
kernel32: Add tests for SetHandleCount + make tests pass for winversions WINNT
Hi Juan, Since we don't have the same limitation in Wine, applications can call it or not, but it won't have any effect. Hence maintaining a version-dependent external behavior, while not behaving differently internally, doesn't make sense to me. Ok, thanks for the info, then i'll just let it return 'count', that should be ok then for apps that use this function (and fixes the bug for Street Fighter). I'll send a new patch tomorrow.
wine.inf: added .NET InstallRoot key
Dan Kegel dank at kegel.com writes: What is our intent with adding all these registry keys? It seems as if they are helpful for installing mono, but might get in the way of installing MS .net. If that's the intent, do y'all want me to make the dotnet20 winetricks verb remove any registry keys that confuse the dotnet20 installer? I tested dotnet 2.0 and these 2 keys don't harm the installer The only key that causes trouble AFAICT is the already present key [HKEY_LOCAL_MACHINE\Software\Microsoft\NET Framework Setup\NDP\v2.0.50727] Version=2.2.30729 It makes the .NET SP1 installer crash much earlier than it does without this key
[1\4]wined3d: Extend IWineD3D_GetAdapterDisplayMode with an extra paramater to pass back some extra adapter info.
Hi Henri I mean that I don't think the rotation argument to GetAdapterDisplayMode() should be allowed to be NULL. I tested IDirect3D9Ex::GetAdapterDisplayModeEx and that allows pRotation to be NULL, and still happily retrieves all other (D3DDISPLAYMODEEX) info. So it's seems logical IWineD3DGetAdapterDisplayMode is allowed to have it's rotation parameter NULL as well. I attached a new series of patches to the bug http://bugs.winehq.org/show_bug.cgi?id=18640 It probably also makes sense to properly start adding the required support from the bottom. XRandR should be able to retrieve the display rotation, but if that's not available you can just let winex11.drv return an identity rotation. I fear i'm completely unfamiliar with XRandr; i think right now it's beyond the scope of this patch series, the patch series is really meant to (partly) tackle bug 18640
[1\4]wined3d: Extend IWineD3D_GetAdapterDisplayMode with an extra paramater to pass back some extra adapter info.
Hi Henri I mean that I don't think the rotation argument to GetAdapterDisplayMode() should be allowed to be NULL. I tested IDirect3D9Ex::GetAdapterDisplayModeEx and that allows pRotation to be NULL, hmm, I remembered to have tested this, but to be sure I tested again a few minutes ago, and looks you were right in the end. I guess i'll have to rework the patch series again. sorry for the noise
[1\4]wined3d: Extend IWineD3D_GetAdapterDisplayMode with an extra paramater to pass back some extra adapter info.
ok, now i really need a break, the test i wrote 10 minutes ago had a mistake, IDirect3D9Ex::GetAdapterDisplayModeEx _does_ allow D3DDISPLAYROTATION pointer to be NULL. I'll just send the test to wine-patches. Again sorry for the noise
[1\4]wined3d: Extend IWineD3D_GetAdapterDisplayMode with an extra paramater to pass back some extra adapter info. Henri Verbeet hverbeet at gmail.com
Hi, @Chris: thanks for the remarks, i'll adjust patch [3\4] accordingly @Henry also thanks, i made a new patch here: http://pastebin.com/y5Kv52h0 would that be ok? I also think the wined3d call should simply retrieve all info, d3d9ex can discard it again if it feels like it. I don't exactly get what you mean here. Currently we can't retrieve display orientation as wine's EnumDisplaySettingsExW doesn't work as expected. Once EnumDisplaySettingsExW is implemented enough (for rotated stuff), IWineD3DImpl_GetAdapterDisplayMode will pass back the correct display orientation. Is that what you meant by remark above? Regards
Re: d3d9: add a few tests for GetAdapterDisplayModeEx
On 7 July 2010 23:39, Louis Lenders xerox_xerox2000 at yahoo.co.uk wrote: +todo_wine ok(mode_ex.ScanLineOrdering == D3DSCANLINEORDERING_PROGRESSIVE, ScanLineOrdering is %d instead of %d\n, mode_ex.ScanLineOrdering, D3DSCANLINEORDERING_PROGRESSIVE); +todo_wine ok(rotation == D3DDISPLAYROTATION_IDENTITY, rotation is %d instead of %d\n, rotation, D3DDISPLAYROTATION_IDENTITY); These obviously depend on the actual setup of the machine running the test. yeah, you have a suggestion how to change the test, or should i just leave them out of the test? It also seems likely that you're supposed to initialize mode_ex.Size before making the GetAdapterDisplayModeEx() call. I did that in the test: test shows that it fails if mode_ex.Size is null, when it is set to sizeof(D3DDISPLAYMODEEX) it returns D3D_OK
Re: make quot;bisectedquot; a keyword in bugzilla?
Nikolay Sivov nsivov at codeweavers.com writes: I believe developer's attention doesn't depend on bug state (confirmed/uncofirmed) at all. I'm not sure about that, my experience is that some developers do care about regressions and some don't (actually i think that they missed the bug reports where the regressions are reported) . It would help at least that if those who don't, drop a little message that they saw the bugreport and are aware of the regression they caused ( or if their patch just was correct, and just revealed another wine-bug, add that information) Actually a regression keyword supposes to mean exactly the same. I don't agree about that, regression means the app doesn't work anymore, that could also be because of a distro-upgrade or a mis-configured system at the user side. Bisected means someone with same system+distro has pinpointed the exact patch that caused trouble. So this should have top-priority for wine-devs to look at, if wine wants to get mature.
Re: Mono integration
The compatibility information basically indicates that Mono can substitute for .NET below version 3.0. 3.0 and higher still needs Microsoft's implementation. How would you handle hybridizing Mono with Microsoft's framework? You would need different wine prefixes if you want to use both at once. What is the problem with 3.0, and can't it be fixed? AFAIK mono doesn't implement WPF, so any .NET app that uses it is likely to fail in mono. Correct me if i'm wrong Vincent Povirk madewokherd+8cd9 at gmail.com writes:
Re: New winetricks 20091125: new verbs ie7, alsa, fbo, pbuffer, ...
Dan Kegel dank at kegel.com writes: Pie's in the oven, time for another winetricks release. Could it be possible to fix mdac as well? Because of wine now having a more or less stubbed oledb32.dll, apps that need mdac don't run properly anymore. Simple solution is to set oledb32 to native, before the mdac installer is started, (and leave it to native afterwards) Could that be added to winetricks?
mapistub: add stubbed dll mapistub.dll
I guess we can forward those functions to mapi32 later on. While running the app, no functions were called at all, it was even enough to copy a random dll into system32 , and call it mapistub.dll. That was enough to get the app going
Re: kernel32/tests: add more tests for Formatmessage{A,W} (try 2)
Hi Louis, These new tests introduce some test failures on several platforms: http://test.winehq.org/data/tests/kernel32:format_msg.html On Win9x/WinMe it seems like just another last error. There seems to be an issue with a particular test when run on a Windows box with no English locale (or something different about the locale): http://test.winehq.org/data/1be99033b1892aa59589e7997f4c5a0ce77e2b42/2000_w2k-sp4-fr/kernel32:format_msg.html On Vista/Win7/W2K8 there are also different last errors but some are not yet defined in our headers: 15100 : ERROR_MUI_FILE_NOT_FOUND 15105 : ERROR_MUI_FILE_NOT_LOADED Could you have a look? I'll have a look , but probably not today, but in weekend. Regards
kernel32: add more tests for FormatMessage{A,W}
A couple of suggestions: 1. There is no point in testing last error if an API didn't fail Couldn't it be that the API sets ERROR_SUCCES if it doesn't fail? 2. It would be helpful to simultaneously test return values and last error for FindResource, which should have similar behaviour (and the bug) to FormatMessage Could you explain a bit more what exactly to test? I can load the whole messagetable with FindResource from kernel32, but that always succeeds of course. Using the MESSAGE_RESOURCE_BLOCK and MESSAGE_RESOURCE_ENTRY structures I could I load a messagestring I guess, but that doesn't test the behaviour of FindResource anymore. Or do i see things wrong here? Trying to load a non existing messagetable from another dll with FindResource gives ERROR_RESOURCE_TYPE_NOT_FOUND. Or is that not what you meant? and drop FormatMessageW tests. Ok i'll do that
kernel32: add more tests for FormatMessage{A,W}
FormatMessage uses the same backend to find the requested resource as FindResource does, so I'd guess that they both fail in the same way when a resource id or a language does not exist in the module. Parsing an actual resource data is not necessary. ok, but isn't that test already in tests/resource.c? See code snippet below: Or do i get it wrong? rsrc = FindResourceExW( GetModuleHandle(0), (LPCWSTR)RT_MENU, (LPCWSTR)MAKEINTRESOURCE(1), MAKELANGID( LANG_NEUTRAL, SUBLANG_NEUTRAL )); ok( rsrc != 0, resource not found\n ); rsrc = FindResourceExW( GetModuleHandle(0), (LPCWSTR)RT_MENU, (LPCWSTR)MAKEINTRESOURCE(1), MAKELANGID( LANG_GERMAN, SUBLANG_DEFAULT )); ok( rsrc != 0, resource not found\n ); SetLastError( 0xdeadbeef ); rsrc = FindResourceW( GetModuleHandle(0), (LPCWSTR)MAKEINTRESOURCE(1), (LPCWSTR)RT_DIALOG ); ok( !rsrc, resource found\n ); ok( GetLastError() == ERROR_RESOURCE_TYPE_NOT_FOUND, wrong error %u\n, GetLastError() ); SetLastError( 0xdeadbeef ); rsrc = FindResourceW( GetModuleHandle(0), (LPCWSTR)MAKEINTRESOURCE(2), (LPCWSTR)RT_MENU ); ok( !rsrc, resource found\n ); ok( GetLastError() == ERROR_RESOURCE_NAME_NOT_FOUND, wrong error %u\n, GetLastError() ); SetLastError( 0xdeadbeef ); rsrc = FindResourceExW( GetModuleHandle(0), (LPCWSTR)RT_MENU, (LPCWSTR)MAKEINTRESOURCE(1), MAKELANGID( LANG_ENGLISH, SUBLANG_DEFAULT ) ); ok( !rsrc, resource found\n ); ok( GetLastError() == ERROR_RESOURCE_LANG_NOT_FOUND, wrong error %u\n, GetLastError() ); SetLastError( 0xdeadbeef ); rsrc = FindResourceExW( GetModuleHandle(0), (LPCWSTR)RT_MENU, (LPCWSTR)MAKEINTRESOURCE(1), MAKELANGID( LANG_FRENCH, SUBLANG_DEFAULT ) ); ok( !rsrc, resource found\n ); ok( GetLastError() == ERROR_RESOURCE_LANG_NOT_FOUND, wrong error %u\n, GetLastError() ); }
kernel32: add more tests for FormatMessage{A,W}
FormatMessage uses the same backend to find the requested resource as FindResource does, so I'd guess that they both fail in the same way when a resource id or a language does not exist in the module. I still fail to see how I can call FindResource for a missing message-id. In the end they both use LdrFindResource_U but I guess that's not what you meant to test. I still have tthe problem to first load the messagetable with FindResource, and I cannot use a call to FindResource to ask for a present or missing message-id. I'll resend the patch with your other two suggenstions, if the patch is not accepted i'll leave it to someone else (more experienced) to take this up
test {IDirect3DTexture8, IDirect3DSurface8}::UnlockRect for rectangles that are not locked
Stefan Dösinger stefan at codeweavers.com writes: Do I read this correctly that a double unlockrect call on a surface fails, while a double unlockrect call on a texture succeeds? Yes Here are some more test suggestions: - Create a texture, retrieve its surface, and call LockRect/ UnlockRect on the surface. Does this show the surface or texture behavior - What happens if you have a texture, retrieve a surface and mix locks on the surface and texture? I'll see if I can fix something together later on this week - What is the d3d9 behavior? Test follows, was about to send
Re: oleaut - SysAllocString/SysFreeString
Markus Stockhausen markus.stockhausen at collogia.de writes: Hi, maybe this topic has discussed before but I did not find any threads in the devel mailing list for the last months. Not sure, but maybe you could find some interesting related stuff in this bug:http://bugs.winehq.org/show_bug.cgi?id=3756
shdocvw: would it be allright to pretend succes in IWebBrowser2::Stop?
Hi, i try run an app that bails out because WebBrowser_Stop returns E_NOTIMPL. Just like another app i already filed a bug for (http://bugs.winehq.org/show_bug.cgi?id=9895) it expects ERROR_SUCCESS. According to MSDN this function Cancels a pending navigation or download, and stops dynamic page elements, such as background sounds and animations. My question is, would it be ok to just pretend ERROR_SUCCESS (as i think now), or would there be any unwanted side effects for other apps that use this function,and do we have to wait for a real implementation (maybe Jacek has a clue?) Regards Louis
Re: Trying buildbot on wine; foiled by distutils expecting mscoree to be resident?
so I tried doing
wine pywin32-212.win32-py2.6.exe
first. This fails immediately as described in
http://bugs.winehq.org/show_bug.cgi?id=13844
It seems to terminate because it tries to get
a handle to the loaded copy of mscoree.dll
and fails (because there isn't one).
The installer seems to have been created by python's distutils.
Mark Hammond seems to be well aware of low level
issues that affect the installer, see e.g.
http://bugs.python.org/issue5075
so perhaps he could explain why the installer expects
mscoree.dll to be resident...
This is explained here: http://bugs.winehq.org/show_bug.cgi?id=6880#c7 (I guess
it's the same issue)
Copy and paste:
--- snip ---
I've seen quite some applications that fail in the end like this one:
0009:Call kernel32.GetModuleHandleA(011bf1d4 mscoree.dll) ret=00c5936f
0009:Ret kernel32.GetModuleHandleA() retval= ret=00c5936f
Then ExitProcess.
--- snip ---
This has nothing to do with this bug.
The application uses dynamic msvc 7.1 runtime, which implicitly pulls
mscoree.dll in.
Normally mscrt __crtExitProcess() calls just ExitProcess() but on newer versions
a call to __crtCorExitProcess() is made to ensure proper shutdown of managed
parts (even if you don't use managed = .NET code).
CorExitProcess() basically does this:
--- snip ---
hModule = GetModuleHandle(mscoree.dll);
if (hModule != NULL)
{
pfn = (PFN_EXIT_PROCESS) GetProcAddress( hModule, CorExitProcess);
if (pfn != NULL)
pfn(status);
}
--- snip ---
If mscoree module or the export is not found it causes no harm.
It works as designed.
The reason for this additional (implicit) shutdown code is you have no control
whether a part of operation system or application dll (3rd party/injected) might
pull in managed stuff thats why this code exists.
Regards
Re: Fixing AppDB once and for all
Zachary Goldberg zgold at bluesata.com writes: All, So it seems to be almost every other day now when somebody mentions how broken the appdb rating system is. This broken-ness has had several high level discussions on Wine-Devel. There have also been many, many proposed solutions to this problem. I do not wish to discuss these problems or these solutions in this thread. It is time something was done about this. By done I mean agreed upon (probably the harder part) then implemented in code and published to the winehq server(s). I'de like to arrange an IRC discussion for all those interested in finalizing an attack plan, and then assigning the responsibility of doing it to somebody who is capable and has the time (perhaps myself). Lets (arbitrarily) set a time for the chat at: When: 11PM UTC (6PM EST) 2/6/09 (Friday) Where: #winehackers I think this will be a very difficult if not impossible task to accomplish. If we talk about test results, it's the app maintainer that is responsible for the correctness of the ratings and test results. What would you want to do if you think that the ratings for application X are overestimated? Remove the maintainer from the application entry in appdb? Then you'd have to check yourself for every app, if ratings are correct. BTW, also the opposite occurs very frequently: applications that are rated too low (garbage) whereas they are probably bronze or higher. When users send in garbage test results, i'm always tempted to try out the app myself if it has free download. In many cases it appears the application needs additional packages like mdac, vbrun or anything. Also many garbage results come from installing in a busted wineprefix ( just do a winetricks dcom98, and you'll get garbage results for apps in many cases), and they run just fine in a new ~/.wine So if someone shouts: Hey, the app is rated gold, but for me it crashes it's not necessarily the gold-rater who's wrong. My conclusion really is, it's very difficult to get the ratings correct, but always worth a try of course. What's more important is I think , that the appdb is rich source of info on how to get application X or Y running. Regards So my conclusion is it will be very difficult to get
Re: Running a simple .Net 3.0 application.
Are you sure that wine's d3d9 is available? (e.g. missing opengl libs on your linux system?) the GdiEntry13 stub sounds a bit like it tried to use native d3d9.dll, which doesn't work on Wine(and most likely never will) Yes i'm sure, as the biggest problem that prevented the app from running was apparently in IDirect3D9ExImpl_EnumAdapterModesEx; the app crashed right after the fixme for that function was printed. Disabling d3d9 got it futher. As for GdiEntry13: it's documented on http://msdn.microsoft.com/en-us/library/ms648442(VS.85).aspx (see GdiEntry13 is #defined as an alias for this function) Apparently it is called from some kind of dll from the .net framework. (ps.to James:for clarity, i didn't have to do anything nasty to get the app running (and i even lack those capabilities ;) ) : all unimplmented functions are documented on msdn, so it ;s just a matter of returning some obvious return value. The only function that seems undocumented is NtSecureConnectPort, but fortunately that can be found in wine's include/winternl.h)
Running a simple .Net 3.0 application.
I saw some good progress is being made on getting the .net 3.0 installer fixed in wine. Nice. As it will take yet quite some time until the installer is fixed, i wondered if wine is in good shape to run .net 3.0 apps, once the installer is finished. Today I saw someone mentioning a program called InstallRite on the users-list, and using this program, I was able to get a a simple .Net 3.0 app running in wine. I thought just share my experience here, in case anyone finds it useful. The application i got running is very simple: AnimatedApplication from http://www.longhorncorner.com/UploadFile/rahul4_saxena/AnAnimatedApplication07112007042303AM/AnAnimatedApplication.aspx (You just need register, then you can download the file) This way I got it running: 1. Fire up Windows Xp (a snapshot from a clean install) in my VirtualBox 2. Install Installrite from http://www.epsilonsquared.com/ in VirtualBox. 3. Start InstallRite, and from within InstallRite you can fire up the dotnetfx3.exe (after downloaded it) 4. After the dotnetfx3.exe finshed the install, there's an option, that you can make a Build Install Kit. I did that, it creates an executable (foo.exe). Save it in a place where you can access it from linux 5. In wine, first do 'winetricks dotnet20' (needed for l_int.nls i guess, otherwise I got crash very early in the app) 6. Run foo.exe in wine, it will extract all files, and write all registry-keys, as if it were a successfull dotnetfx3 installation in wine. 7. Now Run the app, it crashes into a bunch of unimplemented functions. Fortunately just simple stubs were enough to make the app happy. I added stubs for gdi32.GdiEntry13 kernel32.WerRegisterMemoryBlock ntdll.NtSecureConnectPort ntdll.RtlEnumerateGenericTableWithoutSplaying ntdll.RtlIsGenericTableEmpty Well, that was enough to get the app running. I was not able to work around a problem in d3d9 ( the app just hang, displaying nothing, probably due to some unimplemented stuff in d3d9) but fortunaly disabling d3d9, was enough to get it running (WINEDLLOVERRIDES=d3d9= wine AnimatedApplication.exe) I'm not sure if it would be useful to open bugs already for the unimplemented functions. If so, just shout, and i'll open some bugs. Conclusion: once the installer is fixed, there's good chance simple .net 3.0 at least apps will run quickly
Re: Implementing dxdiag as student project?
Chris Robinson chris.kcat at gmail.com writes: I think such a thing could still be useful. It'll help figure out what kind of info apps are getting from a given system, and help determine if problems are app-specific or more general system/wine-related. It can also serve as a basic interactive test bed for various DX functionality that even users can run and look at, instead of being delegated to the wine test suite only. Plus it can check DirectPlay and DirectSound (a couple other components prone to errors), instead of just Direct3D/DirectDraw. Wine needs a dxdiag.exe as some apps expect it to be present, like for example GameShadow. I once gave it a shot already, see http://bugs.winehq.org/show_bug.cgi?id=14118. A builtin dxdiag.exe would aslo be nice addition to wine imo.
Re: shell32: FOF_MULTIDESTFILES must be set when copying files into directory
Thank you for your answer. I agree, that before sending a patch I should write a test first. But the problem is that even a tests are ignored without any explanation. Maybe my tests aren't good, but why anybody just tell what's wrong. Seems to be common habit on this list. I hope you're not added to the Julliard ranking s**t list? Yes: REJECT ( see http://www.winehq.org/?issue=353#WineConf%202008%20Keynote ) like i am. Spent loads of time for more than 3 years trying to help triaging bugs and helping out in appdb, only to find out that all my patches are ignored silently, but everybody seems to be happy with this policy, so i'll stop complaining. Personally this makes me quite sad. Hope you have more luck with your patches. Have you tried asking on the #winehackers IRC channel? No, I doesn't use IRC. It's very hard to me to write in english in real-time If people spent quite an amount of time trying to get a patch written, it shouldn't be too much trouble to just drop a note on wine-devel, what the reason is the patch got rejected. But i guess this takes more time then the few seconds to see that the code is correct? If today is a busy day: IGNORE Great feedback... Ok, I try to resend my old tests, and write tests to other patches. Also there are some functions and stubs implemented, wchich doesn't require (as I think) a tests. Send instant messages to your online friends http://uk.messenger.yahoo.com Send instant messages to your online friends http://uk.messenger.yahoo.com
Re: mapi32: initialize session pointer to zero in MAPILogonEx (2nd resend)
diff --git a/dlls/mapi32/mapi32_main.c b/dlls/mapi32/mapi32_main.c
index 936d435..5aace9a 100644
--- a/dlls/mapi32/mapi32_main.c
+++ b/dlls/mapi32/mapi32_main.c
@@ -109,6 +109,7 @@ HRESULT WINAPI MAPILogonEx(ULONG_PTR uiparam,
LPWSTR profile,
{
FIXME((0x%08lx %s %p 0x%08x %p) Stub\n, uiparam,
debugstr_w(profile), password, flags, session);
+*session=0;
return SUCCESS_SUCCESS;
}
Are you guaranteed that session is not NULL?
No, no garantueed, but i looked up some code-samples by google, and as
far as i can tell, the current stub for MAPILogonEx will pass back garbage
anyway to the application, so my thought was this patch would be rather
harmless anyway.
A test case would help.
I guess you're right about that, thanks anyway for the comments.
--Juan
Re: mapi32: initialize session pointer to zero in MAPILogonEx (2nd resend)
- Original Message
From: Juan Lang [EMAIL PROTECTED]
To: Louis Lenders [EMAIL PROTECTED]
Cc: wine-devel@winehq.org
Sent: Monday, 6 October, 2008 13:36:52
Subject: Re: mapi32: initialize session pointer to zero in MAPILogonEx (2nd
resend)
diff --git a/dlls/mapi32/mapi32_main.c b/dlls/mapi32/mapi32_main.c
index 936d435..5aace9a 100644
--- a/dlls/mapi32/mapi32_main.c
+++ b/dlls/mapi32/mapi32_main.c
@@ -109,6 +109,7 @@ HRESULT WINAPI MAPILogonEx(ULONG_PTR uiparam,
LPWSTR profile,
{
FIXME((0x%08lx %s %p 0x%08x %p) Stub\n, uiparam,
debugstr_w(profile), password, flags, session);
+*session=0;
return SUCCESS_SUCCESS;
}
The rest of the file uses ' = 0', so please stay consistent.
Also, the indenting is inconsistent: the function uses 2-space
indenting, whereas your change uses 4-space indenting. Please match
the file's existing style.
--Juan
Sorry , i don't understand what you mean with that comment above. When i apply
the patch i get the code below:
HRESULT WINAPI MAPILogonEx(ULONG_PTR uiparam, LPWSTR profile,
LPWSTR password, ULONG flags, LPMAPISESSION *session)
{
FIXME((0x%08lx %s %p 0x%08x %p) Stub\n, uiparam,
debugstr_w(profile), password, flags, session);
*session=0;
return SUCCESS_SUCCESS;
}
I don't see any 2-space nor 4-space indention introduced by this patch. I'll
try to be more consistent with all this space-thing stuff, but is it now
policy to reject patches because of missing/too much spaces? I'm just trying to
fix a bug you know...
I'll resend this patch, as for the other patch, i sent it in 5 times already, 2
times because of changing stylish things i was requested, then 3 times resend
because it was not applied and i didn't receive any comments anymore about it.
I don't think it's good idea to spam the list with just another resend, if
there's another reason why it was rejected i'd be happy to know about it
Re: howto fix bug 13462
Rob Shearman robertshearman at gmail.com writes: Thanks very much for your comments Rob, I've updated the patch here: http://bugs.winehq.org/attachment.cgi?id=16397 Hopefully correct now? But now got another problem with the test, i changed it a bit like here: http://bugs.winehq.org/attachment.cgi?id=16430 This test passes fine in Xp, but not in wine, more specific, this part fails: pCoInitializeEx(NULL, COINIT_APARTMENTTHREADED); . . . . if(hr == S_OK) refs = IContextCallback_Release(pComThreadingInfo); ok(refs == 0, pComThreadingInfo should have 0 refs instead of %d refs\n, refs); In windows it shows the refcount should be zero in the end, but with my patch and this test, it doesn't (refcount =2 in the end). I added several traces to the code to show how the refcount was in/decreased, but wasn't able to figure out what goes wrong, it's quite mysterious. Whereas this test fails, the one that starts with pCoInitializeEx(NULL, COINIT_MULTITHREADED) passes just fine in wine. Am i still missing something?
Re: howto fix bug 13462
Rob Shearman robertshearman at gmail.com writes:
Hi Rob, i think i got the test ready now, i'll send it when the defenitions are
in place in ctxtcall.idl. Now still strugling how to fix the bug.
I fixed up the patch below, also by looking how things are done in similar
places in wine-code. With patch applied I can see that
ContextCallback_ContextCallback and ContextCallback_Release are called from the
application (tested with NASA WorldWind), and the simple stubs are enough to let
the app continue fine. But i'm not sure if everything is 100% ok. Is this what
you more or less meant in your first comment?
diff --git a/dlls/ole32/compobj.c b/dlls/ole32/compobj.c
index 37907ec..a1f41fd 100644
--- a/dlls/ole32/compobj.c
+++ b/dlls/ole32/compobj.c
@@ -55,6 +55,7 @@
#include objbase.h
#include ole2.h
#include ole2ver.h
+#include ctxtcall.h
#include compobj_private.h
@@ -3615,25 +3616,39 @@ HRESULT WINAPI CoRegisterChannelHook(REFGUID
guidExtension, IChannelHook *pChann
typedef struct Context
{
const IComThreadingInfoVtbl *lpVtbl;
+const IContextCallback *lpVtblIContextCallback;
LONG refs;
APTTYPE apttype;
} Context;
+static inline Context *impl_from_Context(IComThreadingInfo *iface)
+{
+return (Context *)((char*)iface - FIELD_OFFSET(Context, lpVtbl));
+}
+
static HRESULT WINAPI Context_QueryInterface(IComThreadingInfo *iface, REFIID
riid, LPVOID *ppv)
{
+Context* This=impl_from_Context((IComThreadingInfo*) iface);
*ppv = NULL;
if (IsEqualIID(riid, IID_IComThreadingInfo) ||
IsEqualIID(riid, IID_IUnknown))
{
*ppv = iface;
-IUnknown_AddRef(iface);
-return S_OK;
}
+else if(IsEqualIID(riid, IID_IContextCallback))
+{
+*ppv = This-lpVtblIContextCallback;
+}
+else
+{
+FIXME(interface not implemented %s\n, debugstr_guid(riid));
+return E_NOINTERFACE;
+}
-FIXME(interface not implemented %s\n, debugstr_guid(riid));
-return E_NOINTERFACE;
-}
+IUnknown_AddRef(iface);
+return S_OK;
+}
static ULONG WINAPI Context_AddRef(IComThreadingInfo *iface)
{
@@ -3691,6 +3706,31 @@ static HRESULT WINAPI
Context_SetCurrentLogicalThreadId(IComThreadingInfo *iface
return E_NOTIMPL;
}
+
+static HRESULT WINAPI ContextCallback_QueryInterface(IContextCallback *iface,
REFIID riid, LPVOID *ppv)
+{
+FIXME(\n);
+return E_NOTIMPL;
+}
+
+static ULONG WINAPI ContextCallback_AddRef(IContextCallback *iface)
+{
+FIXME(\n);
+return E_NOTIMPL;
+}
+
+static ULONG WINAPI ContextCallback_Release(IContextCallback *iface)
+{
+FIXME(\n);
+return E_NOTIMPL;
+}
+
+static HRESULT WINAPI ContextCallback_ContextCallback(IContextCallback *iface,
PFNCONTEXTCALL pfnCallback, ComCallData* pParam, REFIID riid, int iMethod,
IUnknown* pUnk)
+{
+FIXME(not implemented yet\n);
+return E_NOTIMPL;
+}
+
static const IComThreadingInfoVtbl Context_Threading_Vtbl =
{
Context_QueryInterface,
@@ -3702,6 +3742,14 @@ static const IComThreadingInfoVtbl
Context_Threading_Vtbl =
Context_SetCurrentLogicalThreadId
};
+static const IContextCallbackVtbl Context_Callback_Vtbl =
+{
+ContextCallback_QueryInterface,
+ContextCallback_AddRef,
+ContextCallback_Release,
+ContextCallback_ContextCallback
+};
+
/***
* CoGetObjectContext [EMAIL PROTECTED]
*
@@ -3735,6 +3783,7 @@ HRESULT WINAPI CoGetObjectContext(REFIID riid, void **ppv)
return E_OUTOFMEMORY;
context-lpVtbl = Context_Threading_Vtbl;
+context-lpVtblIContextCallback=(IContextCallback*)Context_Callback_Vtbl;
context-refs = 1;
if (apt-multi_threaded)
context-apttype = APTTYPE_MTA;
Re: howto fix bug 13462
Rob Shearman robertshearman at gmail.com writes:
2008/9/15 Louis Lenders xerox_xerox2000 at yahoo.co.uk:
Rob Shearman robertshearman at gmail.com writes:
I suggest you write a test case that replicates what the
application does and either send it to wine-patches
with appropriate todo_wine's or attach it to the bug.
Well, it looks like the app is only checking if the uuid of the
interface is defined using Context_QueryInterface,
and that's about it.
It doesn't really seem to try to use anything from it, as
Erich's initial hack is already enough to get the apps running as
well (this one:http://bugs.winehq.org/attachment.cgi?id=13379)
That's fine. You can still add a test that does the same
as what the app does.
Hi, as there isn't really much activity in the bug
(understatement haha) i tried to hack up a test myself.
Rob, is the test below more or less what you meant?
or am i way off...
(The test passes on winxp, and fails in wine, so afaics shows we
should support the interface )
diff --git a/dlls/ole32/tests/compobj.c b/dlls/ole32/tests/compobj.c
index bdc34d9...49c3276 100644
--- a/dlls/ole32/tests/compobj.c
+++ b/dlls/ole32/tests/compobj.c
@@ -28,6 +28,7 @@
#include objbase.h
#include shlguid..h
#include urlmon.h /* for CLSID_FileProtocol */
+//#include ctxtcall.h
#include wine/test.h
@@ -61,6 +62,15 @@ static const IID IID_IWineTest =
0x4fd0,
{0xa1, 0xa2, 0x5d, 0x5a, 0x36, 0x54, 0xd3, 0xbd}
}; /* 5201163f-8164-4fd0-a1a2-5d5a3654d3bd */
+
+static const IID IID_IContextCallback =
+{
+0x01da ,
+0x,
+0x,
+{0xc0, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x46 }
+};
+
static const CLSID CLSID_WineOOPTest = {
0x5201163f,
0x8164,
@@ -1022,6 +1032,26 @@ static void test_CoGetObjectContext(void)
CoUninitialize();
}
+static void test_ContextCallBack(void)
+{
+
+HRESULT hr;
+IComThreadingInfo *pComThreadingInfo;
+
+if (!pCoGetObjectContext)
+{
+skip(CoGetObjectContext not present\n);
+return;
+}
+
+pCoInitializeEx(NULL, COINIT_APARTMENTTHREADED);
+
+hr = pCoGetObjectContext(IID_IContextCallback, (void
**)pComThreadingInfo);
+
+ok_ole_success(hr, CoGetObjectContext);
+CoUninitialize();
+}
+
START_TEST(compobj)
{
HMODULE hOle32 = GetModuleHandle(ole32);
@@ -1050,4 +1080,5 @@ START_TEST(compobj)
test_registered_object_thread_affinity();
test_CoFreeUnusedLibraries();
test_CoGetObjectContext();
+test_ContextCallBack();
}
Re: howto fix bug 13462
+//#include ctxtcall.h Please resend the patch adding the IDL file for this generated file and get it in before sending this patch adding the tests. Hi Rob, thanks very much for the comments. I'll do the above , but i have problems when I uncomment the above include, i get: compobj.c:(.text+0x394b): undefined reference to `IID_IContextCallback' /usr/bin/ld: compobj.o: relocation R_386_GOTOFF against undefined hidden symbol `IID_IContextCallback' can not be used when making a shared object /usr/bin/ld: final link failed: Bad value collect2: ld returned 1 exit status winegcc: gcc failed make[2]: *** [ole32_test.exe.so] Error 2 Adding the two lines below #define INITGUID #include guiddef.h fixes the compiler error, but i have the feeling something is wrong with my setup or so, or is this a normal error?
Re: msi: add stub for MsiDetermineApplicablePatchesW
- Original Message From: James Hawkins [EMAIL PROTECTED] The vast majority of this file does not put spaces around parenthesis, so can you resend with that fixed? well, the last functions from that file do put the spaces around them, but if you prefer otherwise, i'll resend it Also, why don't you add MsiDetermineApplicablePatchesA at the same time? i tried to keep patch as small as possible, and this is enough to fix the bug, but i'll add the A-version along the way in the resend. James Hawkins
Re: wine.inf.in: create default key App Paths (and key for IEXPLORE)
- Original Message From: Alexandre Julliard [EMAIL PROTECTED] Louis. Lenders [EMAIL PROTECTED] writes: Hi, the key HKLM//Software\\Microsoft\\Windows\\CurrentVersion\\App Paths is needed by LexWare installer (bug http://bugs.winehq.org/show_bug.cgi?id=15347) This patch creates that key by default, but also creates the key for IEXPLORE along the way, needed to fix http://bugs.winehq.org/show_bug.cgi?id=7257. The key is present on a default winxp installation btw, was there anything wrong with this patch: http://www.winehq.org/pipermail/wine-patches/attachments/20080918/e269df3c/attachment.txt ? Yes, it doesn't match the Windows definitions. And this patch doesn't either. You really need to pay more attention to what you are doing. honestly, i'm trying to be as careful as i can. But I see an extra semi-colon crawled in in the patch for the registry key for App Paths. Is that what you meant with 'doesn't match Windows definitions'? Or is there something more wrong? As for the patch for MsiSetExternalUIRecord , i compared again with de definition at http://msdn.microsoft.com/en-us/library/aa370385(VS.85).aspx, but i don't see a problem there. Also i matched the definition for InstalluiHandlerRecord to the definition of InstalluiHandler in wine's msi.h, as that seemed more consistent to me. I'm happy to fix up any patch , if only i knew what was wrong with them... louis
Re: howto fix bug 13462
Rob Shearman robertshearman at gmail.com writes: That's not acceptable as that change will cause applications that do use the returned interface to either crash on a NULL pointer (if you set *ppv to NULL and return S_OK) or stack corruption (if you return a pointer to the wrong interface). You will be turning a known unimplemented feature into a buggy feature which will be harder to fix later. So what now? If running the tests on Windows show that the interface in question is implemented for the Context object then add that interface to the object with stubbed functions. Hi Rob, thanks for the reply. I'll add your comments to the bug report. As for fixing the bug + the tests myself, i guess i have to learn a lot more about this stuff, but maybe someone (with more knowledge on this matter) can use your hints to get the bug fixed. Regards
Re: user32: fix error setting in FindWindow (try 2)
- Original Message From: Alexandre Julliard [EMAIL PROTECTED] To: Louis. Lenders [EMAIL PROTECTED] Cc: wine-devel@winehq.org Sent: Friday, 22 August, 2008 4:54:49 AM Subject: Re: user32: fix error setting in FindWindow (try 2) Louis. Lenders [EMAIL PROTECTED] writes: diff --git a/dlls/user32/tests/win.c b/dlls/user32/tests/win.c index 1964e88..246347f 100644 --- a/dlls/user32/tests/win.c +++ b/dlls/user32/tests/win.c @@ -4789,14 +4789,20 @@ static void test_hwnd_message(void) SetLastError(0xdeadbeef); found = FindWindowExA( GetDesktopWindow(), 0, 0, message window ); ok( found == 0, found message window %p/%p\n, found, hwnd ); -todo_wine -ok(GetLastError() == ERROR_FILE_NOT_FOUND, ERROR_FILE_NOT_FOUND, got %d\n, GetLastError()); +ok(GetLastError() == ERROR_FILE_NOT_FOUND, ERROR_FILE_NOT_FOUND, got %d\n, GetLastError()); Have you tried your test on Windows? According to the test results there isn't any Windows version that sets last error here. If you're talking about the test above, that was a test written by someone else, i think it was committed on wednesday or so. I only take out the todo_wine there; i assumed that test passed on windows, as the patch was committed, but i now see on the test results page that it doesn't. I did run the test on windows yesterday , the whole console got spammed with lots of messages, and i guess i overlooked something then ( i now see on the testpage that the failing test appears in the first lines of the spam, i only overlooked the last part in the console as i expected an eventually failing test there) As FindWindowEx apparently doesn't set an error, I'll have to recheck what FindWindow does on windows Send instant messages to your online friends http://uk.messenger.yahoo.com
patches
Hi, apparently none of my patches is making it into git, nor did i recieve any response from Alexandre about what's wrong with them. I guess i'm kind of blacklisted because of my dxdiag patch from a few months ago, where i took some code from a directX tutorial ( i thought tutorials were free code, well they aren't apparently). Anyway, there are i think some patches that contain useful things to fix some bugs, so if anyone would like to pick them up, feel free (espesially the fix for the google lively download) (@Alexandre: this is not a request from me to explain why the patches have been rejected. I don't want to be pissed off again by you like in your last mail; I may be a crappy coder, but i've been helping wine-users for a few years now, so i think i deserved a little more respect , than was reflected by that mail) Send instant messages to your online friends http://uk.messenger.yahoo.com
Re:activeds: add stub for ADsGetLastError
Thanks for reviewing the patch James
@@ -6,7 +6,7 @@
8 stub ADsBuildVarArrayInt
9 stdcall ADsOpenObject(wstr wstr wstr long ptr ptr)
12 stub ADsSetLastError
-13 stub ADsGetLastError
+13 stdcall ADsGetLastError(ptr wstr long wstr long)
Both of those wstr parameters are out pointers so they should be ptr, not wstr.
Didn't know that, so that has to be changed for sure
/*
+ * ADsGetLastError[ACTIVEDS.13]
+ */
+HRESULT WINAPI ADsGetLastError(LPDWORD pError, LPWSTR buffer, DWORD
buflen, LPWSTR bufname, DWORD bufnamelen)
+{
+FIXME((%p,%p,%d,%p,%d)stub\n, pError, buffer, buflen, bufname,
bufnamelen);
+return E_POINTER;
+}
Returning E_POINTER seems pretty wrong.
In the documentation on
http://msdn.microsoft.com/en-us/library/aa772183(VS.85).aspx
it is listed as one of the possible return values. Of course one could also
return E_NOTIMPL or E_FAIL etc, but for a stub this seemed like a good choice
to me as well, the application (Dameware) doesn't seem to bother what is
returned, it starts up just fine
Send instant messages to your online friends http://uk.messenger.yahoo.com
Re:shobjidl.idl: add Taskbarlist interface defenitions
The I'll send the rest later is a warning light. You should further develop this and send it all later so we know this is actually going somewhere. The whole patch, that lets Governor of Poker start i have attached to the bug http://bugs.winehq.org/attachment.cgi?id=15297 a few weeks ago. As i said before , it's enough to stub out interface calls like in that patch to let the game start I discovered later I put the headers in the wrong (seperate ) header file, so i thought first to send in the definitions in the correct header. I thought later on send the rest in small pieces thanks again for the review Send instant messages to your online friends http://uk.messenger.yahoo.com
Re:kernel32: Tiny improvement to the GetVolumePathNameW stub (try 4)
You've handled *a* successful case, but what about the error case?
As i said already in the mail with the patch, it might be *a* case, but this is
the case
that most apps will follow as far as i can see. Futhermore, when apps are
really crashing
into the other cases, it can be added later on i.m.o. For now they will just
fall back to the current
implementation, returning not implmented then, so there will be no
differnce with current behaviour.
+{
+ lstrcpynW(volumepathname,filename,4);
+ return TRUE;
+}
Also, you're copying 4 bytes of filename into volumepathname. I don't
think you understand what lstrcpyn does. Imagine this case:
volumepathname =
buflen = 8
filename = C:\\file
After the call to lstrcpyn:
volumepathname = C:\\f
MSDN says volumepathname was a pointer to an out - string, so how would it
become someting
like aa, or am i overseeing something?
Send instant messages to your online friends http://uk.messenger.yahoo.com
Re: kernel32: Tiny improvement to the GetVolumePathNameW stub (try 4)
- Original Message
From: James Hawkins [EMAIL PROTECTED]
To: Louis. Lenders [EMAIL PROTECTED]
Cc: wine-devel@winehq.org
Sent: Thursday, 21 August, 2008 3:55:07 PM
Subject: Re: kernel32: Tiny improvement to the GetVolumePathNameW stub (try 4)
That whole paragraphs reads hack now, fix later, which is definitely
not acceptable.
Well, I would call it a semi-stub, there's more of them scattered all over
the wine-source. But if opinions are it's too hackish, that's fine with me, I
was only trying to help a user to get an app running
+{
+ lstrcpynW(volumepathname,filename,4);
+ return TRUE;
+}
Also, you're copying 4 bytes of filename into volumepathname. I don't
think you understand what lstrcpyn does. Imagine this case:
volumepathname =
buflen =
8
filename = C:\\file
After the call to lstrcpyn:
volumepathname = C:\\f
MSDN says volumepathname was a pointer to an out - string, so how would it
become someting
like aa, or am i overseeing something?
Yes you are overseeing something. I think it would be a good idea if
you read up a bit more on C in your spare time. I get the feeling you
don't quite have a grasp on the intricacies of the language,
particularly pointers and strings.
What I meant is, why would an app set volumepathname to aa, as it's the
pointer where it expects to find the volumepoint, so on windows this would be
filled by kernel32.dll, not by the app. Maybe you mean this could be the case
after a second call to GetVolumePathName? Anyway, this is not the place to
discuss a C-language course so I'll reread the docs. Thanks for the comments
anyway.
Send instant messages to your online friends http://uk.messenger.yahoo.com
rsaenh: Test and correct the maximum allowable salt length
Usually i don't feel the need to respond to messages on wine-devel, but now i do: What in the hell does this patch do? Why is it needed? What does it fix/implement? Doees this change affect any Bugzilla issues? Where is the Changelog? This is what I have been trying to get you to do. I have no idea what you are up to and I have NO access to IRC or other alternate forms of messaging/communications other than this mailing list. I haven't got a clue what the patch is all about either, but if i'd wanted to know i would just drop a friendly note, asking some more info. As long as i've followed wine's development i've seen Juan as very helpful and main contributor to wine, so i'm a bit surprised about your unfriendly reaction to this patch __ Not happy with your email address?. Get the one you really want - millions of new email addresses available now at Yahoo! http://uk.docs.yahoo.com/ymail/new.html
Re: programs: add rudimentary dxdiag
Detlef Riekenberg wine.dev at web.de writes: Louis, please do not give up and reopen the bug. You got already some comments, and I want to give some more Ideas. - You told, that you reuse the code for the cube from the internet. That is a no-go because of copyright and license issues! Where does the code came from? What is the license for that code? As already said, from tutorials scattered allover the internet, www.codesampler for example. I'm not sure what the license code for a tutorial is. Is the hello world tutorial also copyrighted? - You told, that minimizing the Cube-Window does not work now, but worked in an old Wine. You think, that this is an Regression in Wine. It's also possible, that there was an bug in Wine which is now fixed and your dxdiag code is not correct. I'd have to check by compiling a windows executable. If it runs in windows, it should run in wine. Again, a clean implementation can avoid this issue. As long as simple stub is not accepted i cannot even start with that. Anyway, thanks for your comments Detlef. Regards
Re: programs: add rudimentary dxdiag
Here's what you said in your original patch: - code for spinning cube was partially based on spinning cube code scattered all over the internet -rest was ripped of winecfg - There' s a problem while minizing the d3d-window, but running it in wine-0.9.22 it all goes fine, so this must be a regression somewhere, and not a bug in the attached code. I'll go after that later. - Hopefully you're not to picky on this patch, it 's quite some line's of code,and i'm sure things need to be improved, but this does not affect wine's core code but os rather an enhancement, and it 's not really possible to send it in in small chuncks. Basically you copied code from you don't know where, True, why reinvent the wheel (copied code from winecfg) minimizing doesn't work but that's not a bug, as far as i can see it looks like regression and I shouldn't be picky and accept a big crappy patch anyway. I admit i'm just a hobbiest, but somehow i was hoping you could point me to what the crappy parts in the patch are, so that i could improve it, but i already gave up that hope. Do you really wonder why you have trouble getting it committed? Maybe i was just hoping for some positive feedback, but i'll stop wasting yours and my time
Re: programs: add rudimentary dxdiag
Detlef Riekenberg wine.dev at web.de writes: Why not? - empty stub - the property-sheet - demo-window with an empty (in memory) Bitmap - the wine-logo as bitmap - spinning cube reorder, when needed Hi Detlef (and Juan) , thanks for the response. I sent in a simple stub (and two other patches on top of that i need to get something useful in dxdiag) but apparently they are not accepted either. If only i knew why, but i don't as again i got no comment why they were rejected, so for now i'd have to guess : 1. no need for a dxdiag in wine 2. my patches are too crappy to respond to. In both cases it's useless to leave thebug i opened for missing dxdiag open, so i'll abandon it (bug 14118)
Re: programs: add rudimentary dxdiag
Juan Lang juan.lang at gmail.com writes: Hi Louis, Apparently they were never received in the first place. At least, I don't see them on the wine-patches archive. Maybe you should resend? --Juan Hi Juan: http://www.winehq.org/pipermail/wine-patches/2008-June/056911.html
Re: programs: add rudimentary dxdiag
Juan Lang juan.lang at gmail.com writes: http://www.winehq.org/pipermail/wine-patches/2008-June/056911.html Ah. That's not enough to judge where your patches are going. I already explained, see http://bugs.winehq.org/attachment.cgi?id=14342 and http://www.winehq.org/pipermail/wine-patches/2008-June/056659.html. That's what i was intended to go to. A series of patches, adding a stub program, then adding a little more to it, and so on, would help judge the final product, while considering each piece independently. Here;s the whole patch that i sent a while ago, but i was advised after that to first sent a simple stub because the patch was too large: http://bugs.winehq.org/attachment.cgi?id=14343 It has the risk of getting rejected partway or wholesale, but has a higher likelihood of getting comments. It also removes a lot of the roundtrip time with patches. Sorry if the guidance isn't very clear. Don't be afraid to ask AJ on irc for more feedback too. --Juan Anyway. thanks for your explanation
Made ENTER_GL() - LEAVE_GL() free X11 lock on exception inside opengl, code
And as was shown, Wine correctly returns NULL when its called without a context, so there is something else making it crash. It may be a buggy driver. It may be memory corruption Wine is causing.. who knows. i don't think it's buggy driver, this happens as far as i know for various people, so i'd guess various cards/drivers. Is there a way to track down what AutoCAD returns in this call to glGetString on Windows? Btw, the installer even finishes fine with native opengl32.dll ( no, this is not a joke!), so somehow i have the feeling that an exception handler is the right way anyway, but i lack knowledge of opengl, so i'll shut up for now ;) ) __ Not happy with your email address?. Get the one you really want - millions of new email addresses available now at Yahoo! http://uk.docs.yahoo.com/ymail/new.html
opengl32: work around a crash in glGetString
As I mentioned before this requires a test case. As i tried to explain , in a simple test glGetString just return null, it will not crash for me, like it does in the program. I remember from the gl log that the program didn't create a WGL context at all. It isn't allowed to make opengl calls because of that Allowed or not, the program does so, and on windows it installs just fine. Perhaps without a context (if Windows allows it) you get some GDI software renderer string back or so. It just returns (null) Anyway at this point it sounds like a workaround instead of a fix for the real bug. Well, the bug might be outside wine, so then it would be workaround, yes, but still necessary IMO. I cannot see how i can make a testcase based on the output of autocad here: http://bugs.winehq.org/attachment.cgi?id=14005 , other then i did already. It's just an endless sequence of 'wglGetIntegerv','wglFinish', and 'wglFlush', and then a crash in glGetString. I cannot make a test program crash like that; the test program just returns null, like i said before A last stupid question for stefan: how can i make X load the mesa driver, instead of my nvidia? __ Not happy with your email address?. Get the one you really want - millions of new email addresses available now at Yahoo! http://uk.docs.yahoo.com/ymail/new.html
Wine + Fedora
Hi, just thought dropping a note here so you'd know: the troubles reported for wine+fedora 9, now also affect fedora 8. Last saturday i did a 'yum update', and after that about all wine-applications froze my computer. Only a hard reboot helped... Solved it by reverting back to kernel 2.6.24.7-92.fc8 Just in case a new wine-1.0 release comes out, and fedora-users start whining wine 1.0 is really crap, it freezes my computer , hope this will be fixed soon.
AutoCad and wine
This seems to be a must have for many people. Would be nice if we could have this running in near futurfe. I found that you can download a few old trialversions from http://www.brothersoft.com/autocad-download-78215.html (this is autocad2006l on the right side you can see the downloadlinks for 2004/2007/2008 as well) I'm currently testing AutoCAD 2004 and with a bit workarounds/tweaking it seems to run but the main issues seem to be with the installer; I'll add some info to the appdb; i'll test other versions lateron; if someone wants to join testing feel welcom ;)
Re: How to phrase Wine's success rate
Dan Kegel dank at kegel.com writes: When making announcements about Wine 1.0, it's useful to include an objective measure of how well it works for the average app, one that correctly conveys both Wine's promise and its limitations. Our current appdb stats are: Platinum 1500 Gold 1763 Silver1194 Bronze1071 Garbage 2512 I think it's important to add a note for the user that wine needs a bunch of tweaking. From the garbage test-results that come in in the appdb, many can be solved so easily (missing mfc42, msvcp60 and lots of other add-on dlls. Also, since wine started to have it's own gdiplus and d3dx9* dlls, lots of crashes because of unimplemented stuff in these dlls). When users know where to look for, it could avoid a lot of dissappointment i guess
Re: What graphics cards do the d3d9 tests pass on?
Dan Kegel dank at kegel.com writes: Anyone know how to get the d3d9 tests to pass? Are there a set of graphic cards that are known to work with them? Right now, nobody who's reported test results under wine is seeing them pass: http://test.winehq.org/data/2470b0b31605133ec046330dd79fdccaa7ba33fe/#group_Wine:d3d9:visual And, come to think of it, ditto for Windows: http://test.winehq.org/data/200804161000/#group_XP:d3d9:visual (though the data's pretty thin there). All the apparant successes are really just skipped tests. - Dan I think the tests also suffer from the d3d-regressions. When i ran the tests a few weeks ago, o saw some fancy visual-tests carried out on my computer (red/green/yellow rectangles etc).The tests took quite some time to finish. Right now i only see the screen flashing black a few times, and that's it. Looks like most tests are really skipped. Maybe we should a regression test to see what patch broke this
Re: Call for help with Wine 1.0 testing
Jeremy White jwhite at codeweavers.com writes: Hi Folks, One key goal for Wine 1.0 is that all of its conformance tests run successfully on nearly all systems. We would really like your help in figuring out how close we are to that goal. To that end, if you are comfortable with checking Wine out via git, could you please visit this page: http://wiki.winehq.org/MakeTestFailures and follow the instructions there? (It's really simple; build current git Wine, download + run a script). And, if you're a Wine developer, since Alexandre is away and the code freeze is on, why not look for one of those failures in your own make test results and see if you can fix it? Thanks! Jeremy Unfortunately the test crashes here with: Running: d3d8:volume (60 of 335) fixme:d3d:IWineD3DImpl_FillGLCaps OpenGL implementation supports 32 vertex s fixme:d3d:IWineD3DImpl_FillGLCaps Expected vertex samplers + MAX_TEXTURES(=8 fixme:win:EnumDisplayDevicesW ((null),0,0x33f7cc,0x), stub! Running: d3d9:d3d9ex (61 of 335) fixme:d3d:IWineD3DImpl_FillGLCaps OpenGL implementation supports 32 vertex s amplers and 32 total samplers fixme:d3d:IWineD3DImpl_FillGLCaps Expected vertex samplers + MAX_TEXTURES(=8 ) combined_samplers fixme:win:EnumDisplayDevicesW ((null),0,0x33f8cc,0x), stub! X Error of failed request: GLXBadDrawable Major opcode of failed request: 143 (GLX) Minor opcode of failed request: 5 (X_GLXMakeCurrent) Serial number of failed request: 263 Current serial number in output stream: 263 Those tests in d3d8/d3d9 used to pass fine here a few weeks ago
Re: msvcrtd: add DllMain
- Original Message From: Alexandre Julliard [EMAIL PROTECTED] To: Louis. Lenders [EMAIL PROTECTED] Cc: wine-devel@winehq.org Sent: Thursday, 10 April, 2008 5:15:56 AM Subject: Re: msvcrtd: add DllMain Louis. Lenders [EMAIL PROTECTED] writes: Hi, this is for bug http://bugs.winehq.org/show_bug.cgi?id=5133 It looks like several apps (like Rubies, and Resolume and i guess several others) are shipped with a copy of this dll (along with msvcr71 and others). So i think it's ok to use this native dll then, and that is what this patch does. In this way this patch fixes bug #5133 It doesn't fix anything, it just hides the bug. -- Alexandre Julliard [EMAIL PROTECTED] Maybe fix wasn't the right word; on the other hand, if you call it hiding a bug, then we're hiding tons of bugs, like in gdiplus, that also loads the native gdiplus, if that is shipped with the application. Anyway, if you don't like it that way, just leave it ___ Yahoo! For Good helps you make a difference http://uk.promotions.yahoo.com/forgood/
Question about LoadImageW and gifs (affects all new Autodesk installers)
Hi, does anyone know if LoadImageW is supposed to work with *.gif files? I'm asking because Autodesk installers seem to so something like LoadImageW(0,c:\\foo.gif,IMAGE_BITMAP, 0, 0, LR_LOADFROMFILE) and then wine just crashes later on, as it tries to get the bitmapinfo header , and ends up with wrong info for size of bitmapinfoheader, width, height etc. Anyone an idea why the installer would do such weird thing? See also http://bugs.winehq.org/show_bug.cgi?id=11784 ___ Yahoo! For Good helps you make a difference http://uk.promotions.yahoo.com/forgood/
improve winetricks dotnet 1.1
Hi, i wonder if it would be possible to improve winetricks dotnet 1.1, so that
it's actually able to run
.net-1.1 applications. Currently it only installs the framework, but due to
bugs the apps don't run. Atm moment i use pretty worthless script below to get
them running, but i'm sure one of the winetricks hackers could turn this into a
nice script
Note, the dlls gdiplus and mscoree should be set to native only, not (native,
builtin), so override_dll should look tiny bit different then in winetricks.
__
Sent from Yahoo! Mail.
The World's Favourite Email http://uk.docs.yahoo.com/nowyoucan.htmloverride_dlls() {
echo Overriding following DLLs: $@
cat /tmp/override-dll.reg _EOF_
REGEDIT4
[HKEY_CURRENT_USER\Software\Wine\DllOverrides]
_EOF_
while test $1 !=
do
echo \$1\=\native\ /tmp/override-dll.reg
shift
done
regedit /tmp/override-dll.reg
rm /tmp/override-dll.reg
}
cd /tmp
wget http://bugs.winehq.org/attachment.cgi?id=11046
sh attachment.cgi?id=11046
cp -rf ~/.wine/drive_c/windows/Microsoft.NET/Framework/v1.1.4322/gdiplus.dll
~/.wine/drive_c/windows/system32/
override_dlls gdiplus
winetricks allfonts
wineprefixcreate #to register the fonts
cp -rf ~/.wine/drive_c/windows/system32/URTTemp/mscoree.dll
~/.wine/drive_c/windows/system32/
override_dlls mscoree
Re: Google Summer of Code
Luis C. Busquets Pérez luis.busquets at ilidium.com writes: Please find attached some projects that could be in this Summer of Code: 1. Finishing the implementation of d3dx9_36. Since we have already the forwarding d3dx9_xx there is just need for the this dll to be in our system. With this fully dll implemented tehre would be no need. Finishing the implementation of d3dx9_36 would be a bit too much i guess, for doing that in 2/3 months. I like the idea though, better do some work on d3dx9_36 Further i would find it nice if a project proposal would be something like write a dxdiag.exe. Something like a fancy spinning cube with wine-logo, and frame-rate counter or something the like. This would allow users to quickly test if they have set up their opengl/directX stuff correctly, and if they have hardware acceleration enabled. This would be something that could be easily done in 2/3 months
Re: Next big app(s) to try?
By the way, AutoCAD and 3ds max are very popular applications. It's easy to check how they are popular by using Google. For example, for AutoCAD alone you will get 43,800,000 results [1]. So there is a really a lot of people who depends on Autodesk products such as AutoCAD. So I think it's about time to get .Net 2.0 support into wine. Actually all the info is there in bugzilla to get a lot of .net applications running . I know .net support is not a target of wine-1.0.0, but why not reconsider? I got 3dmax 9 somehow running, but it seems to suffer from opengl bug; AutoCad 2008 only made it into the main screeen,then threw up a messagebox about a fatal error. So if someone could pick this up , and fix the remaining .net issues, i think wine could get another boost...
Re: GOM player
On 1/17/08, Dan Kegel dank at kegel.com wrote: http://www.guardian.co.uk/technology/2008/jan/17/linux.korea says everyone in Korea uses the GOM player... It installs ok, but blew up when I tried to load the Sony music stream from its playlist. ... http://www.gomplayer.com/ supposedly comes with lots of codecs. Rolf Kalbermatter r.kalbermatter at hccnet.nl writes: I tested it in wine, doesn't play anything in plain wine. With native quartz (and installing some codecs with winetricks) it works , but there is still some issues: window can't be moved, and it displays the movies just too bright. Unfortunately I haven't seen any work on quartz latest months/years. For now i'd give it a bronze rating.
Re: kernel32:add ReadFileScatter
Dan Kegel dank at kegel.com writes: Hey Louis, Focht is using a pseudonym, and I believe it's Wine policy to not accept patches without real names. His patches should be used as guides only, and should not be reposted to wine-patches, until such time as he decloaks. Well , sorry, i thought it was OK to send the patch to wine-patches, as he's not going to send them himself, and also from bugreport he stated clearly (quote): you might try attached patch which implements kernel32.ReadFileScatter based off what I found in MSDN documentation. So looks like a perfectly clean patch to me, and i have no reason to not believe him If he doesn't want to decloak, I think we can't use his patches. I rather wish he would avoid attach patches to bugs, as it tempts people into submitting them as you have done, which is a waste of effort given Wine's policy. But I greatly value his ability to describe where and how Wine is wrong. Me too! So somehow i hope there's a way he keeps being involved in wine. - Dan
Re: defining and revamping our bugzilla categories
James Hawkins truiken at gmail.com writes:
Currently we have some categories that exactly fit to one dll and
some categories that include multiple dlls that are related. Also
there is overlap between those two. (And perhaps some that fit in
neither.)
E.g. there is wine-quartz (one dll dlls/quartz/ ) and
wine-directx-dshow (includes dlls/{quartz,msdmo,qcap}/ ).
Well, the common (newbie) user probably won't know anything about dshow (neither
do i ;) ), nor will he know what quartz stands for. The only thing he will see
in his console is something like:
fixme:quartz: blablabla
So for example if he was about to search for duplicates before filing a bug,
it's really better to have a per dll component.
One component per dll is ideal for development.
There are some situations where a group component works best, e.g.
directX. In most cases though, per dll is best. We can have both
types of components. The following is a list of components that need
to get the boot or be renamed:
wine-rebar (this is comctl32, no need for this component)
wine-binary (what does that even mean?)
wine-gdi-(printing) - gdi
wine-gui (per dll)
wine-multimedia (per dll)
wine-net (needs to be per dll)
wine-patches (what was this for?)
wine-user - user32
wine-usp10.dll - usp10
bug list, comments, login (what are these for?)
totally agree with James. I'll await the changes.
Re: Wine 1.0 bugs, release criteria
Dan Kegel dank at kegel.com writes: Louis wrote: Ok, here one on my wish-list: All apps that currently fail on wine due to shdocvw/mshtml disfunctionality. Hmm. I looked at the 48 bugs in http://bugs.winehq.org/buglist.cgi?product=Winecomponent=wine-shdocvw briefly, and marked a few of them that looked important as 1.0. See http://bugs.winehq.org/buglist.cgi?product=Winecomponent=wine-shdocvwtarget_milestone=1.0.0 How's that for a start? That's very much ok, thanks.
Re: Wine 1.0 bugs, release criteria
Dan Kegel dank at kegel.com writes: At Wineconf 2007, I was appointed to be the guy who decides (with Alexandre's approval) what bugs are 1.0 bugs and what aren't. So I've started adjusting the Target Release fields on a few bugs in Bugzilla. Over the next month or so, I'd like Wine developers to nominate important Comments? - Dan Maybe it's an idea to say if a bug includes at least 5 duplicates (so 5 apps suffering from the same bug) it can be automatically boosted to the 1.0 target release. I was especially thinking of bug #7380. ( http://bugs.winehq.org/show_bug.cgi?id=7380 ) Couls i set this one on the list? Any comments
Re: Wine 1.0 bugs, release criteria
Ok, here one on my wish-list: All apps that currently fail on wine due to shdocvw/mshtml disfunctionality. Almost all of these apps start fine using ies4linux. I did quite a lot of testing of demo's, and many of them fail because of this (in most cases you just end up with a white screen). Actually i figured out what exact dlls make them fail in wine, and run in ies4linux. I currently use the script below to work around this , and in most cases it works quite fine (native shlwapi and urlmon are probably only needed for dll-dependancy, jscript and msls31 are not implemented by wine) (/sda3/native/ is where i've put my dlls from my windows-partition) unalias cp cp /sda3/native/shdocvw.dll ~/.wine/drive_c/windows/system32/ cp /sda3/native/shlwapi.dll ~/.wine/drive_c/windows/system32/ cp /sda3/native/urlmon.dll ~/.wine/drive_c/windows/system32/ cp /sda3/native/mshtml.dll ~/.wine/drive_c/windows/system32/ cp /sda3/native/mshtml.tlb ~/.wine/drive_c/windows/system32/ cp /sda3/native/jscript.dll ~/.wine/drive_c/windows/system32/ cp /sda3/native/MSLS31.DLL ~/.wine/drive_c/windows/system32/ cp /sda3/native/mlang.dll ~/.wine/drive_c/windows/system32/ regsvr32 jscript (then run the app with native shdocvw, shlwapi,urlmon,mshtml,mlang).
Re: wtsapi32: add stub for WTSRegisterSessionNotification
Anything wrong with these simple stubs? http://www.winehq.org/pipermail/wine-patches/2007-September/043944.html and http://www.winehq.org/pipermail/wine-patches/2007-September/043945.html ? - Yahoo! Answers - Get better answers from someone who knows. Tryit now.
Re: About WritePrivateProfileString and file operations
Zhongli Xu zhongli.xu at gmail.com writes: Hi all,I run some tests about mixed using WritePrivateProfileString and stand file operationsCodes look like this:GetPrivateProfileString(keyname, value);fopen();fprintf(# comments); fclose();WritePrivateProfileString(keyname, newvalue);What I found in the file is that either WritePrivateProfileString operation succeeded(newvalue has been written) or fprintf succeeded(#comments shows up in the file). On windows hosts, there is no such problem.Any suggestion or idea is welcomed.Thanks.Milo I don't know if it's the same issue but i know there is a bug in wine's implementation of WritePrivateProfileString. See http://bugs.winehq.org/show_bug.cgi?id=5024 I currently use this hack http://bugs.winehq.org/attachment.cgi?id=6750 to install the game. Maybe it helps for your app too, and maybe someone could pick up this bug.
Fonts (+liberation again...)
Hi , a few weeks ago posted something about if liberation fonts could be included in wine. There didn't seem to be one view of how to do that. Of course 'winetricks liberation' is great, but i'd like to see something that works out of the box on a fresh .wine. Attached is a patch, that generates Arial.ttf from liberation font (just like winetricks) but this is an attempt to get it included in wine's source. To summarize, i added a file arial.ttf2sfd that changes a liberation font into arial.sfd, change appropriate family/font name, and then generate the arial.ttf. All is done by fonforge. Of course this patch lacks checking for presence of liberation, and has ugly hard-coded path for the liberation-font, but that could be worked on later on. Simple question: Could something like this be included in the source, otherwise i'm not gonna spend any time improving it. Any hints welcomed. Regards, louis - Yahoo! Answers - Get better answers from someone who knows. Tryit now.diff --git a/Make.rules.in b/Make.rules.in index a32b276..257598e 100644 --- a/Make.rules.in +++ b/Make.rules.in @@ -126,7 +126,7 @@ LINTS = $(C_SRCS:.c=.ln) # Implicit rules -.SUFFIXES: .mc .rc .mc.rc .res .res.o .spec .spec.o .idl .tlb .h .y .l .tab.c .tab.h .yy.c .ok .sfd .ttf .man.in .man _c.c _i.c _p.c _s.c +.SUFFIXES: .mc .rc .mc.rc .res .res.o .spec .spec.o .idl .tlb .h .y .l .tab.c .tab.h .yy.c .ok .sfd .ttf .ttf2sfd .man.in .man _c.c _i.c _p.c _s.c .c.o: $(CC) -c $(ALLCFLAGS) -o $@ $ @@ -179,6 +179,9 @@ LINTS = $(C_SRCS:.c=.ln) .c.ok: $(RUNTEST) $(RUNTESTFLAGS) $ touch $@ +.ttf2sfd.sfd: + $(FONTFORGE) -script $(TOPSRCDIR)/fonts/$ $ $@ + .sfd.ttf: $(FONTFORGE) -script $(TOPSRCDIR)/fonts/genttf.ff $ $@ diff --git a/configure b/configure diff --git a/dlls/gdi32/dc.c b/dlls/gdi32/dc.c diff --git a/dlls/shell32/shell32_En.rc b/dlls/shell32/shell32_En.rc diff --git a/dlls/shell32/shellpath.c b/dlls/shell32/shellpath.c diff --git a/dlls/shell32/shresdef.h b/dlls/shell32/shresdef.h diff --git a/dlls/user32/sysparams.c b/dlls/user32/sysparams.c diff --git a/fonts/Makefile.in b/fonts/Makefile.in index 2a69d6a..35d1e71 100644 --- a/fonts/Makefile.in +++ b/fonts/Makefile.in @@ -47,11 +47,16 @@ BITMAP_FONTS = \ vgas1257.fon \ vgas874.fon +TTF2SFD = \ +arial.sfd + TRUETYPE_FONTS = \ - marlett.ttf + marlett.ttf \ +arial.ttf FONTS = \ $(BITMAP_FONTS) \ + $(TTF2SFD) \ $(TRUETYPE_FONTS) all: $(FONTS) diff --git a/fonts/arial.ttf2sfd b/fonts/arial.ttf2sfd new file mode 100644 index 000..2ce704e --- /dev/null +++ b/fonts/arial.ttf2sfd @@ -0,0 +1,3 @@ +Open(/usr/share/fonts/liberation/LiberationSans-Regular.ttf); +SetFontNames(ArialMT, Arial, Arial); +Generate($2); diff --git a/include/setupapi.h b/include/setupapi.h diff --git a/tools/wine.inf b/tools/wine.inf
Re: request to change appdb message
I think the main problem is that there is a lack of maintainers and the ones that exist seem to be mainly inactive. Yeah, and it's quite a tedious task to submit test-results, new versions and new apps into appdb. Maybe we need a few more active ones. If they were active then there would already be notes pointing to easy fixes for the apps like NoCD patches, d3dx9xx.dll files, etc. I agree a pre-parser for common issues would be nice, but probably quite a bit of coding work and likely to get many wrong hits. I'll try to give it a shot later, something like a page with commaon failures. Could take a while though... It isn't all that complex. It would require someone to start to collect common debug output from users and then look at how we might look for particular dlls or errors to identify the particular issue. For someone with lots of experience it wouldn't seem to be all that difficult but it really depends on how generic some errors are. I never played with appdb code so i'm afraid i'm of no help there :( Chris
Re: request to change appdb message
Chris Morgan chmorgan at gmail.com writes:
How do you normally judge if the result is valid or not? What if the
result says that everything works?
Basically i'm only talking about garbage test results. If the app is
gold/platinum there's of course no need to paste debug output
It seems like any result could be faked, and we can't reject a test result
from
a user that had problem just because a handful of other users didn't.
Yeah, i agree, there's no way to solve that.
What else can we do with the issue you raised in #1? If users report
their app doesn't work but don't report the crash data then at least
we know the app doesn't work and thats valuable data. If it is too
difficult to report bugs in bugzilla we should see if there are ways
to assist with this.
I don't think it's too difficult, most users just don't bother to do this.
I'm not entirely sure what your point #2 is. You are arguing that we
want to see crash results in test submissions because then we can
reply with a suggestion about how to fix the issue? It seems like this
is exactly the kind of thing we want in bugzilla since it reflects
issues users have with Wine.
Unfortunately , if anyone would open a bug with the example
i gave in issue #2,it would be closed immediately with a comment
Invalid - Closing.
I guess my point about #2 is that assuming the user didn't do
something really crazy, the issues the user has tend to be
deficiencies in wine or its documentation and these really are
legitimate issues that should be addressed.
Yeah, so maybe we could add a list of Common failures to the documention,
with the solution. I can live with that. Then we could point garbage test
submitters to that page. That would be a nice work around. I'll have to
figure out how wiki works, and then i could give it a shot lateron i guess.
Something like:
Problem:
err:module:import_dll Library MSVBVM60.DLL (needed by LC:\\app.exe)
not found
err:module:LdrInitializeThunk Main exe initialization for LC:\\app.exe
failed,status c135
Solution:
winetricks vcrun60
or
Problem:
wine app.exe
err:ole:CoGetClassObject class {0514--0010-8000-00aa006d2ea4}
not registered
err:ole:create_server class {0514--0010-8000-00aa006d2ea4}
not registered
err:ole:CoGetClassObject no class object
{0514--0010-8000-00aa006d2ea4}could be created for
context 0x5
Unhandled page fault etc.
Solution:
winetricks mdac27
Would that be something useful?
Cheers, Louis
request to change appdb message
Hi, since a few weeks the following message is displayed when you try to submit test results into appdb: Please DO NOT include crash or Wine debug output. Instead report the crash as a bug in the Wine bugzilla at http://bugs.winehq.org. We ask that you use bugzilla because developers do not monitor the AppDB for bugs. I'm not that happy with this message for a few reasons: 1. Most testers will not attach this to a bug, either because there isn't an entry for the app in bugzilla, or they don't bother to do so. 2. There are crashes like these that users attach: wine app.exe err:module:import_dll Library MSVBVM60.DLL (which is needed by LC:\\app.exe) not found err:module:LdrInitializeThunk Main exe initialization for LC:\\app.exe failed, status c135 We don't want users to attach these things in bugzilla, we'd rather point them what to do in the email-field. If users don't attach crashes anymore to the testresults , i cannot by no means see anymore if a testresult is valid or not. I'd rather see something like: Please DO include crash or Wine debug output here, and report the crash as a bug in the Wine bugzilla at http://bugs.winehq.org. Any comments? - Yahoo! Answers - Get better answers from someone who knows. Tryit now.
Re: Liberation
Hans Leidekker hans at it.vu.nl writes: On Friday 15 June 2007 12:14:06 Michael Stefaniuc wrote: Why do you need to copy the fonts? Wine can use the system fonts. The Wine package would need to have only a dependency on the liberation font package. The liberation-fonts rpm is already in Fedora Extras for FC6 and in Fedora 7. That doesn't help when an app asks for Arial. Or when it references the file c:\windows\fonts\arial.ttf directly. -Hans So could something be included in wine's source like detect if they are present (/usr/share/fonts/liberation/ here), use Hans' convert-script to convert it into arial.ttf, and then copy them into /usr/share/wine/fonts/, i think that would be enough for apps to detect the font, right?
Liberation
Hi, this is mainly a follow up to the thread here http://www.winehq.org/pipermail/wine-devel/2007-May/057092.html , to give it a new boost Question is, are there any plans to include Liberation fonts in wine? I gave it a good testing last two weeks, that is, i converted the fonts with Hans' Leidekkers script , from link above, and tested the Arial-compatible font quite a bit, with several applications. It all seems to work great, no issues / problems found. Several applications would be very happy , if this were to be included in wine. Any comments? Some of the tested apps: xchat -- just aborts silently without arial font Book worms adventures -- pops up a crash window without arial font d3d9-samples from DirectX 9.0 SDK -- Don't show any text without arial font + a lot more that just look prettier with arial font. - Yahoo! Mail is the world's favourite email. Don't settle for less, sign up for your freeaccount today.
Re: GDI+ programs
Evan Stade estade at gmail.com writes: Hi, I want to make some real applications work with the built-in wine GDI+. Does anyone know of some programs that use GDI+ that would be good for guiding my development? thanks, Evan Stade Try Query bugs in bugzilla with keyword gdiplus: http://bugs.winehq.org/buglist.cgi?query_format=short_desc_type=allwordssubstrshort_desc=long_desc_type=substringlong_desc=gdiplusbug_file_loc_type=allwordssubstrbug_file_loc=keywords_type=allwordskeywords=bug_status=UNCONFIRMEDbug_status=NEWbug_status=ASSIGNEDbug_status=REOPENEDbug_status=RESOLVEDbug_status=VERIFIEDbug_status=CLOSEDemailassigned_to1=1emailtype1=substringemail1=emailassigned_to2=1emailreporter2=1emailcc2=1emailtype2=substringemail2=bugidtype=includebug_id=votes=changedin=chfieldfrom=chfieldto=Nowchfieldvalue=cmdtype=doitorder=Reuse+same+sort+as+last+timefield0-0-0=nooptype0-0-0=noopvalue0-0-0=
Wine fails to start browser
Hi, i noticed some kind of regression in current git, for example when i try to start http://fe.trymedia.com/dm/infogrames/30m_default/t_20em/FreddiKelp.exe , a download manager for the game. With current git i get this: Usage: winebrowser URL That's it, whereas in wine-0.9.34, it opens my firefox fine, at the correct page , and starts to download the game. The only solution i found now is again add %1 to the key HKEY_CLASSES_ROOT\http\shell\open\command\winebrowser, but that fix' was not acceptable in wine, me was told a few weeks ago. I saw some patches from Misha Koshelev that might be related to this, maybe changing the key is acceptable now, or anyone know another fix? Thx - Yahoo! Answers - Got a question? Someone out there knows the answer. Tryit now.
Re: Wine fails to start browser
Koshelev, Misha Vladislavo mk144210 at bcm.tmc.edu writes: If I have time, I may look into how hard it would be to add DDE for winebrowser (I don't think it should be too bad, but I'll have to check). Misha Cool! looking forward to that than ;)
Re:wine.inf: Create fake dll for iexplore.exe.
wine.inf: Create fake dll for iexplore.exe. Vitaliy Margolen wine-patches at kievinfo.com Thu May 24 08:50:10 CDT 2007 Some older programs check if IE is installed looking for c:\Program Files\Internet Explorer\iexplore.exe --- tools/wine.inf |1 + 1 files changed, 1 insertions(+), 0 deletions(-) -- next part -- A non-text attachment was scrubbed... Name: 5d5627890e959f7208122b32f60035a59b566e72.diff Type: text/x-patch Size: 353 bytes Desc: not available Hi, after comittment of this patch , I still don't see a fake c:\Program Files\Internet explorer\iexplore.exe. It appears this should be handled in differrent way. Somehow the directory Internet Explorer should be created first, right? Or am I missing something? - Yahoo! Answers - Got a question? Someone out there knows the answer. Tryit now.
Re: problems regression testing/compiling wine
E winegcc: gcc failed. make[2]: *** [winex11.drv.so] Error 2 make[2]: Leaving directory `/home/eric/wine/dlls/winex11.drv' make[1]: *** [winex11.drv] Error 2 make[1]: Leaving directory `/home/eric/wine/dlls' make: *** [dlls] Error 2 _ More photos, more messages, more storageget 2GB with Windows Live Hotmail. http://imagine-windowslive.com/hotmail/?locale=en-usocid=TXT_TAGHM_migration_HM_mini_2G_0507 I think git clean -x should work too
Re: problems regression testing/compiling wine
EA Durbin ead1234 at hotmail.com writes: No, that doesn't help, i've tried distclean, git clean -x, the usual make clean, and nothing works. Regression testing seems borked passed two bisects. From: Louis Lenders xerox_xerox2000 at yahoo.co.uk To: wine-devel at winehq.com Subject: Re: problems regression testing/compiling wine Date: Sun, 13 May 2007 14:05:42 + (UTC) I know I had the same problem, and somehow i got around it, but i forgot how ;( maybe rm -rf */*/*.def from wine's source tree.
Internet explorer not detected
Hi, i tried help this dude on IRC channel getting an application to run called MegaSpoof. Even after creating fake registry key it kept complaining about missing Internet Explorer. After looking through the +relay log i found this: 000d:Call KERNEL32.CreateProcessW(,0034f428 Lc:\\Program Files\\Internet Explorer\\iexplore.exe -Embedding,000 0,,,,,,0034f7d8,0034f828) ret=77f1d75f 000d:Ret KERNEL32.CreateProcessW() retval= ret=77f1d75f In current wine a simple wine c:\Program Files\Internet Explorer\iexplore.exe just fails , because we don't have that directory. After manually creating it , and copy iexplore.exe.so to /Program Files/Internet Explorer/iexplore.exe, the application didn't complain anymore, and got further. Question: do we need to mimic windows behaviour, and create that directory + put wine's iexplore in it, or is the policy that in this case we just have to download MS ie6, and install that (as the application suggested)
Re: msvcp60 and bug 7679
Eric Pouech eric.pouech at wanadoo.fr writes: Tom Spear a écrit : On 4/26/07, Tom Spear speeddymon at gmail.com wrote: http://bugs.winehq.org/show_bug.cgi?id=7679 - IMVU 3D Avatar Chat client crashes I gave the application a try, and looks like there's a problem with builtin dbghelp.dll. When i use native dbghelp.dll , the login window comes up just fine, and i'm able to login as well, and get the client running. didn't test any further. BTW, could someone please add these categories like dbghelp, urlmon, quartz etc to bugzilla? has been requested a few times but no response yet :(
Re: wine.inf: update registry key
Dmitry Timoshkov [EMAIL PROTECTED] wrote: Louis. Lenders wrote: Hi, this fixes bug #7953 - http://bugs.winehq.org/show_bug.cgi?id=7953 Vitaly said this one won't go as it might break another app, but i don't get that , as the key in windows looks quite the same, No it doesn't in the default Windows setup, and the key was changed for a reason to make Picasa work some time ago: http://source.winehq.org/git/wine.git/?a=commitdiff;h=f03c86a27387cd1dc27c371d52a7c72d83b70481 -- Dmitry. I cannot check how it looks in a default Windows setup anymore, as i installed another browser (mozilla) on my windowsXP installation. However, there's one thing I don't get: the key on my WinXp installation does have that extra %1 now, so would that mean that picasa would crash on my windowsXp installation after i installed, or do things work differently there? - Yahoo! Mail is the world's favourite email. Don't settle for less, sign up for your freeaccount today.
Fedora packages, where are they?
Hi, the link on the wine-page to get the Fedora- wine packages points to nowhere. Could this be fixed? Furthermore, anyone know where i can get the wine-rpm for Fedora?
request to look into this bug
Hi, while working through the test reports in the appdb, i saw users submitting
crashes with applications , all similar to bug 7380, so i decided to take
it here. The applications that crash are
*WinMerge (newest version)
*BookWorms Adventures + several other PopCap games ( i tested them)
*5 other applications listed under bug 7380.
So i know of at least 10 applications that crash this way. They all start fine
using the buggy pointer patch from Rein Klazes below. However, i think it's
becoming rahter strange that all these (just released!) applications pass
buggy pointers, so i'm beginning to think the problem must be somewhere else.
I've sent in a patch to work around this bug by an exception handler a few
weeks ago, but that's likely not the way to go either then. Anyone an idea how
to tackle this problem? Thanks.
diff --git a/dlls/winex11.drv/dib.c b/dlls/winex11.drv/dib.c
index cec2058..4e61da4 100644
--- a/dlls/winex11.drv/dib.c
+++ b/dlls/winex11.drv/dib.c
@@ -3861,6 +3861,7 @@ INT X11DRV_SetDIBits( X11DRV_PDEVICE *ph
X11DRV_DIB_IMAGEBITS_DESCR descr;
BITMAP bitmap;
LONG width, height, tmpheight;
+ int nrsrcbytes, dibpitch;
INT result;
descr.physDev = physDev;
@@ -3880,6 +3881,17 @@ INT X11DRV_SetDIBits( X11DRV_PDEVICE *ph
if (startscan + lines height) lines = height - startscan;
+
+ /* pointer check */
+ dibpitch = ((width * descr.infoBpp + 23) ~23) / 8;
+ if( descr.compression)
+ nrsrcbytes = 1;
+ else {
+ nrsrcbytes = lines * dibpitch;
+ if( nrsrcbytes 0) nrsrcbytes = - nrsrcbytes;
+ }
+ if( IsBadReadPtr( bits, nrsrcbytes)) return 0;
+
switch (descr.infoBpp)
{
case 1:
@@ -3926,7 +3938,7 @@ INT X11DRV_SetDIBits( X11DRV_PDEVICE *ph
descr.width = bitmap.bmWidth;
descr.height= lines;
descr.useShm= FALSE;
- descr.dibpitch = ((descr.infoWidth * descr.infoBpp + 31) ~31) / 8;
+ descr.dibpitch = dibpitch;
X11DRV_DIB_Lock( physBitmap, DIB_Status_GdiMod, FALSE );
result = X11DRV_DIB_SetImageBits( descr );
X11DRV_DIB_Unlock( physBitmap, TRUE );
-
New Yahoo! Mail is the ultimate force in competitive emailing. Find out more
at the Yahoo! Mail Championships. Plus: play games and win prizes.
Re: On bugs and docs
James Hawkins truiken at gmail.com writes: However, the components could use a major revamping and should be fairly trivial. However I think that one component for each dll might be a bit much.. Maybe narrow the dll's down to categories such as wine-common-controls, and wine-riched.. No, we had vague components before, and they're not useful. Yeah, i use bugzilla for quite some time and from some components i still have no idea what they mean, and some are never used at all: *wine-console (i could guess, but i've never seen a bug with this component) *directx and directx-d3d. (ok , directx is more than d3d, but we already have components for dinput, dmusic etc. so why not remove directx) *wine-files (no idea what it means, no files ever seen with this component) *wine-gui (what does that mean?) *wine-ipc(never seen a bug with that component) *wine-multimedia (just change to winmm i'd say) *wine-ports (?) *wine-Rebar( could be moved to comctl32?) *wine- resources( (never seen a bug with that component) *wine-winelib ( (never seen a bug with that component)) My opininion is : please remove /change We need a component per dll. Yeah, common dlls not yet added that come in my mind are urlmon, mshtml, shlwapi and advapi32. I don't think we should add them all right now, but when we have a bug report for a bug in a particular dll that isn't a component yet, the component should be added (by request).
Re: WineCfg and DirectX options
Bryan Haskins kingofallhearts999 at gmail.com writes: Completely seconded, some nice UI love is the only thing we have under Transgaming right now, really. But a native Exec. UI is a python buggy UI. On 3/17/07, Michael Lothian mike at fireburn.co.uk wrote: HiHas anyone thought about adding the directx options to the Graphicstab in WineCfgJust now I've been testing all the work been done on the graphicslayer on different games so I've been switching on and off GLSL and changing backbuffer to fbo etc using regeditWould it not be better to change these things easily instead to allowfor wider testing. I completely agree with this.This fiddling around with regedit is really annoying, and moreover you cannot see what keys actually can be added or changed. Adding it to winecfg is quite simple, so i wonder what the reason is, why it's never been don
Re: AppDB performance issue
Bryan Haskins kingofallhearts999 at gmail.com writes: I was just replying, and reading now, no slow down at all. It loads a little slow running through all that text, but no where near the minutes everyone says it takes them, even on dialup. For your info, Appdb, is complete unusable for me ... Loading a page, or adding a test result to an application takes several minutes. Please fix, as this is really annoying :(
Failing regression tests, how to solve?
Hi, regression testing back to for example wine-0.9.22 all fails for me with link errors: palette.o: In function `X11DRV_PALETTE_ToPhysical': /sda3/wine-git/dlls/winex11.drv/palette.c:828: undefined reference to `GDI_GetObjPtr' /sda3/wine-git/dlls/winex11.drv/palette.c:848: undefined reference to `GDI_ReleaseObj' /sda3/wine-git/dlls/winex11.drv/palette.c:859: undefined reference to `GDI_ReleaseObj' /sda3/wine-git/dlls/winex11.drv/palette.c:866: undefined reference to `GDI_ReleaseObj' /sda3/wine-git/dlls/winex11.drv/palette.c:881: undefined reference to `GDI_ReleaseObj' /sda3/wine-git/dlls/winex11.drv/palette.c:898: undefined reference to `GDI_ReleaseObj' Maybe it's due to renaming of gdi32 directory, but how can i solve this? Regression testing is really impossible this way :(
Re: GreenVille font, is it still available? I have a question about it.
Hi, i finally got response from Larry Snyder (aka wierd_w ), who created Greenville font. (appeared he was on holiday). Below is the mail he sent me, and i talked to him on irc about it. To summarize, he's willing to license this LGPL, but reading his mail it seems to me this won't be a one day fix ;) What he writes further is quite a bit beyond my knowledge of fonts, so i really hope on of the wine developers who know something about fonts could read the mail and tell what could be done, or how things should be done. Thanks in advance,Louis Wierd_w [EMAIL PROTECTED] wrote: --- Louis. Lenders wrote: Hi, i got your email address from one of the Reactos developers. AFAIK you have been working on a Tahoma compatible font called Greenville. I was wondering if you still have it, and if you were willing to license this LGPL, so that it could be included in Wine project. Sure I could. I would be happy to release the glyphset that I have started on, but the reason I never finished the project was because of Differences between the rasterizers in FreeType and MS Windows. These differences would have required me to learn native truetype assembler to resolve, because of (in my opinion) overzealous freetype developers attempting to take full advantage of the hint system's tolerances. (Better explanation: MS Windows' rasterizer only blends to 16 shades of grey, instead of the theoretical maximum of 256 shades. There is a REASON for doing this: Namely, it makes it possible for visual hinting systems, like the software that I used to work on Greenville, to produce a visually high-quality font, without using exact binary precision with the use of hinting instructions; It allows for a degree of leniency in the rasterizer's interperetation of a glyph outline. Because Freetype wants to use the full theoretical maximum to achieve more shades of grey, you must be Spot on dead on the money accurate with the use of hinting instructions, or else the font will have 'blurry' edges. Throw into that the fact that the Delta instruction is patented by Apple computer corporation, and refuses to sell Freetype a license, it makes it VERY VERY VERY difficult to get Freetype to even render the glyph even kind-of correctly to begin with. It is possible to 'patch' freetype to turn off some of this overzealousness, and even to turn on the native bytecode interpereter-- but even then the test case TTF files I generated (that look just fine in windows) look asthetically gut-wrenching in freetype.) After spending 6 months trying (and failing) to resolve these internal rendering troubles, (and even considering the implementation of Scalar Bitmaps (SBIT)data so that I wouldnt HAVE to mess with Freetype's CRAP, and ending up with a 600kb font file.) I decided that enough was enough. Since the software that I used was VERY expensive (over 300$ US for the STUDENT DISCOUNTED version), and uses a proprietary working format, I would instead be happy to send you the glyph metrics and kerning data in Adobe format, and the actual Glyph set in your choice of vector format. (Note, I spent 2 weeks looking for a suitable TTF editing suite from the freesoftware community (You know, one that would *gasp!* Run on windows, where I could quickly test the fonts!), and came up empty handed. this is why I shelled out the big bucks for FontLab. The Free Software community's gestalt predjudices have shot it in the foot this time.) The actual HINTING process would then be up to you, but be prepared to have your hair turn grey, and to develop ulcers. In order to achieve a strong level of clean resemblence to Tahoma, you *WILL* need to use Truetype, OR, a bitmapped font set. Adobe Type-1 fonts (God, so many tools for that in the FOSS community, but not a SINGLE ONE for TTF hints!...) will not be suitable, because they lack the necessary hinting control (Only stem and leaf, instead of Vector Node Deform, like TTF-- Means that round contours, like in the letter O or G, will NEVER be as clean in an adobe type-1, as they will be with TTF.) I am currently at the college, and dont have access to my software at the moment, but when I get home this evening I will begin cleaning up my old resources and packaging them. Any particular preference on a vector format? I CAN package the raw glyphs into an unhinted Adobe Type-1, but you will have to do a vector conversion to work on them as a TTF. That shouldnt be a problem though. Likewise, I could also send an unhinted TTF, with the kerning data allready merged. If one of these would be suitable, let me know, and if not-- please specify one. Want to start your own business? Learn how on Yahoo! Small Business. http://smallbusiness.yahoo.com/r-index - To help you stay safe and secure online, we've developed the all new Yahoo! Security Centre.
Re: appdb rating inflation
Frank Richter frank.richter at gmail.com writes: On 03.01.2007 04:00, Dan Kegel wrote: No manual editing of files, no winecfg settings, no native DLLs, no third-party install scripts, and no cracks are allowed for a Platinum rating. Well, if you look at the submissions in the appb , we get reports like What works: everything i tested ;What doesn't: nothing How on earth can we find out if this app is silver, gold, platinum or polonium. IMHO it's far more important to have a good written HOWTO, than a rating. I'd say a rating like satisfying/not satisfying would be enough, and an application shouldn't have rating without a HOWTO.
Re: Building a full win32 winetest.exe
Paul Millar paulm at astro.gla.ac.uk writes: Try posting the problems with the crypt32 and hlink tests: it could be you need to patch you MinGW compiler to support extra functions. HTH, Paul. I too had problems trying to do make crosstest in crypt32 a time ago, this is what i get (link errors): cert.cross.o: In function `testSignAndEncodeCert': /sda6/wine-git/dlls/crypt32/tests/cert.c:1094: undefined reference to [EMAIL PROTECTED]' /sda6/wine-git/dlls/crypt32/tests/cert.c:1098: undefined reference to [EMAIL PROTECTED]' /sda6/wine-git/dlls/crypt32/tests/cert.c:1102: undefined reference to [EMAIL PROTECTED]' /sda6/wine-git/dlls/crypt32/tests/cert.c:1106: undefined reference to [EMAIL PROTECTED]' /sda6/wine-git/dlls/crypt32/tests/cert.c:1114: undefined reference to [EMAIL PROTECTED]' cert.cross.o:/sda6/wine-git/dlls/crypt32/tests/cert.c:1119: more undefined references to [EMAIL PROTECTED]' follow cert.cross.o: In function `testAcquireCertPrivateKey': /sda6/wine-git/dlls/crypt32/tests/cert.c:1939: undefined reference to [EMAIL PROTECTED]' cert.cross.o: In function `testGetPublicKeyLength': /sda6/wine-git/dlls/crypt32/tests/cert.c:2013: undefined reference to [EMAIL PROTECTED]' /sda6/wine-git/dlls/crypt32/tests/cert.c:2018: undefined reference to [EMAIL PROTECTED]' /sda6/wine-git/dlls/crypt32/tests/cert.c:2025: undefined reference to [EMAIL PROTECTED]' /sda6/wine-git/dlls/crypt32/tests/cert.c:2030: undefined reference to [EMAIL PROTECTED]' /sda6/wine-git/dlls/crypt32/tests/cert.c:2038: undefined reference to [EMAIL PROTECTED]' cert.cross.o:/sda6/wine-git/dlls/crypt32/tests/cert.c:2043: more undefined references to [EMAIL PROTECTED]' follow collect2: ld returned 1 exit status make: *** [crypt32_crosstest.exe] Error 1
Re: fonts:(followup)
Steven Edwards winehacker at gmail.com writes: Talk to the ReactOS guys and ask them if they still have it. I don't remeber if I ever committed it to ReactOS svn but if its there it would have been in reactos/media/fonts. Email them or ask on IRC if they can get you in touch with the author. I think his irc handle was WiredW but I don't recall his real name. The author had offered to license it LGPL or X11/BSD and was going to try to import the source or whatever in to fontforge but was frustrated because it lost his hinting or something. Hi Steven, i asked in reactos' irc, but this guy (wierd_w) hasn't been seen around for a while. So i've sent him a e-mail twice( 2 weeks ago, and a week ago, [EMAIL PROTECTED]) but got no response. Looks like he disappeared mysteriously:( (at least from this e-mail address) Looks like this way ends here for now.
Re: fonts:add
Greenville's face is substantially is different from Tahoma, the only thing which is similar to Tahoma is character widths, which makes Greenville a compatible replacement of Tahoma. Since I worked for a publishing company for 10 years, and I know how the font faces are .being created, I should say that although Greenville has been developed (formally) for ReactOS I don't think that that fact should make it less useable outside of it. So what now? How to proceed? Is that font freely available? Should we ask Reactos developers to donate the font to wine? Would be nice if this font could finally be added in near future, applications are failing because of this
Re: Bug in MapAndLoad function
There's nothing wrong with bringing this up on wine-devel. Adam has taken the time to track down the possible bug culprit, and he's sharing it with the developers. If, on the other hand, he had just said, app xyz doesn't work, don't know why the the response would be correct. Not every developer reads wine-bugs, or checks the bugzilla. Totally agreeing with you here. The mail from Adam Connell has much more to do with wine development then a load of other really off-topic mails that sometimes appear on wine-devel mailinglist.
When will ie6 registry key be added?
Hi, subject says it: When will ie6 registry key be added?People are filing bugs against wine, because installers fail, saying ie6 has to be installed. I guess in most cases, they will rush for ies4linux (which is btw a great script i think, but useless to use other apps then ie6) and end up with a mess because it sets lots of dlls to native.Or is this a wontfix, because real ie6 will never come with wine? Please consider adding the key. Send instant messages to your online friends http://uk.messenger.yahoo.com
ntdll: Add a stub implementation for RtlDllShutdownInProgress
a little test shows it returns some unknown status on my xp lap[top:0x7c927f00, so likely not STATUS_SUCCESS.diff --git a/dlls/ntdll/tests/rtl.c b/dlls/ntdll/tests/rtl.cindex 59871de..588e33e 100644--- a/dlls/ntdll/tests/rtl.c+++ b/dlls/ntdll/tests/rtl.c@@ -66,6 +66,7 @@ static RTL_HANDLE * (WINAPI * pRtlAllocastatic BOOLEAN (WINAPI * pRtlFreeHandle)(RTL_HANDLE_TABLE *, RTL_HANDLE *);static NTSTATUS (WINAPI *pRtlAllocateAndInitializeSid)(PSID_IDENTIFIER_AUTHORITY,BYTE,DWORD,DWORD,DWORD,DWORD,DWORD,DWORD,DWORD,DWORD,PSID*);static NTSTATUS (WINAPI *pRtlFreeSid)(PSID);+static NTSTATUS (WINAPI *pRtlDllShutdownInProgress)(void);#define LEN 16static const char* src_src = "This is a test!"; /* 16 bytes long, incl NUL */static ULONG src_aligned_block[4];@@ -97,6 +98,7 @@ static void InitFunctionPtrs(void)
pRtlFreeHandle = (void *)GetProcAddress(hntdll, "RtlFreeHandle"); pRtlAllocateAndInitializeSid = (void *)GetProcAddress(hntdll, "RtlAllocateAndInitializeSid"); pRtlFreeSid = (void *)GetProcAddress(hntdll, "RtlFreeSid");+ pRtlDllShutdownInProgress = (void *)GetProcAddress(hntdll, "RtlDllShutdownInProgress"); } strcpy((char*)src_aligned_block, src_src); ok(strlen(src) == 15, "Source must be 16 bytes long!\n");@@ -848,6 +850,13 @@ static void test_RtlComputeCrc32(void) ok(crc == 0x40861dc2,"Expected 0x40861dc2, got %8x\n", crc);}+static void test_RtlDllShutdownInProgress(void)+{+ DWORD ret;++ ret = pRtlDllShutdownInProgress();+ ok(0x7c927f00 == ret,"Expected 0x7c927f00,
got %08x\n", ret);+}typedef struct MY_HANDLE{@@ -933,4 +942,6 @@ START_TEST(rtl) test_HandleTables(); if (pRtlAllocateAndInitializeSid) test_RtlAllocateAndInitializeSid();+ if (pRtlDllShutdownInProgress)+ test_RtlDllShutdownInProgress();} Send instant messages to your online friends http://uk.messenger.yahoo.com
