Re: wineconf 2002: final things
does this _really_ mean all active wine-developers are 30-something white males?? Some of us are 20-something :) -James -- James Hatheway [EMAIL PROTECTED] ~ http://www.macadamian.com Software Designer - Macadamian Technologies, Inc. -- Software experts for the world's leading technology companies. Obligatory Geek Expression: Save the Whales, Free the mallocs!
Re: Road to 0.9
* Wine Server Protocols (DONE) it this really done ? I still have some enhancements I think you better send an email to Alexandre then, because he said at the conference that it (Wineserver protocol) is basically finished, we just need to formally freeze it (or something like that, that is not a word for word quote) -James -- James Hatheway [EMAIL PROTECTED] ~ http://www.macadamian.com Software Designer - Macadamian Technologies, Inc. -- Software experts for the world's leading technology companies. Obligatory Geek Expression: Save the Whales, Free the mallocs!
Re: Road to 0.9
* Regression Testing - Francois, Andridy, Patrick, Dimi, Andi, Steven Hmm, Regression Tests development will never finish. Can you define any specific goal for the regression tests you want to accomplish for 0.9? I believe the goal from Alexandre was that he just wanted the frameworks stabilized, with documentation and some sample tests. (I know there is a framework in place, it was demonstrated at the conference, but I'm not sure if the API was frozen or not) -James -- James Hatheway [EMAIL PROTECTED] ~ http://www.macadamian.com Software Designer - Macadamian Technologies, Inc. -- Software experts for the world's leading technology companies. Obligatory Geek Expression: Save the Whales, Free the mallocs!
Re: Road to 0.9
C. Testing apps? I have no real idea what you mean. Sorry, I guess I should have been more clear, I just typed in word for word my brief shorthand notes :) Basically, the idea that we had was the concept of getting users to volunteer to own an app, ie. responsible for yelling when we break an app. This already sort of happens, but never in a formal way. We never decided the details, but I envisiage having one person volunteering to each test their favourite app on every release and filing bugs. (in a way that is helpful, we'll have docs for that) -James -- James Hatheway [EMAIL PROTECTED] ~ http://www.macadamian.com Software Designer - Macadamian Technologies, Inc. -- Software experts for the world's leading technology companies. Obligatory Geek Expression: Save the Whales, Free the mallocs!
Re: Clarification on my call for license change
Several people have asked me to clarify my original post. I just don't understand one thing: How does your company expect to make money once WINE is xGPLed? If all your code has to be contributed back, why should I buy it from your company? Hi, Companies will pay because they want certain functionality to be implemented that isn't there. For example, let's say you are company Foo, who wants their product FooBar for Windows 2000 to work in Linux using WINE. It makes use of some COM related functionality not currently in WINE (like Out-of-proc objects or something) What do you do? I mean, you can't just post on wine-devl and say hey guys, stop making patches for DirectX, we want you to fix this COM stuff and NOW! No way. Do you get your internal staff to do it? Maybe. However, most likely none of them know anything about WINE, so there is a big ramp up time. Or do you hire an outside company to help you out, a WINE developer-for-hire so to speak. That's why companies like Macadamian and CodeWeavers get hired by clients, to get functionality into WINE that would otherwise not get done. It allows the client to focus the fixes in the areas they need for their particular application. Sure, these changes (optionally for BSD license, required for GPL) are made available to competitors, but as far back as I remember and for a while yet I imagine any moderately complex app will always require some fixes to WINE to get it to work perfectly. -James -- James Hatheway [EMAIL PROTECTED] ~ http://www.macadamian.com Software Designer - Macadamian Technologies, Inc. -- Software experts for the world's leading technology companies. Obligatory Geek Expression: Save the Whales, Free the mallocs!
Re: Clarification on my call for license change
Congratulations, you have just explained is why specialized consultants can make a living in the Wine market. However since this with a similar explaination is true in almost any market, I can't say I'm impressed. Sorry. That was perhaps a little rude. I was trying to illustrate a principle not insult you. It was not really aimed at you. Hey, hey, hey, I'm not even *IN* this flame war. Relax. Some guy says how can you make any money with *GPL license and I gave an example. That's it. I haven't even specified my license preference When is Wine-flamewar-license list starting anyway? Remind me not to subscribe. -James -- James Hatheway [EMAIL PROTECTED] ~ http://www.macadamian.com Software Designer - Macadamian Technologies, Inc. -- Software experts for the world's leading technology companies. Obligatory Geek Expression: Save the Whales, Free the mallocs!
Re: (FWD) Announcing wineconf 2002
PS. Does anybody know if a VISA to the US is required for citizens of the European Union countries (like Sweden)? Nope. Check out: http://www.ins.usdoj.gov/graphics/lawenfor/bmgmt/inspect/vwpp.htm Most importantly: What Countries Are in the VWP? The following countries are currently in the program: Andorra, Argentina, Austria, Australia, Belgium, Brunei, Denmark, Finland, France, Germany, Iceland, Ireland, Italy, Japan, Liechtenstein, Luxembourg, Monaco, the Netherlands, New Zealand, Norway, Portugal, San Marino, Singapore, Slovenia, Spain, Sweden, Switzerland, The United Kingdom*, and Uruguay. -James -- James Hatheway [EMAIL PROTECTED] ~ http://www.macadamian.com Software Designer - Macadamian Technologies, Inc. -- Software experts for the world's leading technology companies. Obligatory Geek Expression: Save the Whales, Free the mallocs!
Re: (FWD) Announcing wineconf 2002
On Wed, 6 Feb 2002, Patrik Stridvall wrote: Anybody else interested? People from Macadamian might be going, it all depends on our various schedules. (Right now it is looking like a go, but won't know for sure for a few days) -James -- James Hatheway [EMAIL PROTECTED] ~ http://www.macadamian.com Software Designer - Macadamian Technologies, Inc. -- Software experts for the world's leading technology companies. Obligatory Geek Expression: Save the Whales, Free the mallocs!
Re: Apps DB round 2
Proposals: * Currently the screenshot is in its own column. That's quite bad sometimes: I'll play with this some more. I'm assuming a web design that the average user is going to be at 1024x768. Does anyone really use less than that anymore? (save for web devices of course). Yes, unfortunately... Many public places like libraries,etc. still have terminals with 15 inch monitors at 800x600. -James -- James Hatheway [EMAIL PROTECTED] ~ http://www.macadamian.com Software Designer - Macadamian Technologies, Inc. Software solutions for leading ISVs and e-Business
Re: some unimplemented COM stuff
Hi Malte, We (Macadamian) were working on implementing oleaut32.dll, if you search the archives of WINE HQ around dec 2000 / jan 2001 you can see some of the patches that we submitted. Unfortunately, work has been shelved for the moment, but there is a starting point for you. For IDispatch::Invoke / ITypeInfo::Invoke, there is a patch at: http://www.integrita.com/cgi-local/lwgate.pl/WINE-PATCHES/archives/2000-12/date/article-196.html As well please see discussion of patch at: http://www.integrita.com/cgi-local/lwgate.pl/WINE-DEVEL/archives/2001-01/date/ (with reasons why it wasn't committed, search for invoke) As for your other issues: - typelib registration Requires adding some registry entries. Not too bad, pretty much any COM book will tell you all you need to do. - IDispatch::Invoke() See above - RegisterBindStatusCallback() and probably asyncronous bind contexts Hummm... no idea. - probably a real URL Moniker, not just CreateURLMoniker() using a File Moniker See the Brockschmidt book. Have fun. :-) Seriously, I don't think anyone has done any work on this one or is currently working on this besides the stubbed DLL that is in the tree. -James -- James Hatheway Software Designer - Macadamian Technologies, Inc. [EMAIL PROTECTED] ~ http://www.macadamian.com Funniest Definition found in a Japanese-English Dictionary so far: Moose: Amerika Ushi (American Cow) (should be: mu-su in katakana)
Re: edit control patch
Just one little comment, you should make your diffs using the -u (unified diff) option. (ie. cvs -d $CVSROOT -u controls/edit.c newdiff.diff) That way your patch has "+"s and "-"s instead of ""s. It makes it easier to read what is changing in the patch... (For example, you patch will look something like this instead:) + INT BkMode; + BkMode = GetBkMode(dc); + SetBkMode( dc, OPAQUE); + SetBkMode( dc, BkMode); -James -- James Hatheway Work: [EMAIL PROTECTED] ~ http://www.macadamian.com Home: [EMAIL PROTECTED] ~ http://members.home.net/jhatheway "Man knnte froh sein, wenn die Luft so rein wre wie das Bier" "One could be happy if the air were as pure as the beer" - Original Message - From: "Dan Engel" [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Wednesday, April 11, 2001 10:24 PM Subject: edit control patch This is my first attempt at submitting a patch--please someone let me know if there are "customs" I need to follow. Problem: Edit boxes are, in some cases, displaying selected text as white-on-white, so that it disappeared. Analysis: When text is drawn using the x11drv function X11DRV_ExtTextOut, the function does not paint a background rectangle if the background mode for the device context is transparent. In the case of edit controls, there is no attempt to change the background mode to opaque for selected text. Solution: In the case of painting reverse text in the edit control (function EDIT_PaintText) set the backgound mode to opaque, and then restore it before exiting the function. The patch is attached (wine.diff).
Re: [PATCH] Add Callback for wavemapper - widOpen
well, the waveOut case is broken when no ACM conversion is required (only mapping to an available device). it uses the wrong waveOut handle (which seems to crash your app). I'll try to whip out something this week-end Hi Eric, Thanks. I've been caught up with some other bugs lately that I didn't have the chance to come back to this issue yet. -James -- James Hatheway Software Designer - Macadamian Technologies, Inc. [EMAIL PROTECTED] ~ http://www.macadamian.com "Man knnte froh sein, wenn die Luft so rein wre wie das Bier" "One could be happy if the air were as pure as the beer"
Re: [PATCH] Name Thread Exception support in Wine debugger
something seems wrong in your patch... the szName field from the exception field is never copied from the debugged program space to the debugger space (only the address is) so, you should use ReadProcessMemory instead (something like ReadProcessMemory(pThread-name, sizeof(pThread-name), DEBUG_CurrThread-process-handle, pThreadName-szName); OOPs... you're right. Works a lot better with ReadProcessMemory. :-) I'll send a modified patch ASAP. also, I don't like the fact that you put the #define in a public header file and the exception struct definition inside the file it would make more sense to me if both were either public or private (I'd go for private, since those values don't seem to be defined in Windows' standard headers) Hmm.. sure, I can put both in the private header... I had the entry in the public one since there was already a WINE specific entry there, but I'll move my stuff all into the private debugger.h. -James -- James Hatheway Software Designer - Macadamian Technologies, Inc. [EMAIL PROTECTED] ~ http://www.macadamian.com "Man knnte froh sein, wenn die Luft so rein wre wie das Bier" "One could be happy if the air were as pure as the beer"
Re: Interesting Magic # exception understood by the MS debugger...
and (B) should we support MS's hack somehow in the official tree? Yes, in the Wine debugger, which should store the name and simply continue execution, just like the MSVC debugger does. OK, I don't know too much about the internals of the WINE debugger, so here goes. Is there a field for this already, or should I make a new field in DBG_THREAD structure? (I think that seems like the right place for it) -James -- James Hatheway Software Designer - Macadamian Technologies, Inc. [EMAIL PROTECTED] ~ http://www.macadamian.com "Man knnte froh sein, wenn die Luft so rein wre wie das Bier" "One could be happy if the air were as pure as the beer"
Interesting Magic # exception understood by the MS debugger...
Hi guys, I encountered something interesting while debugging a newer build of my application. I noticed that all of a sudden I was receiving approximately 10 new exceptions in the debugger on startup that I wasn't receiving before. After digging a little, I found out that the app coders were making use of a 'hidden' feature of MS VC that allowed you to name your threads (thus allowing for easier debugging). To do this, you call RaiseException with the code of 0x406D1388. (Search on deja.com or google.com for "0x406D1388" for details.) The windows debugger seems to be on the lookout for this code. Of course, what it does in wine is just breaking into the debugger many times and getting on my nerves. :-) For now, I put the little hack I attached to this mail in my tree to save my sanity. My question to the list is, (A) is there a way to name threads in Linux/Unix (I don't think so, but of course I could be wrong) and (B) should we support MS's hack somehow in the official tree? -James -- James Hatheway Software Designer - Macadamian Technologies, Inc. [EMAIL PROTECTED] ~ http://www.macadamian.com "Man knnte froh sein, wenn die Luft so rein wre wie das Bier" "One could be happy if the air were as pure as the beer" name_thread.diff
Re: [PATCH] Add Callback for wavemapper - widOpen
But these other functions are not using the WINE_MLD internal winmm structure, so why do you need it in widOpen()? Couldn't you instead do exactly what wodOpen() does? Hi Alexandre, Ok, I see what you are saying now. Sorry about that. Humm.. I guess the short answer is because it doesn't work if I do it the same way wodOpen does. :-) I'll look into this and send another patch when I have a bit of time (maybe today or on Monday), it appears that it is breaking in MMDRV_WaveIn_Callback, but I'm not 100% sure yet... -James -- James Hatheway Software Designer - Macadamian Technologies, Inc. [EMAIL PROTECTED] ~ http://www.macadamian.com "Man knnte froh sein, wenn die Luft so rein wre wie das Bier" "One could be happy if the air were as pure as the beer"
Re: VerQueryValue[A|W]
Hi Francois, Haven't heard from you in a while? How are things shaking? The Geek corner isn't the same without you! ^_^ Where's HEAP_strudupAtoW called from? All over the place, not just in OLE/COM DLLs. advapi32, commdlg, winspool, etc. Basically, anywhere where the functionality in a DLL is implemented in the W version, and the A version is converting to widechar and calling into W could have a call. For all OLE/COM DLLs, strings should be internally stored as OLECHAR* (wchar_t*) strings. I remember it wasn't the case with typelib.c when I started playing with it. A side-effect of that is that we had to HEAP_strdupAtoW / HEAP_strdupWtoA all over the place in that file - making ASCII-based stored strings more expensive than OLECHAR*-based strings (yeah yeah we're still converting back to ASCII strings a lot, but that's for tracing - not run-time) True, storing as OLECHAR* makes sense. The thing is, that both HEAP_strdupAtoW and MultiByteToWideChar both return wchar_t*. The difference is that HEAP_strdupAtoW does somethings like NULL ptr checks, memory allocation, etc. for you. Its basically a convenience function to MultiByteToWideChar. Its in include/heap.h. So even in COM/OLE DLLs you can s/HEAP_strdupAtoW/MultiByteToWideChar boiler plate code/g without any harm or change in functionality. For the record, the reason why these macros are being phased out is because it breaks DLL seperation. Thanks to Uwe for the info. -James -- James Hatheway Software Designer - Macadamian Technologies, Inc. [EMAIL PROTECTED] ~ http://www.macadamian.com "Man knnte froh sein, wenn die Luft so rein wre wie das Bier" "One could be happy if the air were as pure as the beer"
Re: VerQueryValue[A|W]
To convert an ASCII string to Unicode, you can use the function HEAP_strdupAtoW, as in: wide_str = HEAP_strdupAtoW(GetProcessHeap(), 0, AsciiStr); Please don't. Use the win32 api instead, eg: Oops, that will teach me to answer emails after midnight. ^_^ Of course, you are right, the Win32 API is the way to go. HEAP_strdupAtoW is used all over the place in WINE, perhaps someday we should change them all to use the proper Win32 API? -James -- James Hatheway Work: [EMAIL PROTECTED] ~ http://www.macadamian.com Home: [EMAIL PROTECTED] "Man knnte froh sein, wenn die Luft so rein wre wie das Bier" "One could be happy if the air were as pure as the beer"
Re: recording sound?
The most interesting piece for me seems to be where it says: fixme:mci:MCI_LoadMciDriver Couldn't load driver for type WAVEAUDIO. If you don't have a windows installation accessible from Wine, you perhaps forgot to create a [mci] section in system.ini Then again, the reason I could find that interesting is that I have no idea what it means :-). It seems to be pointing out that I'm missing something, but I don't know if that peticular message is relevent. Hi Thomas, I've seen this problem before. You probably don't have a system.ini file in your designated WINE 'c:\windows' directory. (This is configured in your ~/.wine/config) Create a file in there called system.ini, and you need at least the following two lines: [mci] waveaudio=mciwave.drv You can see a sample in CVSROOT/documentation/samples/system.ini -James -- James Hatheway Software Designer - Macadamian Technologies, Inc. [EMAIL PROTECTED] ~ http://www.macadamian.com "Man knnte froh sein, wenn die Luft so rein wre wie das Bier" "One could be happy if the air were as pure as the beer"
Re: Question about how to cleanly solve a tricky crash in WsControl...
The only problem is our own implementation of WINSOCK.DLL, where we currently do just this: include both Unix and Windows headers. But this is done mostly to get to both sets of data types so that conversion is possible; the conflicting functions are renamed anyway. So one possible solution would be to rename the Windows data types as well, and not rely on winsock.h to define them, but just replicate the definitions with changed names in a private header ... Hi Ulrich, Thanks for the quick reply. I agree with you that the correct way of solving this problem is to get rid of our mixing of windows and unix headers. I think your suggested solution is sound. (making the windows headers functionally equivalent to the real thing, with private WINE headers containing renamed definitions of their Linux equivalents). Unfortunately, at this time I don't have enough time to fix this properly. So, for now, I will follow a suggestion emailed to me by Franois Gouget and use some macros to save the day. Even though I localized it to my socket.c rather than in a global header, its probably not clean enough to get Alexandre's seal of approval (ie. commit to CVS), but I can keep it in my local tree for the time being. I included the patch with this mail just in case there are other people who have apps using WsControl, to fix stack corruption in the short-term. Thanks, -James -- James Hatheway Software Designer - Macadamian Technologies, Inc. [EMAIL PROTECTED] ~ http://www.macadamian.com "Nothing is a problem once you debug the code." wscontrol_socket_hack2.diff
Question about how to cleanly solve a tricky crash in WsControl...
Hi everyone, For the past couple of days, I have been investigating the cause of an interesting bug. What was happening was my application was either crashing in WsControl, or losing its networking after calls to WsControl. I thought this was rather odd, so I started going through the CVS looking at what patch was causing this. I found if I reverted a patch that made importing ws2_32.dll from wsock32.dll work properly, there would be no more crashes. One of the bugs was related to mixing Windows and Linux socket calls, which I fixed and submitted a patch for this to Wine-Patches mailing list. However, despite this patch, I was still getting wierd crashes, always after entering WsControl. Just for fun, I tried commenting out from WsControl all cross-dll calls (ioctlsocket, socket, closesocket). Amazingly, no more crashes! Add back a call only to socket() (really WSOCK32_socket), mysterious crashes again. This problem is only happening if I have a call to socket(), not closesocket() (I assume ioctlsocket as well, but I didn't test that...) My theory for this problem is as follows. In the standard Linux headers there is a declaration for socket(). WINE's declaration of WSOCK32_socket is different. (WINE's takes the modifier WINAPI). When gcc is compiling wsock32.so, it is depending on the declaration from linux's headers, so it places arguments on the stack in the way it is defined there. Since ws2_32 is expecting the arguments in a different way, the stack gets corrupted either on function entry or exit. To test this theory out, I made a quick hack. Basically, I make sure not to call socket() as socket(). I export from ws2_32 another version of WSOCK32_socket, called WSCONTROL_HACK_socket; I add an extern with the right signature in winsock2.h, and I call it from WsControl with WSCONTROL_HACK_socket. I included the hack as an attachment to this mail, you need my other fix to WsControl recently sent to Wine-patches to apply it. Interestingly enough, it works perfectly with my hack, so it seems like my theory is correct. My question to you guys is, how do I solve this problem properly/cleanly? socket()'s declaration in the linux headers is in a header that is needed, there doesn't appear to be a way to "undeclare" a function signature in C (maybe I'm wrong on this?), and simply making another declaration with the right signature results in a type conflict error in compilation. What is a non-hackish way of doing this? Thanks in advance, -James -- James Hatheway Software Designer - Macadamian Technologies, Inc. [EMAIL PROTECTED] ~ http://www.macadamian.com "Nothing is a problem once you debug the code." wscontrol_socket_hack.diff
Re: Display problem in 16bpp with bitblt/dib changes...
Hmm. In theory, it shouldn't make much of a difference for DIB depths above 8bpp. Both the optimized and unoptimized code paths goes through X11DRV_DIB_DoCopyDIBSection (albeit with differing arguments), provided the blit isn't clipped away on the way. What is the destination of the failing blit? What do you mean by "start up with 8bpp mode"? Is the source bitmap perhaps always 8bpp, even if you run at 16bpp? Does the blit encompass the whole bitmap, or only part of it? Is the source bitmap an "upside-down" one (positive DIB height)? Hi Ove, When I said "8bpp mode", I meant running X in 8bpp. Sorry for the confusion. So, when I run X in 8bpp, there is no corruption, however when I run X in 16bpp there is corruption. I will answer your other questions later today, I'm concentrating on another bug at the moment. Thanks, -James -- James Hatheway Software Designer - Macadamian Technologies, Inc. [EMAIL PROTECTED] ~ http://www.macadamian.com "Nothing is a problem once you debug the code."
Display problem in 16bpp with bitblt/dib changes...
Hi Ove,
I've noticed a bug that was introduced in a patch you
originally submitted about a month ago. (Dec.6,2000)
The patch was called 'DIB structure patch' and it
restructured how DIB sections were handled as well as a
small optomization in X11DRV_BitBlt.
When I start my application (Groove) up with 16bpp mode,
whatever is being bitblt'ed turns out as big black
rectangles. If I start up with 8bpp mode, it looks fine.
(or, at least as fine as it can look in 8bpp ^_^)
If I comment out the small optomization, my app
appears fine in 16bpp mode like it did in the past.
The code I comment out is:
== graphics/x11drv/bitblt.c (1512-1542) ==
if ((sSrc == DIB_Status_AppMod) (rop == SRCCOPY)) {
/* do everything ourselves; map coordinates */
xSrc = dcSrc-DCOrgX + XLPTODP( dcSrc, xSrc );
ySrc = dcSrc-DCOrgY + YLPTODP( dcSrc, ySrc );
xDst = dcDst-DCOrgX + XLPTODP( dcDst, xDst );
yDst = dcDst-DCOrgY + YLPTODP( dcDst, yDst );
width = MulDiv(width, dcDst-vportExtX, dcDst-wndExtX);
height = MulDiv(height, dcDst-vportExtY, dcDst-wndExtY);
/* Perform basic clipping */
if (!BITBLT_GetVisRectangles( dcDst, xDst, yDst, width, height,
dcSrc, xSrc, ySrc, width, height,
visRectSrc, visRectDst ))
goto END;
xSrc = visRectSrc.left;
ySrc = visRectSrc.top;
xDst = visRectDst.left;
yDst = visRectDst.top;
width = visRectDst.right - visRectDst.left;
height = visRectDst.bottom - visRectDst.top;
if (sDst == DIB_Status_AppMod) {
FIXME("potential optimization - client-side DIB copy\n");
}
X11DRV_CoerceDIBSection( dcDst, DIB_Status_GdiMod, FALSE );
X11DRV_DIB_CopyDIBSection( dcSrc, dcDst, xSrc, ySrc, xDst, yDst, width, height);
result = TRUE;
goto END;
}
==
I'm sure that my application isn't the only one who is having
problems.. Anyway, I was just wondering if you had any ideas with
what could be going wrong in this section of code. Any help
would be appreciated.
Thanks,
-James
--
James Hatheway
Software Designer - Macadamian Technologies, Inc.
[EMAIL PROTECTED] ~ http://www.macadamian.com
"Nothing is a problem once you debug the code."
Re: StorageBaseImpl? functions
You can call them in C, use the normal API to get an interface and then use the IInterface_Xyz() functions (found in include/wine/obj_*.h) to access the interfaces. IMO the windows API is not a normal API :-). I take it there is some function named approximately "GetInterface"? Well, maybe another pass through the headers and --debugmsg +storage traces will root it out, now I have some beginning of an idea. Hi Lawson, What you want to use is the function call CoCreateInstance(), with the CLSID (Class identifier) for your desired object (which is registered in the registry) and the refid for the interface you want. (Could be IID_IUNKNOWN, then you can QueryInterface for anything else) You will get back a interface pointer, which you can use in conjunction with macros defined in the header files that Marcus was mentioning, such as IUnknown_QueryInterface(). You can also use CoGetClassObject() to get the class factory and get your COM interfaces that way. This stuff is all documented in MSDN, but you might also want to check out "Inside COM" by Dale Rogerson, Microsoft Press, for an intro look at all things COM. "Inside OLE" by Kraig Brockschmidt is also an excellent read, and it is free on MSDN. I'm sure other people on this list can recommend other books as well. Good luck! -James -- James Hatheway Software Designer - Macadamian Technologies, Inc. [EMAIL PROTECTED] ~ http://www.macadamian.com "Nothing is a problem once you debug the code."
Re: regapi broken in newer builds of Wine
../../include/wine/obj_base.h:493: duplicate argument name `tj' in `#define' make: *** [regapi.o] Error 1 The patch I sent earlier, "small fixes", fixes this. Brown paper bag time, I think I was the cause of that problem... However, now it is back where it was before, regapi segmentation faults when it tries to insert new keys into the registry. -James -- James Hatheway Software Designer - Macadamian Technologies, Inc. [EMAIL PROTECTED] ~ http://www.macadamian.com "Nothing is a problem once you debug the code."
regapi broken in newer builds of Wine
Hi guys, I'm not sure if anyone noticed, but regapi has been broken recently in the CVS. I haven't had a chance to track down the exact patch, but it is after 'November 7, 2000 23:30:00' (that was my last reference sandbox which regapi worked) Now if you try to merge a key (keys) it segfaults. Also, for an added bonus, in more recent days regapi doesn't even build. The following happens: gcc -c -I. -I. -I../../include -I../../include -g -O2 -Wall -fPIC -DSTRICT -D_REENTRANT -I /usr/X11R6/include -o regapi.o regapi.c In file included from ../../include/unknwn.h:7, from ../../include/objbase.h:6, from ../../include/ole2.h:10, from ../../include/windows.h:47, from regapi.c:12: ../../include/wine/obj_base.h:493: duplicate argument name `tj' in `#define' make: *** [regapi.o] Error 1 I can help look at this problem on Monday, unless someone fixes the problem before then. ^_^ -James -- James Hatheway Software Designer - Macadamian Technologies, Inc. [EMAIL PROTECTED] ~ http://www.macadamian.com "Nothing is a problem once you debug the code."
Update: MacOSX and WineLib...
Hi everyone, Last week I had sent an email to the devel mailing list asking if anyone knew of any possible issues there would be with porting WineLib to MacOS X. I received a number of potential issues. The main ones, summarized from an email from Patrik Stridvall, are: ===START= - According to the "MacOS X Kernel Environment" book, pg. 37, Mac OSX does not support memory mapped devices through the mmap API. This would affects at least streaming sound playback. But it supports mmap for files? Especially MAP_SHARED? Speaking of mmap. Does MacOS X support sendmsg/recvmsg? If not you can forget about porting Wine unless you can convince Alexandre that the Wineserver should be redesigned. - Must ensure that behaviour of lower level UNIX resources like sockets, threads, files are the way WINE expects it. Wine currently expects that the file API works on socket descriptors. This is not the case on BeOS but I determined that this was a fixable issue. I just never did it. ===FINISH= To test these concerns, I made four test apps and compiled and ran them on Mac OS X. I used the "Mac OS X Public Beta Developer Tools CD" which is downloadable from http://connect.apple.com The first test app used mmap and MAP_SHARED option, the second sent messages between two programs using sendto over a socket, the third used file I/O functions (like read,write) to send messages over a socket, the fourth sent an FD over a socket to another process using sendmsg/recvmsg. I have good news, each of these programs compiled without modification on MacOS X with the standard cc, and ran perfectly!! So, I don't think there are any show stoppers that would keep us from being able to port WineLib to MacOS X. Of course there would be work to do, but at least it is definitely possible. Thanks for all of the help, -James -- James Hatheway Software Designer - Macadamian Technologies, Inc. [EMAIL PROTECTED] ~ http://www.macadamian.com "Nothing is a problem once you debug the code."
Re: Issues regarding porting WineLib to MacOS X
Hi Patrik, Thanks for the response. - According to the "MacOS X Kernel Environment" book, pg. 37, Mac OSX does not support memory mapped devices through the mmap API. This would affects at least streaming sound playback. But it supports mmap for files? Especially MAP_SHARED? I would assume that it supports mmap for files, however I can't back that up with facts. ^_^ I say that it probably is supported, otherwise Apple probably would list it as a difference between it and BSD in the Mac OS X Kernel Environment book I referred to earlier. I couldn't find info on that in my usual places (google, deja), but someone here at the office has a copy of MacOS X so I'll see if I can see for myself what mmap on that platform supports. Speaking of mmap. Does MacOS X support sendmsg/recvmsg? If not you can forget about porting Wine unless you can convince Alexandre that the Wineserver should be redesigned. I would assume so, but I will look for myself - Sound Support. Currently done with WineOSS (ties into Linux OSS drivers) Doesn't seem to be a port of OSS to MacOSX. Maybe need to do another layer specific to the Mac(?) Well. The Solaris port doesn't support sound yet so that is not really nessary. It's necessary for me, because sound is an important feature of the app I might be porting. ^_^ That said I don't imagine support MacOS X through a special driver will pose any problems. Yah, probably not, but still it is another task that will take time. - Must ensure that behaviour of lower level UNIX resources like sockets, threads, files are the way WINE expects it. Wine currently expects that the file API works on socket descriptors. This is not the case on BeOS but I determined that this was a fixable issue. I just never did it. I would be surprised if file API didn't work on socket, since MacOS X is built on BSD core and they ported emacs, apache, etc. succesfully to MacOS X. But again, I should verify that. - Need to be able to build Windows app using gcc (might be issues such as using MS specific keywords/language constructs, etc.) That isn't really a MacOS X specific problem is it? No, you're right. I'm just making a list of all the things that would have to be done to port our app, using WineLib, to Mac OSX, and that is one of the tasks for ME. -James -- James Hatheway Software Designer - Macadamian Technologies, Inc. [EMAIL PROTECTED] ~ http://www.macadamian.com "Nothing is a problem once you debug the code."
Re: Issues regarding porting WineLib to MacOS X
- Sound Support. Currently done with WineOSS (ties into Linux OSS drivers) Doesn't seem to be a port of OSS to MacOSX. Maybe need to do another layer specific to the Mac(?) yes. anyway, multimedia libs are built in mind with different "physical" drivers (one for OSS, one Alsa, one for Solaris au interface, one for...) only the first one is currently implemented. Not a top priority for MacOSX anyway Unfortunately, sound support (recording, playback) is an important feature of the product I might be porting, so for me it would be a priority. ^_^ So if I were to port my app, I would need to write a driver for the multimedia libs for MacOSX... -James -- James Hatheway Software Designer - Macadamian Technologies, Inc. [EMAIL PROTECTED] ~ http://www.macadamian.com "Nothing is a problem once you debug the code."
Re: COM/DCOM support?
I have been looking for information about COM and DCOM support under WINE and haven't been able to find anything. I have looked through the documentation section and have done some web searches but haven't found anything. I am an experienced COM/DCOM/CORBA developer and would be willing to assist in the development efforts, but I would like to know what, if anything, has been done so far. Hi Chris, The COM that is in WINE currently works pretty well, overall. For example, an app I am currently debugging is basically completely written as COM objects, and it works fine. There are certainly things that are missing, for example out of process and remote servers are not supported yet, a lot of functions are only stubs, I'm sure other people on this list can point other things out to you. A good way to find problems is to grep files for FIXME and stub. Also, DCOM support doesn't exist at all, as far as I know. I don't think anyone is currently working on COM/DCOM at the moment in WINE... So, if you would be willing to help out, that would be great! In the source tree, most of the COM stuff is in dlls/ole32/compobj.c -James -- James Hatheway Software Designer - Macadamian Technologies, Inc. [EMAIL PROTECTED] ~ http://www.macadamian.com "Nothing is a problem once you debug the code."
Silence an annoying exception in acmMetrics
Hi, With this patch, it makes debugging in acm stuff a bit easier. It silences an exception in acmMetrics. Basically what is happening is that acmMetrics calls MSACM_GetObject on the incoming hao parameter. Inside MSACM_GetObject, it calls IsBadReadPtr, if that fails it returns NULL. However, it is possible for the incoming hao parameter to be NULL, so this IsBadReadPtr causes an exception (and breaks in the debugger). Of course, you can pass this exception and everything works fine, but it makes things confusing when mixed in with REAL exceptions So I basically check for NULL, and if it is NULL I don't call MSACM_GetObject. Nothing is really changed, just less times I have to type "pass." while debugging some ACM stuff. Changelog: James Hatheway - [EMAIL PROTECTED] Silence unneeded exception to allow easier ACM debugging Modified: dlls/msacm/msacm32_main.c -- James Hatheway Software Designer - Macadamian Technologies, Inc. [EMAIL PROTECTED] ~ http://www.macadamian.com "Nothing is a problem once you debug the code." noexcep_acmMetrics.diff
Re: Silence an annoying exception in acmMetrics
Sorry!! I sent this to the wrong mailing list -James -- James Hatheway Software Designer - Macadamian Technologies, Inc. [EMAIL PROTECTED] ~ http://www.macadamian.com "Nothing is a problem once you debug the code." - Original Message - From: "James Hatheway" [EMAIL PROTECTED] To: "WineHQ Devel" [EMAIL PROTECTED] Cc: "James Hatheway" [EMAIL PROTECTED] Sent: Friday, September 29, 2000 10:26 AM Subject: Silence an annoying exception in acmMetrics Hi, With this patch, it makes debugging in acm stuff a bit easier. It silences an exception in acmMetrics. Basically what is happening is that acmMetrics calls MSACM_GetObject on the incoming hao parameter. Inside MSACM_GetObject, it calls IsBadReadPtr, if that fails it returns NULL. However, it is possible for the incoming hao parameter to be NULL, so this IsBadReadPtr causes an exception (and breaks in the debugger). Of course, you can pass this exception and everything works fine, but it makes things confusing when mixed in with REAL exceptions So I basically check for NULL, and if it is NULL I don't call MSACM_GetObject. Nothing is really changed, just less times I have to type "pass." while debugging some ACM stuff. Changelog: James Hatheway - [EMAIL PROTECTED] Silence unneeded exception to allow easier ACM debugging Modified: dlls/msacm/msacm32_main.c -- James Hatheway Software Designer - Macadamian Technologies, Inc. [EMAIL PROTECTED] ~ http://www.macadamian.com "Nothing is a problem once you debug the code."
Re: Re: [PATCH] Silence an annoying exception in acmMetrics
seeing an exception for a bad hao is not intended by design, it's just that I forgot that IsBadReadPtr now relies on exception handlers... so, I agree that having an exception popping up for a bad parameter is a bad design. anyway, the semantics of MSACM_GetObj is: from a *valid* hao, get the pointer to the internal struct referred by hao (given it's type when needed). so, putting the test for NULL hao in MSACM_GetObj doesn't change the semantics (it will still return NULL). only difference is that no exception will be thrown (since they were not intended, that's even better) anyway, it's up to the caller of MSACM_GetObj to known if a NULL hao is a case of error or not. OK. Here is the check in MSACM_GetObj instead. -James -- James Hatheway Software Designer - Macadamian Technologies, Inc. [EMAIL PROTECTED] ~ http://www.macadamian.com "Nothing is a problem once you debug the code." noexcep_acmMetrics_2.diff
Re: Disabled windows can't be resized by WM
Hi Dmitry, Although WinEdt doesn't crash for me, it exhibits some flaws in the way Wine manages windows. For instance main WinEdt window has only close box on it, though in Windows all three standard buttons showed. My patch adds another "feature": after any dialog box was shown, bitmap on the system menu along with the sole close box on the main window caption disappear and don't get restored after the main window was enabled back. I don't think your patch is causing these problems. I have these two same problems in the app that I am debugging, without your patch applied. (I get this problem with KDE 1.1.2) For me, when the app starts up it has a normal rectangular window and only has the close button. When a region is applied to its window with SetWindowRgn(), and then a normal rectangular window is restored with a SetWindowRgn() and a NULL region, the window doesn't have a system menu or the close button. I don't have time to look at this bug at the moment, unfortunately. I just thought I'd let you know that I don't think your patch is the actual cause of the problem. -James -- James Hatheway Software Designer - Macadamian Technologies, Inc. [EMAIL PROTECTED] ~ http://www.macadamian.com "Nothing is a problem once you debug the code."
sendto() broadcast works on Windows without a Gateway...
Hi guys, The app that I am debugging from time to time sends broadcast (255.255.255.255) UDP packets using the winsock function sendto(). On Windows, if the default gateway is not configured, the sendto() function still sends the UDP packet onto the local network. In Linux, if no default gateway is set, sendto() fails with a "network unreachable". Since it is possible to have an isolated local network that isn't connected to the internet, I guess it is possible to not have a gateway configured, so I want to fix WSOCK32_sendto() to be like Windows and handle this. I attached to this email my first try at handling this problem. Basically what I am doing is: if I am receiving the broadcast address, get the list of interfaces on the machine and their broadcast addresses and send to each bcast address individually. This seems to work fine, with or without a default gateway installed. So my question is, can you guys think of a better way to do this? Are there any problems with what I am doing? My other theory is to do something this in WSOCK32_sendto(): native sendto() call if sendto() fail if broadcast addr send to broadcast of each interface else std error handling stuff... endif endif The only thing with that is that it seems slightly inefficient. Anyway, what do you guys think? Thanks in advance, -James -- James Hatheway Software Designer - Macadamian Technologies, Inc. [EMAIL PROTECTED] ~ http://www.macadamian.com "Nothing is a problem once you debug the code." no_def_gway_fix1.diff
Re: socket.c
Hi Osvaldo, What platform are you attempting to compile WINE on? socket.c:1318: storage size of ifInfo' isn't known This error (and the others) is happening because the compiler can't find the definition for 'struct ifreq'. This should be in net/if.h which is included like this: #ifdef HAVE_NET_IF_H # include net/if.h #endif So, either your net/if.h doesn't have this declaration, or configure didn't find net/if.h on your machine. Could you see if struct ifreq is defined somewhere else on your machine? (cd /usr/include, grep -r "struct ifreq" * | more) If it is defined in a seperate place, I can expand the #ifdef to include your file instead. Thanks, -James -- James Hatheway Software Designer - Macadamian Technologies, Inc. [EMAIL PROTECTED] ~ http://www.macadamian.com "Nothing is a problem once you debug the code."
Patch for WSControl/WSAIoctl, hopefully builds across platforms. :^)
Hi guys, I hope this patch fixes compiling of my WsControl/WSAIoctl stuff on other platforms such as FreeBSD and Solaris. I was wondering if you guys could try compiling this patch on your respective platforms, and if it works I will forward it to the patches mailing list to be committed to CVS. (In the patch I replace ulong with 'unsigned long', and check for the exitence of the defines I want to use, and if they don't exist print a runtime error message rather than be uncompilable) Thanks, -James -- James Hatheway Software Designer - Macadamian Technologies, Inc. [EMAIL PROTECTED] ~ http://www.macadamian.com "Nothing is a problem once you debug the code." wscontrol_portable.diff
Re: dlls/winsock/socket.c 1.21 breaks FreeBSD
I believe we should avoid #ifdef linux whereever possible, because on the one hand even different versions of the Linux kernel or different distributions may behave differently (in general), and on the other hand it makes the code less portable and reduces the incentive to improve portability -- something which Ulrich, Patrik and myself (to a much lesser degree) and probably others have been working on. The Right Thing[TM], is to add autoconf and #ifdef feature checks in the code, that's what we do -- rather successfully -- with GCC, which is probably one of the largest non-trivial portable programs available. OK, sorry for suggesting the evil #ifdef linux, its just that I had seen it somewhere once in the WINE source tree. I'll have a look at adding another check in autoconf, and hopefully have a patch ready sometime today or (more likely) tommorow, depending on my schedule. Of course, if someone out there beats me to it and submits a patch, I won't complain. ^_^ -James
Re: WordPerfect Office 2000 for Linux Review
Hallo, http://lwn.net/2000/0413/commerce.phtml has a review for WordPerfect Office 2000 for Linux. Here is another review (that isn't so negative:) http://www.linuxtoday.com/stories/19377.html -James -- James Hatheway Software Developer - Macadamian Technologies, Inc. [EMAIL PROTECTED] ~ http://www.macadamian.com "Nothing is a problem once you debug the code."
Threading bug in Wine...
Hi guys,
I've been investigating a bug with threads in
the Corel tree of WINE for a little while, and I noticed
that it can be replicated with the current CVS build
from WineHQ as well.
To replicate the bug, all you have to do is create a lot
of threads very rapidly. All the created thread does is
exit, and there is a synchronization to ensure that only one
thread is created at any time. If you do it enough times
in rapid succession, you will not be able to create any more
threads. (on my pc, between 2500 ~ 4000 thread creations
causes this.)
It seems that somewhere between the client and the wine server
a file descriptor is not being closed, and eventually there
are too many open files, thus the client is not able to
open a connection with the server to create more new threads.
In the WineHQ build, it dies in THREAD_Create
(/scheduler/thread.c), in the following code snippet:
===
/* Create the thread on the server side */
if (teb-socket == -1)
{
req-suspend = ((flags CREATE_SUSPENDED) != 0);
req-inherit = (sa (sa-nLength=sizeof(*sa)) sa-bInheritHandle);
/ The call below fails ***/
if (server_call_fd( REQ_NEW_THREAD, -1, teb-socket )) goto error;
/* * */
teb-tid = req-tid;
*server_handle = req-handle;
fcntl( teb-socket, F_SETFD, 1 ); /* set close on exec flag */
}
===
To quickly see the bug, stick a printf before the "goto error"
in the above code, and use the following test app (start with
CTestApp2Dlg::OnWineThreadCrash() method):
===
void CTestApp2Dlg::OnWineThreadCrash()
{
for (int j=0; j5000; j++)
{
// printf ("DEBUG - Thread #%d Attempted\n\n", ++count1);
StartThread();
Sleep(1);
}
}
void StartThread()
{
const DWORD cbStack = 4096;
DWORD idThread;
EndPreviousThread();
m_hPreviousThread = CreateThread(0, cbStack,
ThreadMethod, NULL, 0,
idThread);
}
BOOL EndPreviousThread()
{
if (m_hPreviousThread)
{
WaitForSingleObject (m_hPreviousThread, INFINITE);
}
return TRUE;
}
DWORD WINAPI ThreadMethod(LPVOID lpvParam)
{
m_hPreviousThread = 0;
// printf ("DEBUG - Thread #%d Finished \n\n", count1);
ExitThread (0);
return 0;
}
===
Does anybody have any clues or ideas why this might be happening?
The test app works in windows...
Thanks a lot!
-James
--
James Hatheway
Software Developer - Macadamian Technologies, Inc.
[EMAIL PROTECTED] ~ http://www.macadamian.com
"Nothing is a problem once you debug the code."
John Carmack
