July 2002 - Wine-Devel - list.winehq.org

Re: __sparc__ not defined with Forte C

by Alexandre Julliard

Gregg Mattinson <gm138242(a)scot.canada.sun.com> writes: > In regards to the second point (@function vs. 2), something has been bugging me > for a while... Why do the .spec.c files have so much assembly code in them? To > me, it looks like most of it could be replaced with an array and some creative > use of global variables. I doubt it. Many things need to have a very specific layout that cannot be done in plain C. If things are done in assembly there's usually a good reason for that. -- Alexandre Julliard julliard(a)winehq.com

July 16, 2002

Re: OLE classes registration

by Andriy Palamarchuk

--- Steven Edwards <steven_ed4153(a)yahoo.com> wrote: > I dont know very much about ole or COM so if I am > way > wrong just flame me. =) > > Can the regsvr code from comcat be adapted for this? > Rather then implementing more stuff in > winedefaultreg > can we make all of the OLE/COM stuff self-register? > I > think during on of my tests on windows with the wine > dlls that was a problem I encountered and at least > for > comcat it is now fixed. Yes, as was discussed before this is the right way to do it. Anyway, finding out what information to add and and development of the dlls registering process are pretty much independent from each other. Andriy __________________________________________________ Do You Yahoo!? Yahoo! Autos - Get free new car price quotes http://autos.yahoo.com

July 16, 2002

Re: CxxFrameHandler problem

by Steven Edwards

I dont think I can help to much with reimplementing the CxxFrameHandler but if anyone decides to work on it I will set aside plenty of time to help them debug. (Hint, Hint) =) Thanks Steven --- J�rgen_Schmied <juergenschmied(a)lycos.de> wrote: > Hmm, I think these FIXME messages should be > considered > as a real FIXME. The application might throw a > exception > and catch it later as a normal behaviour. As long as > our > implementation of CxxFrameHandler does not behave > right > is has to be fixed. Then we can blame the > application. __________________________________________________ Do You Yahoo!? Yahoo! Autos - Get free new car price quotes http://autos.yahoo.com

July 16, 2002

Re: OLE classes registration

by Steven Edwards

I dont know very much about ole or COM so if I am way wrong just flame me. =) Can the regsvr code from comcat be adapted for this? Rather then implementing more stuff in winedefaultreg can we make all of the OLE/COM stuff self-register? I think during on of my tests on windows with the wine dlls that was a problem I encountered and at least for comcat it is now fixed. Thanks Steven --- Andriy Palamarchuk <apa3a(a)yahoo.com> wrote: > While researching bug 853 I found out that > OleLoadFromStream fails if the specified OLE class > is > not registered. Many our OLE classes are not > registered. Just submitted a patch to register > CLSID_StdFont class which fixes the bug. > > Should I also add the registry etries for all other > OLE classes? > > Thanks, > Andriy > > __________________________________________________ > Do You Yahoo!? > Yahoo! Autos - Get free new car price quotes > http://autos.yahoo.com > __________________________________________________ Do You Yahoo!? Yahoo! Autos - Get free new car price quotes http://autos.yahoo.com

July 16, 2002

AutoCAD2000 again and CreateFiber

by Max

Well, after the patch-hack-or whatever on VirtualQuery, AutoCAD2000 began coming alive ! Some problems yet, but one wonders me in particular : setting window version as win98 or winnt40, app shows an exception stating that CreateFiber function is not implemented; setting as win95 the apps starts quite well. Any idea ? Is there some plan to implement xxxxxFiber functions, or it's too difficult ? BTW, looking for help on the net, i haven't really understood the difference between a regular thread and a fiber (only caught that use of fibers instead of threads is somehow discouraged...) Regards Max

July 16, 2002

VirtualQuery problem... maybe

by Max

After 2 weeks debugging between window$ and wine (sigh), I found a different behaviour of VirtualQuery function : The app queries info about some pages in its code (really dunno why....); in PROTECT field of BASIC_MEMORY_INFO, windows returns a 0x20 value (EXECUTE_READ), but wine returns 0x08 (WRITE_COPY), causing app to hang. I guess there's an error somewhere, as the required info belongs to executable code, so at least should be active some EXECUTE flag; btw, my app checks only that the page has not active NO_ACCESS, WRITECOPY and PAGE_GUARD flags, and behaves badly if find one of them. As a check, I only add an *protect = *protect & 0xffff7fff to GetWin32Prot code, taking so off the WRITECOPY flag only, and the app began starting. As I don't know about anything of linux memory protections (sigh), the question is : is there someone with wnough skllls that want to check it ? :-) Regards Max

July 16, 2002

OLE classes registration

by Andriy Palamarchuk

While researching bug 853 I found out that OleLoadFromStream fails if the specified OLE class is not registered. Many our OLE classes are not registered. Just submitted a patch to register CLSID_StdFont class which fixes the bug. Should I also add the registry etries for all other OLE classes? Thanks, Andriy __________________________________________________ Do You Yahoo!? Yahoo! Autos - Get free new car price quotes http://autos.yahoo.com

July 16, 2002

Re: Avoid crash

by P. Christeas

Dominik Strasser wrote: > I had a crash where This->pTypeInfo was 0. > I didn't investigate the real culprit. > > Changelog: avoid crash on NULL pointer I read your patch; I didn't investigate it either. I think you should put the test inside the ITypeInfo_Release() fn. Your patch may solve this case, but what happens when that fn is mis-called from somewhere else? This is a general matter of programming style. Moreover, you could add some TRACE or warning point. There was a conversation on what to do in such cases (where we could handle a NULL, but M$ may not). I suggest: warn and try to go on..

July 16, 2002

Re: SHLWAPI ole32 (delay-load of dlls)

by Jon Griffiths

--- juergen.schmied(a)debitel.net wrote: > The LoadLibrary call comes from the implementation of DelayLoad Ah, In that case I can see why doing it manually is a waste of time ;-) Cheers, Jon ===== "Don't wait for the seas to part, or messiahs to come; Don't you sit around and waste this chance..." - Live jon_p_griffiths(a)yahoo.com __________________________________________________ Do You Yahoo!? Yahoo! Autos - Get free new car price quotes http://autos.yahoo.com

July 16, 2002

Re: Bug Fix: WM_GETTEXT should return NULL string if LB_GETCURSEL is LB_ERR

by Carl Sopchak

On Monday, July 15, 2002 10:15 pm, wine-devel-request(a)winehq.com wrote: > > If VC does have a "one correct way", while gcc doesn't, shouldn't we > > prefer the VC correct one? > > No - you should the one that is in the C standard. > > > In this case '0' should be ok under ALL circumstances. > (Unless M$ have completely stuffed their compiler) > > > David I'd have to agree with David, that the code should work under all circumstances. So, should this be modified, and another patch submitted? I'd be happy to do that, if it makes life easier... (Reiterating: I'm no C guru, and I know less about unicode, so let me know "the best way", and I'll be happy to change it if needed...) Once again, the code in question: if (unicode) { LPWSTR lpText = (LPWSTR)lParam; lpText[0] = '\0'; } else { LPSTR lpText = (LPSTR)lParam; lpText[0] = '\0'; } return 0; Carl

July 16, 2002