January 2005 - Wine-devel - list.winehq.org

No new tests since 01/15/2005 ?
by Paul Vriens 25 Jan '05

25 Jan '05

Hi, I have no idea if something is wrong but since 01/15/2005, no new tests (and more important, new output) appeared at http://test.winehq.org/data/ Cheers, Paul.

4 3

HKEY_USERS in our registry
by Paul Vriens 25 Jan '05

25 Jan '05

Hi, just saw that our entry for the default user is .Default while on at least win98SE,Win2K and WinXP it's .DEFAULT. Not a big deal but should this be changed? The registry functions all seem to be case-insensitive. Cheers, Paul.

1 0

gdi32 test failing
by Jakob Eriksson 25 Jan '05

25 Jan '05

http://test.winehq.org/data/200501151000/2000_JakobEriksson/gdi32:metafile.… This fails. It shouldn't, because I ran winetest manually. http://test.winehq.org/data/200501151000/2000_JakobEriksson/version.txt what's up with that? regards, Jakob

3 2

Trying to fix the shreg tests
by Paul Vriens 25 Jan '05

25 Jan '05

Hi, now that the test results are current again :-) I can see why some of the shreg tests failed before. The error we are getting back for RegCreateKeyA is ERROR_CHILD_MUST_BE_VOLATILE on most of the XP boxes. We need to either: - Use a different key to write to (a non volatile parent) - Use RegCreateKeyEx instead of RegCreateKey and specify REG_OPTION_VOLATILE which one is preferred? Cheers, Paul Vriens.

1 0

Summary of MSRPC / DCE/RPC interoperability / Applicability of FreeDCE for Wine (DCOM)
by Luke Kenneth Casson Leighton 25 Jan '05

25 Jan '05

hi, in case you looked at the number of emails exchanged on FreeDCE and freaked out, here's a summary. if you feel that there are any relevant points missing or incorrect, please _do_ speak up. [p.s. this message not sent to samba mailing lists due to censorship decision by samba team in effect since 15th dec 2004. if anyone believes this message to be relevant to samba development please kindly forward it to the samba lists, checking first to see if you are the first person to do that. or simply feel free to add cc on any comments to any samba lists you feel are appropriate. please _do_ remember to remove my email address from any cc's to samba lists because it is likely to trigger the samba team censorship filters. thank you] 1) initial query raised: "freedce suitable for wine, esp. dcom!" 2) comments made (corrections from mark, rob and wez): "freedce doesn't have anything _like_ the capability required for DCOM - freedce's DCOM code is 'stubs'" 3) confusion resulted, clarification process began (rob, luke). conclusion: a) "freedce is almost identical to MSRPC, and is the back-end to rpcrt4.dll" b) "MSRPC as implemented in rpcrt4.dll has NOTHING to do with DCOM: DCOM compiles to code that ***UTILISES*** rpcrt4.dll" (this requires further explanation, see below). c) Porting of / Plugging in FreeDCE to rpcrt4.dll could be done "a la Apache Runtime (APR)", i.e. wrapper functions - maybe even just macros in most cases. d) extending FreeDCE to support rpcrt4.dll is easy and almost boring - even RpcImpersonateClient would be trivial to add (trivial from a Wine perspective - but see below for implications) e) lkcl suggested porting FreeDCE to use Wine's threads because dcethreads (posix draft 4 threads) have to diiiieeee. this can be done independently of Wine and there is an incentive _outside_ of Wine to _get_ it done because the dependency on posix draft 4 threads is so "last decade". f) modifying and utilising FreeDCE to understand Win32 "type string format" tables is, with the help of muddle (a program written by matthew chapman that understands exactly those tables in Win32 DLLs and EXEs) going to be a pretty trivial task. (see below for more details here) g) extension of DCE/RPC syntax to support MSRPC syntax is infinitely more straightforward than rewriting an IDL compiler from scratch. (see below) ... still with me so far? :) now here's the catch, and the catch to the catch :) the main counterargument raised to utilising freedce was not so much a technical argument, but was a resources-related and maintenance argument. 'why bother, when the approach presently being taken will "work"'? to answer that, i have to drop out of "summary" mode and into a mode of adding to and also reiterating [some of the] points raised last week. 1) it'll work - _eventually_ - and not fully [codeweavers present aims are for binary and type string interoperability only, and for only a subset of MSRPC to keep the time, development and maintenance costs down] 2) if you ever intend to aim for full interoperability with MSRPC, i recommend that you investigate how "full" pointers are implemented, because i know of a [proprietary] company that implemented that, after first only doing unique pointers, and adding "full" pointers QUADRUPLED the amount of code that they ended up with. 3) why aim to implement (from scratch) only 25% of the full solution (i.e. leaving out network interoperability by implementing your own non-NDR wire format, and not even implementing the full capabilities of the DCE/RPC IDL language) when a 95 to 98% feature-complete and free-software-license-compatible solution already exists? madness! madness, i say! 4) by utilising FreeDCE in Wine, you can kill two birds (actually three or maybe four) with one stone - two of which were aimed for with the initial DCOM work (DCOM binary interoperability at the Win32 and "type string" table levels) and two more are gained "by accident" - network interoperability and the ability to run MSRPC-based applications. 5) the effort expended so far is most certainly not "wasted" by adopting FreeDCE. if the time and effort expended so far had not been spent, how would it then be possible to appreciate the scope and scale of adapting and maintaining FreeDCE integrated to suit Wine? remember, i went through the same thing - i implemented from scratch HAND-CRAFTED marshalling and unmarshalling code in NT Domain interoperability code - almost 100,000 lines over three years - before deciding it was insane and seeking alternatives [and i found FreeDCE]. 6) if you understand the present Wine rpcrt4.dll code, FreeDCE is _so_ similar that the issue of "it's so different that codeweavers and the wine developers couldn't _possibly_ adapt to it" is just absolute nonsense and a complete non-issue: it _is_ the same code (OSF DCE 1.1 "reference" implementation) it's just that in rpcrt4.dll, DCE 1.1 has been "microsofted", and in FreeDCE, DCE 1.1 has been "gnu'd" and "autoconf'd". the question therefore, in my mind, turns on its head: "how _can_ you turn such an opportunity to save time (and money, and effort) down?" summary (well, sort of summary) ends here. the rest of this message is notes about the two. three points above. [noooobody expects the spanish inquisitionnn. the key element is surpriiise. surprise and ... the _twooo_ key elements .... ] DCOM is nothing to do with MSRPC regarding 3b) - this is where the initial confusion arose in 1). DCOM is, as rob kindly clarified, an object-orientated "thing" that uses MSRPC for its transport. it is a programming concept, not a networking API. in microsoft's c++ implementation of DCOM, once the c++ compiler has done its job, no evidence of the fact that it was DCOM remains: everything is compiled down onto MSRPC interfaces [including certain services that are required as part of DCOM]. therefore, it is both easy to confuse rpcrt4 as an implementation of "DCOM" (which it is not, it is an implementation of MSRPC) and also it is easy to forget that DCOM expects some interfaces (including the c++ APIs if you want your c++ applications to utilise DCOM) and services (e.g. the additional service in the endpoint mapper) to exist. and, according to documentation written by microsoft and available online at the open group's site, one of those services is a Win32 registry (yuk). oops :) for which there exists samba tng code that implements the MSRPC side of a Win32 registry, btw, which could easily be combined with Wine's registry to complete a full proper job. RpcImpersonateClient and ImpersonateNamedPipeClient these functions can be implemented such that FreeDCE will transfer security contexts about (to and from Win32 applications that ask for them). the process of adding the two above functions to Wine is very straightforward: pass a few blobs around, such that they can be passed to SeAccessCheck amongst other things. the _implications_ of adding them are that ReactOS must actually understand them, make use of them, etc. [otherwise, you needn't bother - just implement stubs] and _that_ means that the integration with and adoption of Samba or Samba TNG's architecture and NT Services needs to be accelerated. the Samba Team will need to be brought up to speed on how this is achieved. you may run into difficulties, there, however. their general ethos is to keep complete control over all projects that they are involved with or need to make use of (emphasis on _they_ need), and where this is not possible, they tend to reimplement from scratch any components that they require (kerberos servers, ldap servers, that sort of thing). recent developments, however, tend to suggest that this ethos is changing - but the proof of the pudding is always in the eating: their track record on cooperation with other projects is not good. you may therefore find it easier to work with the samba tng architecture for the initial implementation of these two functions, because samba tng is already split into easily manageable and understandable portions behind APIs that match or mirror the samba tng team's "best-guess" of the underlying (or unpublished) Win32 apis. and, as frequently happens, once a concept has been demonstrated as viable in samba tng, it is often adopted by the samba team - so you need not have any concerns about utilising the samba tng architecture. consider it a "proving ground". NDR "type string" interoperability - f) compared to writing an interpreter from scratch that understands these tables, adapting FreeDCE to understand MSRPC tables in DLLs and EXEs is most certainly trivial. NDR "type strings" - aka in DCE/RPC formats as "AST", is effectively a byte-code interpreted language, one in which the size of data structures and the type and offsets of members of structs is embedded, amongst almost a hundred or so other things. remember, binary-interoperability with _linux_ is totally irrelevant: you can just recompile the source code, link against static libraries, blah blah, sorted. so adapting FreeDCE for win32 "type string" interoperability it's a matter of: 1) changing some constants and alignments where necessary, to match those in MSRPC (analysing muddle and freedce) 2) improving muddle to correctly identify the data structures and their relative positions in the DLLs / EXEs - at present, muddle "guesses" some of the table's locations (eek!) and as an aside / prerequisite: 3) correctly duplicating any MSRPC extensions, including adding in support for "complex" expressioning. MSRPC interoperability - g) "interface" inheritance has already been added (by wez). "expressions" needed for size_is(complexthing) have already been added [needs more work and needs "outsourcing" to a function] range(n-n) needs to be added (trivial to do). -- -- <a href="http://lkcl.net">http://lkcl.net</a> --

3 6

Re: [OLE #50] IRemUnknown Proxy/Stub Implementation
by Alexandre Julliard 25 Jan '05

25 Jan '05

Robert Shearman <rob(a)codeweavers.com> writes: > + memcpy(&cIids, buf, sizeof(USHORT)); > + buf += sizeof(USHORT); > + ir = (REMINTERFACEREF*)buf; > + pResults = alloca(cIids * sizeof(HRESULT)); You shouldn't use alloca, it's not portable, plus the space may not be available since the app controls the stack size. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: Summary of MSRPC / DCE/RPC interoperability / Applicability of FreeDCE for Wine (DCOM)
by Dan Kegel 25 Jan '05

25 Jan '05

Mike wrote: > Luke Kenneth Casson Leighton wrote: >> hi, in case you looked at the number of emails exchanged on FreeDCE >> and freaked out, here's a summary. if you feel that there are any >> relevant points missing or incorrect, please _do_ speak up. > > There's only one thing that counts for Wine, and that is patches that > improve Wine. A grand scheme is nice, but it means nothing without patches. Indeed. Luke, we're all excited about the possibilities, but intimidated by the prospect of learning FreeDCE etc. and figuring out how to plug it in to Wine. Perhaps you could figure out a plan of attack that yields a useful intermediate result with a minimum of changes to Wine? If you actually got something simple plugged into Wine and working, it would really get people to stand up and take notice. - Dan -- Trying to get a job as a c++ developer? See http://kegel.com/academy/getting-hired.html

1 0

Unexpected messages arriving while in RedrawWindow()
by Troy Rollo 25 Jan '05

25 Jan '05

In RedrawWindow (dlls/user/painting.c:402) there is a call to MsgWaitForMultipleObjects: /* process pending events and messages before painting */ if (flags & RDW_UPDATENOW) MsgWaitForMultipleObjects( 0, NULL, FALSE, 0, QS_ALLINPUT ); This call can result in messages arriving at an unrelated window, such as in the trace below. This will not happen under Windows - a single-threaded application will not receive a message in an unrelated window while RedrawWindow is on the stack (unless one of the windows that is supposed to be getting messages sends it or processes the message queue). In the trace, the creation of the Combo Box (at stack frame 60) is part of the initialisation sequence for a window. During the creation of that box, RedrawWindow is called, and while in the MsgWaitForMultipleObjects code, an event arrives that causes SetWindowPos() to be called on the frame window containing the parent of the combo box, resulting in a WM_SIZE. In this case, the WM_SIZE message triggers some operations in the parent of the combo box (at stack frames 0-4) that result in data used by an earlier stack frame (at frames 61-70) being changed unexpectedly. A quick fix in the present case might be to take the "RDW_UPDATENOW" flag off the call to RedrawWindow() from CBResetPos(), since it seems unlikely that the flag is necessary, but it seems that doing so just masks the real problem. The real fix would appear to be involve some queueing of events received other than those needed by RedrawWindow(). .... in application code.... #5 0x406f118f in WINPROC_wrapper () at ../../include/winbase.h:2056 #6 0x406f14fa in WINPROC_CallWndProc (proc=0x403550 <WndProc((short, HWND__*, unsigned int, unsigned int, long))>, hwnd=0x20046, msg=5, wParam=2, lParam=19858040) at ../../windows/winproc.c:419 #7 0x406f7fb7 in WINPROC_CallProc32WTo32A (func=0x403550 <WndProc((short, HWND__*, unsigned int, unsigned int, long))>, hwnd=0x20046, msg=5, wParam=2, lParam=19858040) at ../../windows/winproc.c:3053 #8 0x406f893f in CallWindowProcW (func=0x407a2dde <winproc_array+734>, hwnd=0x20046, msg=5, wParam=2, lParam=19858040) at ../../windows/winproc.c:3279 #9 0x40731071 in call_window_proc (hwnd=0x20046, msg=5, wparam=2, lparam=19858040, unicode=1, same_thread=1) at message.c:1473 #10 0x4073219f in SendMessageTimeoutW (hwnd=0x20046, msg=5, wparam=2, lparam=19858040, flags=0, timeout=4294967295, res_ptr=0x4067dbc4) at message.c:1936 #11 0x40732472 in SendMessageW (hwnd=0x20046, msg=5, wparam=2, lparam=19858040) at message.c:2017 #12 0x406cc9d6 in DEFWND_HandleWindowPosChanged (hwnd=0x20046, winpos=0x4067e054) at ../../windows/defwnd.c:75 #13 0x406cdc10 in DEFWND_DefWinProc (hwnd=0x20046, msg=71, wParam=0, lParam=1080549460) at ../../windows/defwnd.c:345 #14 0x406ce2dd in DefWindowProcA (hwnd=0x20046, msg=71, wParam=0, lParam=1080549460) at ../../windows/defwnd.c:851 #15 0x406d9319 in DefFrameProcA (hwnd=0x20046, hwndMDIClient=0x20044, message=71, wParam=0, lParam=1080549460) at ../../windows/mdi.c:1280 .... in application code .... #19 0x406f118f in WINPROC_wrapper () at ../../include/winbase.h:2056 #20 0x406f14fa in WINPROC_CallWndProc (proc=0x403550 <WndProc((short, HWND__*, unsigned int, unsigned int, long))>, hwnd=0x20046, msg=71, wParam=0, lParam=1080549460) at ../../windows/winproc.c:419 #21 0x406f7fb7 in WINPROC_CallProc32WTo32A (func=0x403550 <WndProc((short, HWND__*, unsigned int, unsigned int, long))>, hwnd=0x20046, msg=71, wParam=0, lParam=1080549460) at ../../windows/winproc.c:3053 #22 0x406f893f in CallWindowProcW (func=0x407a2dde <winproc_array+734>, hwnd=0x20046, msg=71, wParam=0, lParam=1080549460) at ../../windows/winproc.c:3279 #23 0x40731071 in call_window_proc (hwnd=0x20046, msg=71, wparam=0, lparam=1080549460, unicode=1, same_thread=1) at message.c:1473 #24 0x4073219f in SendMessageTimeoutW (hwnd=0x20046, msg=71, wparam=0, lparam=1080549460, flags=0, timeout=4294967295, res_ptr=0x4067dfac) at message.c:1936 #25 0x40732472 in SendMessageW (hwnd=0x20046, msg=71, wparam=0, lparam=1080549460) at message.c:2017 #26 0x40ebae77 in X11DRV_SetWindowPos (winpos=0x4067e054) at winpos.c:885 #27 0x406f09cc in SetWindowPos (hwnd=0x20046, hwndInsertAfter=0x20026, x=0, y=4, cx=640, cy=350, flags=2147483664) at ../../windows/winpos.c:1200 #28 0x40ebc3e5 in X11DRV_ConfigureNotify (hwnd=0x20046, event=0x4067e1ac) at winpos.c:1480 #29 0x40ea51d5 in EVENT_ProcessEvent (event=0x4067e1ac) at event.c:348 #30 0x40ea4d68 in process_events (data=0x4037ff40) at event.c:128 #31 0x40ea4e4c in X11DRV_MsgWaitForMultipleObjectsEx (count=1, handles=0x4067e3ec, timeout=0, mask=255, flags=0) at event.c:162 #32 0x406db6e4 in MsgWaitForMultipleObjectsEx (count=0, pHandles=0x0, timeout=0, mask=255, flags=0) at ../../windows/message.c:596 #33 0x406db7a1 in MsgWaitForMultipleObjects (count=0, handles=0x0, wait_all=0, timeout=0, mask=255) at ../../windows/message.c:613 #34 0x40736d8c in RedrawWindow (hwnd=0x20040, rect=0x0, hrgn=0x0, flags=261) at painting.c:414 #35 0x406fe76a in CBResetPos (lphc=0x452a1e68, rectEdit=0x452a1e84, rectLB=0x452a1ea4, bRedraw=1) at combo.c:1599 #36 0x406fe7e6 in COMBO_Size (lphc=0x452a1e68) at combo.c:1616 #37 0x406fef84 in ComboWndProc_common (hwnd=0x20040, message=71, wParam=0, lParam=1080551548, unicode=0) at combo.c:1911 #38 0x40700425 in ComboWndProcA (hwnd=0x20040, message=71, wParam=0, lParam=1080551548) at combo.c:2281 #39 0x406f118f in WINPROC_wrapper () at ../../include/winbase.h:2056 #40 0x406f14fa in WINPROC_CallWndProc (proc=0x407003c0 <ComboWndProcA>, hwnd=0x20040, msg=71, wParam=0, lParam=1080551548) at ../../windows/winproc.c:419 #41 0x406f7fb7 in WINPROC_CallProc32WTo32A (func=0x407003c0 <ComboWndProcA>, hwnd=0x20040, msg=71, wParam=0, lParam=1080551548) at ../../windows/winproc.c:3053 #42 0x406f893f in CallWindowProcW (func=0x407a2b4a <winproc_array+74>, hwnd=0x20040, msg=71, wParam=0, lParam=1080551548) at ../../windows/winproc.c:3279 #43 0x40731071 in call_window_proc (hwnd=0x20040, msg=71, wparam=0, lparam=1080551548, unicode=1, same_thread=1) at message.c:1473 #44 0x4073219f in SendMessageTimeoutW (hwnd=0x20040, msg=71, wparam=0, lparam=1080551548, flags=0, timeout=4294967295, res_ptr=0x4067e7d4) at message.c:1936 #45 0x40732472 in SendMessageW (hwnd=0x20040, msg=71, wparam=0, lparam=1080551548) at message.c:2017 #46 0x40ebae77 in X11DRV_SetWindowPos (winpos=0x4067e87c) at winpos.c:885 #47 0x406f09cc in SetWindowPos (hwnd=0x20040, hwndInsertAfter=0x0, x=0, y=0, cx=223, cy=26, flags=22) at ../../windows/winpos.c:1200 #48 0x406fc21c in CBForceDummyResize (lphc=0x452a1e68) at combo.c:332 #49 0x406fc85a in COMBO_Create (hwnd=0x20040, lphc=0x452a1e68, hwndParent=0x2003e, style=1352728579, unicode=0) at combo.c:666 #50 0x406feee1 in ComboWndProc_common (hwnd=0x20040, message=1, wParam=0, lParam=1080552968, unicode=0) at combo.c:1875 #51 0x40700425 in ComboWndProcA (hwnd=0x20040, message=1, wParam=0, lParam=1080552968) at combo.c:2281 #52 0x406f118f in WINPROC_wrapper () at ../../include/winbase.h:2056 #53 0x406f14fa in WINPROC_CallWndProc (proc=0x407003c0 <ComboWndProcA>, hwnd=0x20040, msg=1, wParam=0, lParam=1080552968) at ../../windows/winproc.c:419 #54 0x406f87cf in CallWindowProcA (func=0x407003c0 <ComboWndProcA>, hwnd=0x20040, msg=1, wParam=0, lParam=1080552968) at ../../windows/winproc.c:3240 #55 0x40731108 in call_window_proc (hwnd=0x20040, msg=1, wparam=0, lparam=1080552968, unicode=0, same_thread=1) at message.c:1478 #56 0x407323e0 in SendMessageTimeoutA (hwnd=0x20040, msg=1, wparam=0, lparam=1080552968, flags=0, timeout=4294967295, res_ptr=0x4067eb18) at message.c:1984 #57 0x407324e2 in SendMessageA (hwnd=0x20040, msg=1, wparam=0, lparam=1080552968) at message.c:2028 #58 0x40eb887f in X11DRV_CreateWindow (hwnd=0x20040, cs=0x4067ee08, unicode=0) at window.c:1124 #59 0x406e9ad3 in WIN_CreateWindowEx (cs=0x4067ee08, classAtom=49153, type=WIN_PROC_32A) at ../../windows/win.c:1172 #60 0x406ea3b7 in CreateWindowExA (exStyle=0, className=0xb47d1a "COMBOBOX", windowName=0xb47d23 "", style=1352728579, x=3, y=3, width=223, height=314, parent=0x2003e, menu=0xce6, instance=0x400000, data=0x0) at ../../windows/win.c:1327 .... in application code .... #71 0x406f118f in WINPROC_wrapper () at ../../include/winbase.h:2056 #72 0x406f14fa in WINPROC_CallWndProc (proc=0x403550 <WndProc((short, HWND__*, unsigned int, unsigned int, long))>, hwnd=0x10022, msg=256, wParam=13, lParam=0) at ../../windows/winproc.c:419 #73 0x406f87cf in CallWindowProcA (func=0x403550 <WndProc((short, HWND__*, unsigned int, unsigned int, long))>, hwnd=0x10022, msg=256, wParam=13, lParam=0) at ../../windows/winproc.c:3240 #74 0x40731108 in call_window_proc (hwnd=0x10022, msg=256, wparam=13, lparam=0, unicode=0, same_thread=1) at message.c:1478 #75 0x407323e0 in SendMessageTimeoutA (hwnd=0x10022, msg=256, wparam=13, lparam=0, flags=0, timeout=4294967295, res_ptr=0x4067f564) at message.c:1984 #76 0x407324e2 in SendMessageA (hwnd=0x10022, msg=256, wparam=13, lparam=0) at message.c:2028 .... in application code .... #79 0x406f118f in WINPROC_wrapper () at ../../include/winbase.h:2056 #80 0x406f14fa in WINPROC_CallWndProc (proc=0x403550 <WndProc((short, HWND__*, unsigned int, unsigned int, long))>, hwnd=0x10022, msg=273, wParam=101, lParam=34) at ../../windows/winproc.c:419 #81 0x406f87cf in CallWindowProcA (func=0x407a2dd0 <winproc_array+720>, hwnd=0x10022, msg=273, wParam=101, lParam=34) at ../../windows/winproc.c:3240 #82 0x406dbe02 in DispatchMessageA (msg=0x4067f96c) at ../../windows/message.c:793 .... in application code .... #85 0x00b1390b in _startup () #86 0x00000000 in ?? ()

1 0

some notes: ADVAPI32: convert services to use pipes for RPC instead of shared memory
by Alexander Yaworsky 25 Jan '05

25 Jan '05

Hello, there should be only one dispatcher thread per process that accepts control requests. For shared services it starts another service threads on demand and the amount of them is not limited with MAXIMUM_WAIT_OBJECTS. Thanks.

2 1

compiling MFC...Advil required? ;-)
by Adam Boyle 25 Jan '05

25 Jan '05

Hi All, First, thanks to all for the excellent work on Wine. I'm a Crossover Office user, and I anxiously await each week's Wine Weekly Newsletter as well to keep myself up with happenings in the Wine world. You guys truly rock. But I digress. Here's the real reason for my e-mail: I need to port one of my company's MFC-based application to Linux. My first thought was to use Winelib. I understand from everything that I've read that I need to recompile MFC using Wine. Easier said than done, though. I've spent several hours just trying to get everything setup correctly, and things are still not compiling correctly. First, some questions: - My initial attempt at compiling MFC was on the MFC source code from VS.NET 2003. After not being able to get a satisfactory Makefile configuration for compling that version of MFC, I figured that perhaps VS98's version of MFC was more commonly recompiled by Wine developers, so I'm currently trying to compile VC98's MFC. Is there a preferred version of MFC that I should be compiling, or are they all equally difficult? ;-) - I have the following RPM packages installed on my Mandrake 10.1 OS: libwine1-20040813-2mdk, winelib-0.3-1mdk, libwine1-devel-20040813-2mdk, wine-20040813-2mdk. I have also downloaded the latest wine source code from 20050111. As mentioned before, I also have Crossover Office installed. In your opinion, is there a more compatible or better set of libraries to use when compiling? Anybody compiled MFC using the Mandrake packages before? (FYI, wineg++ --version and winegcc --version both report that they are g++/gcc (GCC) 3.4.1. - Also, should I be using an older version of Wine's source code, instead of the very recent 20050111 version that I've currently got on my system? I've read the Winelib documentation on compiling MFC and have combed through the mailing list archives as much as possible to get to where I'm currently at. After running winemaker on the VC98 source code directories and tweaking the resulting VC98/MFC/src/Makefile quite a bit, I also put the following #defines at the top of VC98/MFC/src/stdafx.h: #define _AFX_PORTABLE #define _FORCENAMELESSUNION #define _AFX_NO_DAO_SUPPORT #define _AFX_NO_DHTML_SUPPORT #define _AFX_NO_OLEDB_SUPPORT #define _AFX_NO_RICHEDIT_SUPPORT #define _AFX_NO_ATL_SUPPORT (That seems to be basically what the Winelib docs tell me to do.) Anyway, here's the current output when I run 'make -f Makefile' in the VC98/MFC/src directory: wineg++ -c -mno-cygwin -isystem -fpermissive -fms-extensions -fshort- wchar -DWINE_UNICODE_NATIVE -DICOM_USE_COM_INTERFACE_ATTRIBUTE -I. - I/home/ajboyle/wine-20050111/include/msvcrt - I/home/ajboyle/wine-20050111/include -I../Include -o afxabort.o afxabort.cpp In file included from stdafx.h:96, from afxabort.cpp:11: ../Include/afxcom_.h: In constructor `CIP<_Interface, _IID>::CIP (IUnknown*)': ../Include/afxcom_.h:357: error: there are no arguments to `GetIID' that depend on a template parameter, so a declaration of `GetIID' must be available ../Include/afxcom_.h:357: error: (if you use `-fpermissive', G++ will accept your code, but allowing the use of an undeclared name is deprecated) ../Include/afxcom_.h: In member function `CIP<_Interface, _IID>& CIP<_Interface, _IID>::operator=(IUnknown*)': ../Include/afxcom_.h:379: error: there are no arguments to `QueryInterface' that depend on a template parameter, so a declaration of `QueryInterface' must be available ../Include/afxcom_.h: At global scope: ../Include/afxcom_.h:403: error: an explicit specialization must be preceded by 'template <>' In file included from stdafx.h:110, from afxabort.cpp:11: ../Include/afxctl.h: In constructor `COleControl::XEventConnPt::XEventConnPt()': ../Include/afxctl.h:1303: warning: invalid access to non-static data member `COleControl::m_xEventConnPt' of NULL object ../Include/afxctl.h:1303: warning: (perhaps the `offsetof' macro was used incorrectly) ../Include/afxctl.h: In constructor `COleControl::XPropConnPt::XPropConnPt()': ../Include/afxctl.h:1310: warning: invalid access to non-static data member `COleControl::m_xPropConnPt' of NULL object ../Include/afxctl.h:1310: warning: (perhaps the `offsetof' macro was used incorrectly) In file included from ../Include/afxpriv.h:758, from stdafx.h:123, from afxabort.cpp:11: ../Include/afxconv.h:62:21: atlconv.h: No such file or directory In file included from stdafx.h:127, from afxabort.cpp:11: oleimpl2.h: At global scope: oleimpl2.h:94: error: a class-key must be used when declaring a friend In file included from /usr/lib/gcc/i586-mandrake-linux- gnu/3.4.1/../../../../include/c++/3.4.1/backward/new.h:33, from stdafx.h:161, from afxabort.cpp:11: /usr/lib/gcc/i586-mandrake-linux-gnu/3.4.1/../../../../include/c+ +/3.4.1/backward/backward_warning.h:32:2: warning: #warning This file includes at least one deprecated or antiquated header. Please consider using one of the 32 headers found in section 17.4.1.2 of the C++ standard. Examples include substituting the <X> header for the <X.h> header for C++ includes, or <iostream> instead of the deprecated header <iostream.h>. To disable this warning use -Wno-deprecated. winegcc: g++ failed. make: *** [afxabort.o] Error 2 Funny how gcc is telling me to use -fpermissive, when I'm already using it. Anyway, that's probably a red herring. If I can gain a clear understanding of the current steps needed to successfully compile MFC, I'd be more than happy to contribute updated 'Compiling MFC' docs to the Winelib docs to help out future developers that may be in a similar predicament as me. Thanks in advance for any help you can give me. Adam Boyle

1 0