Re: rpc issues
On 1/4/07, Matthew Edlefsen <[EMAIL PROTECTED]> wrote: On 1/2/07, Damjan Jovanovic <[EMAIL PROTECTED]> wrote: > On 1/1/07, Matthew Edlefsen <[EMAIL PROTECTED]> wrote: > > Hi, I've been trying to get a program that uses rpc to work on wine and I've > > been having some problems (my understanding is that isn't surprising). The > > goal is to be able to run a rpc server that sits and waits for connections > > over tcp/ip (It's for doing distributed computing). My first problem was > > that I was using RpcServerUseProtseq which after looking at the code noticed > > will always fail with tcp/ip since it passes RpcServerUseProtseqEp NULL for > > the endpoint which eventually causes > > rpcrt4_protseq_ncacn_ip_tcp_open_endpoint to call > > getaddrinfo with NULL for both the ip and port which I guess isn't allowed. > > > > Anyways I altered my code to use a given endpoint instead and now it tells > > me: > > fixme:rpc:RpcMgmtWaitServerListen not waiting for server > > calls to finish > > Ah yes - that one! > > > Does this mean the function just doesn't work? Is there any way around it? > > It does work. After calling RpcMgmtWaitServerListen, just sleep > forever. The RPC function calls come in on a different thread anyway. Ah great, thanks. > > I assume if it was easy to implement it would have already but just in case > > what exactly needs to be done to get it working? > > I was wondering this too, Robert might know. > > > I was also confused by the > > differences between the online git tree and the LXR/what actually gets > > downloaded to my computer. > > > > To be honest I'm pretty new to wine and linux in general but it would be > > absolutely wonderful to get this working. > > Good luck. > > > Thanks in advance - Matt Edlefsen > > Damjan I set my server to sleep right after it starts listening but I still can't connect to it for some reason. You (or anyone else) don't happen to have any example code that you know works that I could start with? Anyways, thanks so much for the help - Matt Edlefsen I'll try running my test code on the latest wine and send it if it works. Is the port open? Damjan
iTunes installer success
iTunes 6.5.2 seems to install ok now, so I marked http://bugs.winehq.org/show_bug.cgi?id=3335 as fixed. Yay Rob... iTunes 7 even seems to install, though its installer tries to run several vbscript custom actions, which of course don't work; wine cheerfully blows past those problems, no idea if they do anything important. ( Apple even has a help page for itunes vbscript install problems on windows, http://docs.info.apple.com/article.html?artnum=304405 ) I wonder if we can convince them to stop using vbscript for their next release... probably not, but it'd be nice if someone who knows them would ask. - Dan -- Wine for Windows ISVs: http://kegel.com/wine/isv
Re: [3/10] WineD3D: Move decoding the vertex declaration to the vertexshader state handler
This particular commit breaks Galactic Civilizations 2 Dark Avatar. Would a trace be helpful? 438c17284138776edbbe9196364ae620bbf01adb is first bad commit commit 438c17284138776edbbe9196364ae620bbf01adb Author: Stefan Dösinger <[EMAIL PROTECTED]> Date: Tue Jan 2 21:31:08 2007 +0100 wined3d: Move decoding the vertex declaration to the vertexshader state handler.
Re: appdb rating inflation
Kari Hurtta wrote: > "Dan Kegel" <[EMAIL PROTECTED]> writes in gmane.comp.emulators.wine.devel: > >> The appdb says >> "Only applications which install and run flawlessly on an out-of-the-box >> Wine installation make it to the Platinum list" > > Yes. Also on front page http://appdb.winehq.org/ on first item: > > The Top-10 Platinum List > > Ragnarok Online All Versions > > http://appdb.winehq.org/appview.php?iVersionId=928 > > Maintainer’s Rating: Platinum > > > Description:What was not tested > > * Installation. That was not necessary because I >already installed it in Windows - I'm just running >RO from the Windows partition. > > > > So that appdb classification is complete garbage. > > If Platinum requires that installation works out of box, and > tester did even tested installation and still gives platinium. This App is definately not platinum. It does not "run flawlessly out of the box". I changed the maintainer rating to gold > > > So first item on http://appdb.winehq.org/ says "don't trust me". > > / Kari Hurtta > > > ( Some other maintenaivers have give rating 'Garbage' for this application > :-) ) Testing results are different from maintainer ratings although they use the same scale (in other words your results may vary) -- Tony Lambregts
Re: appdb rating inflation
On 1/3/07, Tony Lambregts <[EMAIL PROTECTED]> wrote: First off I think that the AppDB is for users. It is meant to help them run their programs and the rating system is meant to help people know how well that program can be made to run Yes, absolutely. No-CD cracks are not in themselves illegal. Using them can only be illegal if you use them to use a program that do not have the right to run. The DMCA makes nearly all copy protection circumvention illegal in the USA, iirc. Gold is for programs that _can_ be made to run _flawlessly_ but require a how-to (If that is changing winecfg to override dlls or use a no-cd crack then I am OK with that) Hmm. I can see the logic of that, but "gold" seems to me to imply "really good", and anything that requires a howto can't be great for the average user. I think it's worth considering making "no howto needed" be a requirement for gold. > How about this: I hear that Alexandre is going to > be working on implementing copy protection soon. > Once he has that implemented for at least one > popular application, how about we revisit the appdb > ratings question? > It won't change things much except that some programs will be elevated from gold to platinum. It might be a good time to consider purging all mention of cracks and no-cd hacks from the appdb, to make it less likely that Wine be associated with potentially illegal or unsavory activities. - Dan
Re: appdb rating inflation
Dan Kegel wrote: First off I think that the AppDB is for users. It is meant to help them run their programs and the rating system is meant to help people know how well that program can be made to run > I dislike the idea of adding even more rating levels > (diamond, etc.); that just adds to confusion. I have to agree with this Platinum already _is_ "works flawless out of the box" no changes to anything. > > Also, I am dismayed that some people think cracks are > OK. They're illegal, last time I checked, and I don't > think winehq should advocate their use. No-CD cracks are not in themselves illegal. Using them can only be illegal if you use them to use a program that do not have the right to run. Gold is for programs that _can_ be made to run _flawlessly_ but require a how-to (If that is changing winecfg to override dlls or use a no-cd crack then I am OK with that) Silver is for programs that work but are flawed in some minor respect. Bronze is for program can be used but have serious flaws. > > How about this: I hear that Alexandre is going to > be working on implementing copy protection soon. > Once he has that implemented for at least one > popular application, how about we revisit the appdb > ratings question? > > It won't change things much except that some programs will be elevated from gold to platinum. -- Tony Lambregts.
automatic gecko download failing
Is it obvious to anyone where the error is in this?
(trace ole, urlmon and mshtml)
trace:ole:DllMain 0x6055 0x8 (nil)
trace:ole:DllMain (0x6075,8,(nil))
trace:ole:DllMain 0x6055 0x1 0x1
trace:ole:DllMain (0x6075,1,0x1)
trace:ole:OleInitialize ((nil))
trace:ole:CoInitializeEx ((nil), 2)
trace:ole:CoInitializeEx () - Initializing the COM libraries
trace:ole:RunningObjectTableImpl_Initialize
trace:ole:apartment_construct creating new apartment, model=2
trace:ole:apartment_construct Created apartment on OXID 80009
trace:ole:apartment_get_or_create Created main-threaded apartment with
OXID 80009
trace:ole:OleInitialize () - Initializing the OLE libraries
trace:ole:OLEClipbrd_Initialize ()
trace:ole:CoRegisterMessageFilter (0x16eb60, (nil))
trace:ole:CoLockObjectExternal pUnk=0x1898f2, fLock=TRUE,
fLastUnlockReleases=FALSE
trace:ole:get_stub_manager_from_object not found for object 0x1898f2
trace:ole:new_stub_manager Created new stub manager (oid=1) at 0x18a6c0
for object with IUnknown 0x1898f2
trace:ole:stub_manager_ext_addref added 1 refs to 0x18a6c0 (oid 1), rc
is now 1
trace:ole:stub_manager_int_release after 1
trace:ole:RegisterDragDrop (0x1002e,0x1898f2)
trace:ole:CoLockObjectExternal pUnk=0x189388, fLock=TRUE,
fLastUnlockReleases=FALSE
trace:ole:get_stub_manager_from_object not found for object 0x189388
trace:ole:new_stub_manager Created new stub manager (oid=2) at 0x190138
for object with IUnknown 0x189388
trace:ole:stub_manager_ext_addref added 1 refs to 0x190138 (oid 2), rc
is now 1
trace:ole:stub_manager_int_release after 1
trace:ole:RegisterDragDrop (0x10040,0x189388)
trace:ole:CoLockObjectExternal pUnk=0x18941c, fLock=TRUE,
fLastUnlockReleases=FALSE
trace:ole:get_stub_manager_from_object not found for object 0x18941c
trace:ole:new_stub_manager Created new stub manager (oid=3) at 0x191268
for object with IUnknown 0x18941c
trace:ole:stub_manager_ext_addref added 1 refs to 0x191268 (oid 3), rc
is now 1
trace:ole:stub_manager_int_release after 1
trace:ole:RegisterDragDrop (0x10044,0x18941c)
trace:ole:CoCreateInstance (rclsid=
{25336920-03f9-11cf-8fd0-00aa00686f13}, pUnkOuter=(nil),
dwClsContext=0005, riid={---c000-0046},
ppv=0x33f6b4)
trace:ole:CoGetClassObject
CLSID: {25336920-03f9-11cf-8fd0-00aa00686f13},
IID:{0001---c000-0046}
trace:ole:WINE_StringFromCLSID 0x44bb30-
>{25336920-03F9-11CF-8FD0-00AA00686F13}
trace:urlmon:DllMain 0x60e0 0x8 (nil)
trace:urlmon:DllMain 0x60e0 0x1 (nil)
trace:urlmon:CoInternetGetSession (0 0x33ed20 0)
trace:urlmon:InternetSession_RegisterNameSpace (0x60e22b9c {79eac9e7-
baf9-11ce-8c82-00aa004ba90b} L"file" 0 (nil) 0)
trace:urlmon:InternetSession_RegisterNameSpace (0x60e22b94 {79eac9e3-
baf9-11ce-8c82-00aa004ba90b} L"ftp" 0 (nil) 0)
trace:urlmon:InternetSession_RegisterNameSpace (0x60e22b8c {79eac9e2-
baf9-11ce-8c82-00aa004ba90b} L"http" 0 (nil) 0)
trace:urlmon:InternetSession_Release ()
trace:ole:COMPOBJ_DLLList_Add
trace:mshtml:DllGetClassObject (CLSID_HTMLDocument {0001---
c000-0046} 0x33f680)
trace:mshtml:ClassFactory_AddRef (0x1957c0) ref = 1
trace:mshtml:HTMLDocument_Create ((nil) {---
c000-0046} 0x33f6b4)
trace:mshtml:HTMLDocument_QueryInterface (0x195db8)->(IID_IUnknown,
0x33f6b4)
trace:mshtml:HTMLDocument_AddRef (0x195db8) ref = 1
trace:mshtml:load_gecko ()
trace:mshtml:check_version unknown version
trace:mshtml:load_xpcom (L"c:\\Program Files\\wine_gecko")
warn:mshtml:load_xpcom Could not load XPCOM: 126
trace:mshtml:load_mozctl Could not find Mozilla ActiveX Control
trace:mshtml:load_mozilla Could not open key L"Software\\mozilla.org\
\GRE"
trace:ole:DllMain 0x6055 0x2 (nil)
trace:urlmon:CreateURLMoniker ((nil),
L"http://source.winehq.org/winegecko.php";, 0x7ed40a4c)
trace:urlmon:URLMonikerImpl_Construct (0x1984d0,
(null),L"http://source.winehq.org/winegecko.php";)
trace:urlmon:parse_canonicalize_url
(L"http://source.winehq.org/winegecko.php"; 0001 0x1a9a98 2084
0x7ed409f0)
trace:urlmon:parse_schema (L"http://source.winehq.org/winegecko.php";
0x7ed408f0 64 0x7ed408ec)
warn:urlmon:CF_QueryInterface (0x60e22b8c)->({79eac9ec-
baf9-11ce-8c82-00aa004ba90b},0x7ed408e8),not found
trace:urlmon:CF_CreateInstance (0x60e22b8c)->((nil),{79eac9ec-
baf9-11ce-8c82-00aa004ba90b},0x7ed408e8)
trace:urlmon:HttpProtocol_Construct ((nil) 0x7ed408a8)
warn:urlmon:HttpProtocol_QueryInterface not supported interface
{79eac9ec-baf9-11ce-8c82-00aa004ba90b} (*** IInternetProtocolInfo ***)
*** HUH ??? ***
trace:urlmon:HttpProtocol_Release (0x1983f0) ref=0
trace:ole:__CLSIDFromString L"{79EAC9E2-BAF9-11CE-8C82-00AA004BA90B}" ->
0x7ed40810
trace:ole:CoGetClassObject
CLSID: {79eac9e2-baf9-11ce-8c82-00aa004ba90b},
IID:{---c000-0046}
err:ole:CoGetClassObject apartment not initialised
*** HUH ??? ***
TIA
Bill Medland
Re: appdb rating inflation
Dan Kegel wrote: > Ratings can be quite useful for helping people find good apps; > a gold rating should imply > "doesn't need a HOWTO because it pretty much just works". > > Any app that needs a HOWTO is probably running into wine bugs of some sort. You keep forgetting that unlike windows Linux has lots and lots of things that you can configure. Doesn't meant you have to, but you can. This negates any assertions about running as-is. Unless we lock Wine into one particular version of one particular distro with requirement of "not touching anything" then what you described as "platinum rating" might be obtainable. But until we, and the whole Linux world, value freedom of choice, we have to widen all our ratings to include HOWTO as not just possible, but strongly suggested way of making application X work. However I would agree that we need to limit extent of the changes, suggested by HOWTO as "allowed" under platinum and gold ratings. For example should be allowed under all ratings: - Changing sound driver - Disabling openGL/D3D extension (because of buggy application/driver) - Changing windows version - Installing freely available software (that does not require windows) - Altering configuration / settings of an application (as long as this does not compromise quality / operation / features) (in winamp changing from dsound to winmm). - Updating application with publicly available upgrade or patch (does not include any ... "questionable" patches). But things like should not be allowed in platinum: - Native dlls - Extra Wine patches (that are not in the tree or were rejected) - Non-standard means of installation (copy cd content to HDD, using ISO images, copying from somewhere). Besides, every program comes with readme, and some do not work as-is even on windows. Vitaliy.
Re: wined3d: Make CreateFakeGLContext thread safe. [try 2]
Jan Zerebecki wrote: +LeaveCriticalSection(&wined3d_fake_gl_context_cs); +LEAVE_GL(); ... LEAVE_GL(); +LeaveCriticalSection(&wined3d_fake_gl_context_cs); return FALSE; } You can't lock or unlock in different orders as this will create subtle races that could result in deadlocks. -- Rob Shearman
Re: appdb rating inflation
You really expect people to have to read HOWTOs? Windows users certainly don't expect to, why should Wine users? Agreed, we can't attract a serious user base and offer it as a viable alternative to Windows if it requires a howto to get working. It should just work. Windows users trying out linux for the first time expect it to just work, yet linux has its quirks and requires a somewhat technical userbase, which is what in my opinion prevents more users from switching. The lack of certain windows games,punkbuster, and copy protection working in linux is what keeps me from formatting my Windows box and switching %100. Requiring a howto is an inconvenience and a turn-off to new, less technically-inclined, potential converts from the Redmond platform.
Re: [5/8] WineD3D: Readd the strided data trace
Stefan Dösinger wrote: I removed that call accidentally in one of my former patches, but I think it is still a good idea to trace the final strided sources used by drawprim You removed it from a d3d8 fixed function FVF-only codepath, and are adding it back into a shared codepath. That function doesn't work properly with vertex declarations, it will only work with FVFs, which have different strided layout. FVFs use fixed semantic index [u.s.position], vdecl asks the shader for an index [u.s.input[idx]]. Furthermore, the trace isn't needed for declarations, because they have their own (better) traces.
Re: compiling simple windows app
xie jason wrote:
can any one help me?
Yes, it looks like you're using the wrong calling convention.
int add(int a, int b)
{
int (*pFunc)(int, int);
This should probably be "int (* __stdcall pFunc)(int, int);"
int retVal;
pFunc=(void*)GetProcAddress(hDLL,"vgMath");
TRACE("((int)%ld,(int)%ld):
forward\n",(LONG)a,(LONG)b);
retVal = pFunc(a,b);
TRACE("Returned (%ld)\n",(LONG)retVal);
return retVal;
}
.spec is
1 stdcall add( long long ) vgMath
--
Rob Shearman
Re: appdb rating inflation
Louis wrote: 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. You really expect people to have to read HOWTOs? Windows users certainly don't expect to, why should Wine users? Ratings can be quite useful for helping people find good apps; a gold rating should imply "doesn't need a HOWTO because it pretty much just works". Any app that needs a HOWTO is probably running into wine bugs of some sort. - Dan
Re: appdb rating inflation
Alexander Sørnes wrote: Also, I am dismayed that some people think cracks are OK. They're illegal, last time I checked, and I don't think winehq should advocate their use. They might be illegal in the US, but that doesn't mean they are illegal in other countries. Nevertheless, they are illegal in some countries, and any hint of Wine encouraging software piracy will taint our reputation and make it hard to attract serious users. How about this: I hear that Alexandre is going to be working on implementing copy protection soon. Once he has that implemented for at least one popular application, how about we revisit the appdb ratings question? Copy protection is already implemented for some games. When it works for all games, we won't have to link to cracks. :) OK, if you didn't like my original proposal, how about this one: let's not link to any cracks at all from appdb, since they are illegal in some countries and encourage software piracy. Like my original proposal better now? Cracks aside, IMHO any app that requires extreme fiddling doesn't deserve even a gold rating; gold and above should be reserved for "even my grandma (or retarded little brother) could install and use it". - Dan
Re: appdb rating inflation
Frank Richter 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: appdb rating inflation
On Wednesday 03 January 2007 19:37, Jeremy White wrote: > If multiplayer support is broken, how on earth can a > game be considered anything but bronze? A huge chunk > of the functionality is missing! I'd still hold that this depends on the game. Anyway, you're right in principle. What I'd like to see, though, would be an even closer link of appdb to bugzilla. Like "Bug #something prevents app x from being rated 'silver'", or something like that. Only if bugs are available, of course, but I think this'd give (prospective) wine developers a better idea what needs to be fixed in order to get an app to work with Wine. Cheers, Kai -- Kai Blin, WorldForge developerhttp://www.worldforge.org/ Wine developer http://wiki.winehq.org/KaiBlin/ -- Will code for cotton. pgpgr5zKgUOw5.pgp Description: PGP signature
Re: [2/2] WineD3D: Re-download dirty GL surfaces
Stefan Dösinger wrote: > > Am 03.01.2007 um 02:48 schrieb Phil Costin: > >> This patch enables the forced re-downloading of dirty GL surfaces. >> >> It requires [1/2] WineD3D: Mark GL Surface Clean after Fresh Surface >> Download and is the first step toward supporting gamma-corrected >> (sRGB) >> texture sampling support. >> >> Thanks to Stefan Dösinger for his advice in IRC during the >> implementation of >> these 2 patches. >> >> > You will have to bind the surface's texture to gl to be able to > download the surface. If the texture name in glDescription is 0 you > don't have to download. Select a proper texture unit(e.g. 0) before > binding and mark that sampler dirty to force drawprim to restore it > later. Thanks Stefan. I'll take this into account when I re-check everything. Regards, Phil
Re: [1/2] WineD3D: Mark GL Surface Clean after Fresh Surface Download
Peter Oberndorfer wrote: > On Wednesday 03 January 2007 02:48, Phil Costin wrote: >> This patch resets the SFLAG_GLDIRTY flag for a surface once the GL >> surface data has been refreshed in surface_download_data(). >> >> Thanks to Stefan Dösinger for his advice in IRC during the implementation >> of these 2 patches. > >> diff --git a/dlls/wined3d/surface.c b/dlls/wined3d/surface.c >> index 031d320..5cb9bf6 100644 >> --- a/dlls/wined3d/surface.c >> +++ b/dlls/wined3d/surface.c >> @@ -142,6 +142,8 @@ static void surface_download_data(IWineD >> } >> } >> } >> + /* No longer dirty */ >> + This->Flags &= SFLAG_GLDIRTY; > I think there is a ~ missing here, > else everything but the dirty flag will be cleared. >> } >> } > > Greetings Peter Thanks Peter, You are correct, it worked its way in there. It's taken from a larger patch I'm working on and I didn't spot it immediately. I will re-submit these patches (1 and 2) when I have ironed out a few overall remaining issues I have. Regards, Phil
Re: appdb rating inflation
On 03 Jan 2007 16:34:21 +0200, Kari Hurtta <[EMAIL PROTECTED]> wrote: "Dan Kegel" <[EMAIL PROTECTED]> writes in gmane.comp.emulators.wine.devel: > The appdb says > "Only applications which install and run flawlessly on an out-of-the-box > Wine installation make it to the Platinum list" Yes. Also on front page http://appdb.winehq.org/ on first item: The Top-10 Platinum List Ragnarok Online All Versions http://appdb.winehq.org/appview.php?iVersionId=928 Maintainer's Rating:Platinum Description:What was not tested * Installation. That was not necessary because I already installed it in Windows - I'm just running RO from the Windows partition. So that appdb classification is complete garbage. If Platinum requires that installation works out of box, and tester did even tested installation and still gives platinium. So first item on http://appdb.winehq.org/ says "don't trust me". / Kari Hurtta ( Some other maintenaivers have give rating 'Garbage' for this application :-) ) I agree, the rating isn't correct. We aren't going to be able to avoid issues with mis-rated applications though, so discussing language changes is only going to clarify the issue not entirely prevent them. In this case the maintainer of the application should be made aware of this issue and should take care of correcting the rating. Chris
Re: appdb rating inflation
Onsdag 03 januar 2007 19:08, skrev Dan Kegel: > I dislike the idea of adding even more rating levels > (diamond, etc.); that just adds to confusion. > > Also, I am dismayed that some people think cracks are > OK. They're illegal, last time I checked, and I don't > think winehq should advocate their use. They might be illegal in the US, but that doesn't mean they are illegal in other countries. And, believe it or not, most people in the world do not live in the US. Besides, there is a difference between 'illegal' and 'immoral'. Is it immoral to play games you have legally bought? > > How about this: I hear that Alexandre is going to > be working on implementing copy protection soon. > Once he has that implemented for at least one > popular application, how about we revisit the appdb > ratings question? Copy protection is already implemented for some games. When it works for all games, we won't have to link to cracks. :) Regards, Alexander N. Sørnes
compiling simple windows app
hi all,
I was trying to compile a simple windows
application using winelib. it crashs and returns:
err:seh:setup_exception stack overflow 12 bytes in
thread 0009 eip 60169224 esp 00230ff4 stack
0x231000-0x34
I first convert a .dll, which contains a simple add
function (int add(int a, int b)) to be .dll.so. And
then I compile a simple program which calls this
function. I am able to compile it properly. but when i
run it, it shows above error message.
-.h is --
int __stdcall add(int a, int b);
.c is
HMODULE hDLL=0; /* DLL to call */
#ifdef __i386__
#define GET_THIS(t,p) t p;\
__asm__ __volatile__ ("movl %%ecx, %0" : "=m" (p))
#endif
BOOL WINAPI DllMain(HINSTANCE hinstDLL, DWORD
fdwReason, LPVOID lpvReserved)
{
TRACE("(0x%p, %ld,
%p)\n",hinstDLL,fdwReason,lpvReserved);
if (fdwReason == DLL_WINE_PREATTACH) return FALSE; /*
prefer native version */
if (fdwReason == DLL_PROCESS_ATTACH)
{
hDLL = LoadLibraryA( "libjason.dll" );
printf("load dll\n");
TRACE(":Forwarding DLL (libJason.dll) loaded
(%ld)\n",(LONG)hDLL);
}
else if (fdwReason == DLL_PROCESS_DETACH)
{
FreeLibrary( hDLL );
TRACE(":Forwarding DLL (libJason.dll) freed\n");
}
return TRUE;
}
int add(int a, int b)
{
int (*pFunc)(int, int);
int retVal;
pFunc=(void*)GetProcAddress(hDLL,"vgMath");
TRACE("((int)%ld,(int)%ld):
forward\n",(LONG)a,(LONG)b);
retVal = pFunc(a,b);
TRACE("Returned (%ld)\n",(LONG)retVal);
return retVal;
}
.spec is
1 stdcall add( long long ) vgMath
can any one help me?
thanks
Send instant messages to your online friends http://au.messenger.yahoo.com
Re: appdb rating inflation
"Dan Kegel" <[EMAIL PROTECTED]> writes in gmane.comp.emulators.wine.devel: > The appdb says > "Only applications which install and run flawlessly on an out-of-the-box > Wine installation make it to the Platinum list" Yes. Also on front page http://appdb.winehq.org/ on first item: The Top-10 Platinum List Ragnarok Online All Versions http://appdb.winehq.org/appview.php?iVersionId=928 Maintainer’s Rating:Platinum Description:What was not tested * Installation. That was not necessary because I already installed it in Windows - I'm just running RO from the Windows partition. So that appdb classification is complete garbage. If Platinum requires that installation works out of box, and tester did even tested installation and still gives platinium. So first item on http://appdb.winehq.org/ says "don't trust me". / Kari Hurtta ( Some other maintenaivers have give rating 'Garbage' for this application :-) )
Re: appdb rating inflation
Dan Kegel wrote: > I dislike the idea of adding even more rating levels > (diamond, etc.); that just adds to confusion. I agree. I also think that most Wine enthusiasts are on crack when it comes to ratings. The fact that an app works well for *my purposes* does *not* make it Gold in my not so humble opinion. If multiplayer support is broken, how on earth can a game be considered anything but bronze? A huge chunk of the functionality is missing! This has long been a pet peeve of mine. I remember a post to Slashdot long ago where someone claimed: "Microsoft Office works perfectly!" The reality was that if you installed it on Windows, copied the files (including a bunch of Windows DLLs), hacked the registry and a bunch of other things, you could get it to start. But then if you typed anything or tried to save a file or did anything else, it crashed and burned. Perfect? Yeah, right. I hate to yell at people for being too enthusiastic, but setting expectations high is a recipe for failure. Setting them low gives you room to exceed expectations. Cheers, Jeremy
Re: appdb rating inflation
Dan Kegel wrote: Also, I am dismayed that some people think cracks are OK. They're illegal, last time I checked, and I don't think winehq should advocate their use. I've never heard anything about them being illegal over here (which means even if they are it's one of those "retarded laws" that absoloutely zero people follow due to it being something that has been implemented wrongly shown by it's complete non-existant follow-up). Copy protection is invasive, annoying, technically for the most part useless and makes most Wine apps useless without a patch for it. Ex.
Re: appdb rating inflation
I dislike the idea of adding even more rating levels (diamond, etc.); that just adds to confusion. Also, I am dismayed that some people think cracks are OK. They're illegal, last time I checked, and I don't think winehq should advocate their use. How about this: I hear that Alexandre is going to be working on implementing copy protection soon. Once he has that implemented for at least one popular application, how about we revisit the appdb ratings question?
Re: appdb rating inflation
I dislike the idea of adding even more rating levels (diamond, etc.); that just adds to confusion. Also, I am dismayed that some people think cracks are OK. They're illegal, last time I checked, and I don't think winehq should advocate their use. How about this: I hear that Alexandre is going to be working on implementing copy protection soon. Once he has that implemented for at least one popular application, how about we revisit the appdb ratings question?
Re: appdb rating inflation
On Wednesday 03 January 2007 17:17, Alexander Nicolaysen Sørnes wrote: > If we are indeed to make further changes, I suggest that we allow a few > cosmetic errors in the Gold and Platinum ratings, but leave them otherwise > unchanged, then add a new 'ultimate' rating that allows no changes or > flaws. We could call it 'Titanium', for example (or why not 'Roentgenium' > :) ), or perhaps Diamond. In that case we should rename Platinum to > Emerald or Ruby. > > That way users not fearing a few extra settings can look for anything rated > Gold and above, while the out-of-the-box lovers can look for Platinum and > above. It should satisfy most people. The thing is, if adding single DLL > override or crack is all that keeps a user from having a Windows copy > around, he is likely to enter that dll override or copy the crack. Kind of sounds sensible. That would give us (borrowed from Ivan's post) Paying customer - Diamond level, maybe Platinum level, decided on a case by case basis. New user, unfamilar with wine - Diamond and Platinum level. Wine expert user - Diamond, Platinum and Gold level, maybe Silver level, decided on case by case basis (e.g. 1602 A.D. blows up in multiplayer, works without flaws that don't exist in win32 in singleplayer) Developer - All ratings. Personally, I kind of like the Diamond/Emerald naming, but in the end I don't care what they're called. I think it'd be kind of nice for people to see what errors stop the app from reaching the next best rating, so going back to my 1602 A.D. example, if I don't care about multiplayer being broken, the app is essentially Diamond for me. My 2 cents, Kai -- Kai Blin, WorldForge developerhttp://www.worldforge.org/ Wine developer http://wiki.winehq.org/KaiBlin/ -- Will code for cotton. pgp06Cry1JXdw.pgp Description: PGP signature
Re: crtdll: Declare some variables static
Robert Shearman wrote: > > However, it had an implicit "... but they are exported from this DLL." > Right. My brain has just caught up with you. As you can see, I'm trawling through the dlls looking for anything I can legitimately take out of the global namespace. I am trying to be as careful as I can, and am unlikely to make the same mistake twice. But I ask people to be patient with me if I stumble a bit. I thought this patch might be questionable, but it just seemed easier to publish it and have it rejected than to discuss it on wine-devel in advance. I'm definitely going to be more wary of functions that appear in spec files, from now on. Thanks to you and Marcus for your help. -- Andy.
Re: crtdll: Declare some variables static
Andrew Talbot wrote: Marcus Meissner wrote: Err, why? They are clearly exported from the .spec file and you just killed the exports? They likely are used by Windows programs. Ciao, Marcus Hi Marcus, I trusted the comment just before the declarations, which says: /* The following data items are not exported from msvcrt */. However, it had an implicit "... but they are exported from this DLL." -- Rob Shearman
Re: crtdll: Declare some variables static
Marcus Meissner wrote: > Err, why? > > They are clearly exported from the .spec file and you just killed the > exports? > > They likely are used by Windows programs. > > Ciao, Marcus Hi Marcus, I trusted the comment just before the declarations, which says: /* The following data items are not exported from msvcrt */. -- Andy.
Re: [3/10] WineD3D: Move decoding the vertex declaration to the vertexshader state handler
Am 03.01.2007 um 14:07 schrieb Ivan Gyurdiev: Regarding the concern of storing the decoded strided data after finishing drawing: This is intentional, the decoded vertex declaration will remain valid after the draw is finished and the arrays loaded. Future draws can use it, if the state is not dirtified again. This sounds like a good idea... Wrt the upward references: When we have multithreading with multiple contexts we will need a per-context tracking of most of the stuff we have in the device now(last_was_rhw, ...). This structure does not exist yet, and I do not see a point in passing the device impl to every function when we can get it from the stateblock too. I still think this caching stuff needs to go into its own structure [ maybe device->cache or something like that ]. I can see how it's a bit different from the standard stateblock data, since it's just a cache, rather than something that's set/get by the application - cache state vs configured state. It's not so clear to me that this is all per-thread data - the strided streams are directly tied to the vertex declaration and stream data, which is in turn shared across threads as part of the stateblock. The strided streams can contain opengl vbo names. They are per gl context, but I think they are shared with display list sharing (Otherwise we'll get an issue with them with multithreading). A seperate structure in the device sounds like a good idea. I'd prefer to keep them were they are until the state management move is finished though. Change one thing after the other :-)
Re: appdb rating inflation
Onsdag 03 januar 2007 04:00, skrev Dan Kegel: > As Chris Morgan pointed out, > http://appdb.winehq.org/help/?sTopic=maintainer_ratings > might need clarification. It now says > > -- snip -- > Platinum > An application can be rated as Platinum if it installs and runs "out > of the box" No changes required to winecfg. > > Gold > Application works flawlessly with some DLL overrides or other > settings, crack etc. > > Silver > Application works excellently for 'normal' use; a game works fine in > single-player but not in multi-player, Windows Media Player works fine > as a plug-in and stand-alone player, but can't handle DRM etc. > -- snip -- > > I'd like to change this to make it clear that cracks are a no-no for > anything Silver and above, and make Platinum and Gold rather > more rigorous: > > -- snip -- > Platinum > Platinum applications install normally and run flawlessly. > 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. > > Gold > Gold applications install normally and run well. > Some cosmetic problems may be present, but they should not be noticable > to the average user. > No manual editing of files, no winecfg settings, no native DLLs, no > third-party install scripts, and no cracks are allowed for a Gold > rating. > > Silver > Application installs and works well for 'normal' use, but some features may > be broken. For instance, a game that works fine in single-player but > not in multi-player, > or a media player that works fine for mp3 files but not for DRM-protected > files. No manual editing of files or cracks are allowed for Silver ratings, > but winecfg settings, native DLLs, or third-party install scripts may be > required. > -- snip -- > > What do people think? > - Dan The ratings should indeed be specified more clearly, but I don't like all of your suggestions for changing the definitions. If you disallow cracks even in the Silver rating, then games that run virutally flawlessly will be rated the same as those that run with severe speed problems, missing text etc. For most users, downloading a crack is not a problem, at least not if the HOWTO gives a link to it. Besides, it is not any more difficult to copy a crack than it is to copy a dll: the only difference is the file extension. Currently, the only difference between Gold and Platinum is that the Gold rating allows all sorts of changes to the program or Wine's settings. If we are indeed to make further changes, I suggest that we allow a few cosmetic errors in the Gold and Platinum ratings, but leave them otherwise unchanged, then add a new 'ultimate' rating that allows no changes or flaws. We could call it 'Titanium', for example (or why not 'Roentgenium' :) ), or perhaps Diamond. In that case we should rename Platinum to Emerald or Ruby. That way users not fearing a few extra settings can look for anything rated Gold and above, while the out-of-the-box lovers can look for Platinum and above. It should satisfy most people. The thing is, if adding single DLL override or crack is all that keeps a user from having a Windows copy around, he is likely to enter that dll override or copy the crack. Regards, Alexander N. Sørnes
Re: crtdll: Declare some variables static
On Wed, Jan 03, 2007 at 03:45:28PM +, Andrew Talbot wrote: > Changelog: > crtdll: Declare some variables static. Err, why? They are clearly exported from the .spec file and you just killed the exports? They likely are used by Windows programs. Ciao, Marcus
Re: Oleview: correct representation of unions
On Thu, 28 Dec 2006, Konstantin Kondratyuk wrote: > Hello, > > this patch corrects representation of unions for old compilers (gcc 2.95) > For example: > (union).field - is not supported by gcc 2.95 > union.field - is supported This is strange. I compile Wine with gcc 2.95 weekly but never encountered this problem. Also note that the U(x) macro would need to be fixed in other places too (include/wine/test.h for instance). -- Francois Gouget <[EMAIL PROTECTED]> http://fgouget.free.fr/ Avoid the Gates of Hell - use Linux.
Re: appdb rating inflation
Jan Zerebecki wrote: On Tue, Jan 02, 2007 at 07:00:20PM -0800, Dan Kegel wrote: I'd like to change this to make it clear that cracks are a no-no for anything Silver and above, and make Platinum and Gold rather more rigorous: I don't think that is helpful. What is more important: to know that it works only with cosmetic problems after quite some work(arounds) or that it does not work at all without workarounds and to have no information about how it works with workarounds? I think that depends on your target audience. Paying customer - no workarounds, misleading advertising New user, unfamiliar with wine - no workarounds, user will be confused, will not understand Wine expert user - doesn't care about rating, wants to see the HowTo instructions and get the app to work Developer - doesn't care about rating, wants to see how close we are to making app work (what workarounds are left, etc..)
Re: appdb rating inflation
On Tue, Jan 02, 2007 at 07:00:20PM -0800, Dan Kegel wrote: > I'd like to change this to make it clear that cracks are a no-no for > anything Silver and above, and make Platinum and Gold rather > more rigorous: I don't think that is helpful. What is more important: to know that it works only with cosmetic problems after quite some work(arounds) or that it does not work at all without workarounds and to have no information about how it works with workarounds? > Platinum > Platinum applications install normally and run flawlessly. > 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. > > Gold > Gold applications install normally and run well. > Some cosmetic problems may be present, but they should not be noticable > to the average user. > No manual editing of files, no winecfg settings, no native DLLs, no > third-party install scripts, and no cracks are allowed for a Gold > rating. AFAIK Platinum was introduced because we wanted to have a rating for "you can get it to work somehow with patches to wine and other workarounds and only cosmetic problems remain" and one for "works without any changes and has no problems on the usual configurations". This also means that a app that does not work at all with winenas (or some of the other more obscure sound drivers) but has no problems with e.g. winealsa should be able to be Platinum. Jan
Re: [3/10] WineD3D: Move decoding the vertex declaration to the vertexshader state handler
Regarding the concern of storing the decoded strided data after finishing drawing: This is intentional, the decoded vertex declaration will remain valid after the draw is finished and the arrays loaded. Future draws can use it, if the state is not dirtified again. This sounds like a good idea... Wrt the upward references: When we have multithreading with multiple contexts we will need a per-context tracking of most of the stuff we have in the device now(last_was_rhw, ...). This structure does not exist yet, and I do not see a point in passing the device impl to every function when we can get it from the stateblock too. I still think this caching stuff needs to go into its own structure [ maybe device->cache or something like that ]. I can see how it's a bit different from the standard stateblock data, since it's just a cache, rather than something that's set/get by the application - cache state vs configured state. It's not so clear to me that this is all per-thread data - the strided streams are directly tied to the vertex declaration and stream data, which is in turn shared across threads as part of the stateblock. === Note: you just made drawPrimitiveTraceDataLocations into dead code. (previously called in d3d8 fixed function code path). I don't care much for this function, but please remove it if getting rid of its callers.
Re: [PATCH] [DbgHelp]: implemented 64 bit versions of EnumerateLoadedModules
You should make the A function call the W one, not the other way around. in theory yes in practice, it would require rewriting all module storage, lookup... with unicode strings which is on my todo list, but with a very low priority. BTW, all the module handling code in dbghelp is already working this way (W calling A). So, I think it's acceptable the way the patch is coded. A+
Re: Reinhard Karcher : user32: Speed improvement for 16bit comm support.
Robert Shearman <[EMAIL PROTECTED]> writes:
>> diff --git a/dlls/user32/comm16.c b/dlls/user32/comm16.c
>> index 9329c82..0164196 100644
>> --- a/dlls/user32/comm16.c
>> +++ b/dlls/user32/comm16.c
>> @@ -719,9 +719,8 @@ INT16 WINAPI GetCommError16(INT16 cid,LP
>> stol = (unsigned char *)COM[cid].unknown + COMM_MSR_OFFSET;
>> COMM_MSRUpdate( ptr->handle, stol );
>> - if (lpStat) {
>> -lpStat->status = 0;
>> -
>> + if (lpStat) {
>> + lpStat->status = 0;
>> SleepEx(1,TRUE);
>> lpStat->cbOutQue = comm_outbuf(ptr);
>
> This patch doesn't seem to do what it says it does.
Indeed, thanks for spotting this. It's the second time this happens,
it seems that Emacs diff mode cannot be trusted to apply hunks
correctly :-(
--
Alexandre Julliard
[EMAIL PROTECTED]
Re: Reinhard Karcher : user32: Speed improvement for 16bit comm support.
Alexandre Julliard wrote:
Module: wine
Branch: master
Commit: dff43b732b10e603f3aee38db2f684dc7404aa4e
URL:
http://source.winehq.org/git/wine.git/?a=commit;h=dff43b732b10e603f3aee38db2f684dc7404aa4e
Author: Reinhard Karcher <[EMAIL PROTECTED]>
Date: Mon Jan 1 17:45:06 2007 +0100
user32: Speed improvement for 16bit comm support.
---
dlls/user32/comm16.c |5 ++---
1 files changed, 2 insertions(+), 3 deletions(-)
diff --git a/dlls/user32/comm16.c b/dlls/user32/comm16.c
index 9329c82..0164196 100644
--- a/dlls/user32/comm16.c
+++ b/dlls/user32/comm16.c
@@ -719,9 +719,8 @@ INT16 WINAPI GetCommError16(INT16 cid,LP
stol = (unsigned char *)COM[cid].unknown + COMM_MSR_OFFSET;
COMM_MSRUpdate( ptr->handle, stol );
- if (lpStat) {
- lpStat->status = 0;
-
+ if (lpStat) {
+ lpStat->status = 0;
SleepEx(1,TRUE);
lpStat->cbOutQue = comm_outbuf(ptr);
This patch doesn't seem to do what it says it does.
--
Rob Shearman
Re: wined3d: state_pointsprite should apply to all texture units
Am 03.01.2007 um 02:27 schrieb Tomas Carnecky:
Chris Robinson wrote:
+for (i = 0; i < GL_LIMITS(texture_stages); i++) {
+/* Note the WINED3DRS value applies to all textures, but
GL has one
+ * per texture, so apply it now ready to be used!
+ */
+if (GL_SUPPORT(ARB_MULTITEXTURE)) {
+GL_EXTCALL(glActiveTextureARB(GL_TEXTURE0_ARB + i));
+checkGLcall("glActiveTextureARB");
+} else if (i>0) {
+FIXME("Program using multiple concurrent textures
which this opengl implementation doesn't support\n");
+}
I'd do that '} else if (i == 1) {', otherwise you'll print a whole lot
FIXME's, and maybe add a 'break', since it doesn't make sense to call
glTexEnvi() over and over for the same texture.
If we do not support multittexturing GL_LIMITS(texture_stages) should
be 1, thus the else path shouldn't be needed.
Re: [2/2] WineD3D: Re-download dirty GL surfaces
Am 03.01.2007 um 02:48 schrieb Phil Costin: This patch enables the forced re-downloading of dirty GL surfaces. It requires [1/2] WineD3D: Mark GL Surface Clean after Fresh Surface Download and is the first step toward supporting gamma-corrected (sRGB) texture sampling support. Thanks to Stefan Dösinger for his advice in IRC during the implementation of these 2 patches. You will have to bind the surface's texture to gl to be able to download the surface. If the texture name in glDescription is 0 you don't have to download. Select a proper texture unit(e.g. 0) before binding and mark that sampler dirty to force drawprim to restore it later.
Re: wined3d: state_pointsprite should apply to all texture units
Am 03.01.2007 um 09:33 schrieb H. Verbeet: On 03/01/07, Chris Robinson <[EMAIL PROTECTED]> wrote: Updated with the change suggested by Tomas. Does this work when there's no texture bound to the unit? In theory we should always have a texture bound to all supported units up to unit 7, either a real texture or a dummy texture.
Re: [1/2] WineD3D: Mark GL Surface Clean after Fresh Surface Download
On Wednesday 03 January 2007 02:48, Phil Costin wrote: > This patch resets the SFLAG_GLDIRTY flag for a surface once the GL surface > data has been refreshed in surface_download_data(). > > Thanks to Stefan Dösinger for his advice in IRC during the implementation of > these 2 patches. > diff --git a/dlls/wined3d/surface.c b/dlls/wined3d/surface.c > index 031d320..5cb9bf6 100644 > --- a/dlls/wined3d/surface.c > +++ b/dlls/wined3d/surface.c > @@ -142,6 +142,8 @@ static void surface_download_data(IWineD > } > } > } > + /* No longer dirty */ > + This->Flags &= SFLAG_GLDIRTY; I think there is a ~ missing here, else everything but the dirty flag will be cleared. > } > } Greetings Peter
Re: ppviewer.exe MSI failure (PowerPoint 2k3): HowTo assemble a lynch mob?
Robert Shearman wrote: Ben Hodgetts (Enverex) wrote: James Hawkins wrote: This installer works fine for me with git wine. It is probably the "-2140172307" bug (http://bugs.winehq.org/show_bug.cgi?id=6998 - Tested by me and Vitaliy) doing it. Basically it started happening after 0.9.27 to newer installshield apps. They simply stop installing without error but it wasn't always and was at a random point (then patches after .28 caused it to give a crazy error message and now a patch has been submitted to fix it). The errors seen in the terminal were normal, you tend to get a lot when installing things but they are rarely critical. PowerPoint Viewer 2003 isn't an InstallShield installer. Ah, sorry, was just taking a stab in the dark. Ex.
Re: appdb rating inflation
Frank Richter wrote: 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. Giving a set of points may lead to some people think "hey to run MyApplication I just have to . It's not in the list, so lets rate it platinum!". So maybe put some generalized criterium in front of that list: "The application should install and run on a fresh, unmodified Wine, from original installation media. That means, among other things, no manual editing of files, ..." OTOH, there are not much "obscure workarounds" not covered by that list. Manually editing the registry might be one that should be be disallowed. Also, you mentioned apps that only run as root; this might be worthwhile to disallow, too. -f.r. I'd have to disagree on the NoCD bit simply because the AppDB will only ever end up with a handful of Platinum games at best due to the fact that copy-protection code will not be implemented for quite some time, if ever when really other than that easily workaroundable point the game may work perfectly. Ex.
Re: quartz: add implementations for AmpFactorToDB and DBToAmpFactor
Robert Reif <[EMAIL PROTECTED]> writes: > For whatever reason Microsoft decided not to use the standard > equations like the rest of the world. I assume it was to eliminate > the need for floating point calculations. Actually you could use the > same equation that the generated the table to go from dB to amp but > you can't use an equation to go the other way around because of the > weird roundoff errors that result from using a lookup table. Yes, but does that really make a difference for real apps? Do we really need to duplicate the roundoff errors? -- Alexandre Julliard [EMAIL PROTECTED]
Re: ppviewer.exe MSI failure (PowerPoint 2k3): HowTo assemble a lynch mob?
Ben Hodgetts (Enverex) wrote: James Hawkins wrote: This installer works fine for me with git wine. It is probably the "-2140172307" bug (http://bugs.winehq.org/show_bug.cgi?id=6998 - Tested by me and Vitaliy) doing it. Basically it started happening after 0.9.27 to newer installshield apps. They simply stop installing without error but it wasn't always and was at a random point (then patches after .28 caused it to give a crazy error message and now a patch has been submitted to fix it). The errors seen in the terminal were normal, you tend to get a lot when installing things but they are rarely critical. PowerPoint Viewer 2003 isn't an InstallShield installer. -- Rob Shearman
Re: wined3d: state_pointsprite should apply to all texture units
On 03/01/07, Chris Robinson <[EMAIL PROTECTED]> wrote: Updated with the change suggested by Tomas. Does this work when there's no texture bound to the unit?
