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

Direct access to LPT1

by E Lea

I'm playing around with a program that controls a small "design cutter" - it's basically a plotter that connects via the parallel port. There is some Windows CAD software that knows about the plotter and sends commands to it, as far as I can tell in one of two ways: 1) Through a printer driver. It doesn't seem too bothered about the details of the driver though. I'm assuming that one would normally use a generic, text-only Windows driver. This method, apparently, has the advantage of the driver buffering the output 2) The second method is a direct connection to LPT1. With Wine, in the first case I get a message in a dialog box saying the call to "StartDocPrinter" failed and fixme:winspool:StartDocPrinterA (hPrinter=0x1, Level=0x1, pDocInfo=0x408a28dc): stub to stdout. In the second case I get a dialog saying "LPT1 was not found" and fixme:dosfs:DOSFS_OpenDevice device open L"LPT1" not supported (yet) err:file:CreateFileW Couldn't open device L"LPT1"! to stdout. Is this a config issue? I'm assuming that is should be easier for me to get the second method working.

July 24, 2003

Re: I need card back bitmaps

by Brian Vincent (C)

> Before I continue with cards.dll work, I need card back bitmaps, specificly: > back 53, a diamond cross-hatch background. This one should have black lines > on a white background, its used as an indicator for where cards can go but > where there are no cards yet. The earliest I can get to that would be tonight. I'll probably go climbing all weekend, so if they're not done by the morning I won't get to them till Monday. I'll see what I can do. Maybe you could use one of those decks you mentioned for development? --------------- Brian Vincent Copper Mountain Telecom vincentb(a)coppercolorado.com

July 24, 2003

Re: Typelib marshalling BSTRs

by Mike Hearn

On Thu, 2003-07-24 at 13:47, Ove Kaaven wrote: > You have to use CoMarshalInterface, but of course you need an IStream > interface to do this, which is probably why I haven't bothered to > implement it yet. I implemented it by creating an HGLOBAL stream then locking the global and doing a memcpy. Not especially high performance but it works and the code is well insulated. I found the necessary flags were in the loword of pFlags. > As for the two spellings of marshal, I think the original DCE RPC > reference code (that MS-RPC was designed as a clone of) was the original > culprit, using the "marshall" spelling everywhere, and since Microsoft > adopted (embraced and extended) their API, they adopted their spelling > too. I assume the original DCE engineers were exactly that, just > engineers, not English majors (perhaps they got confused by the > unrelated noun (and name) marshall or something). Microsoft's OLE > department knew how to spell, though, so that's why we have > CoMarshalInterface in OLE, and Ndr*Marshall in MS-RPC. Hehe, yes, this sounds possible. Well, no matter, I was just a bit curious. Anyway, dispatch variant marshalling works now. On to the next crash :) thanks -mike

July 24, 2003

Re: is there a "wine coding guide" available?

by Dimitrie O. Paun

On July 24, 2003 07:35 am, Jonathan Wilson wrote: > Something that covers things like coding style, things not to do in wine > (e.g. because they arent portable enough) and so on. No really. There's DEVELOPERS-HINTS, but that's about it. As for style, you can use your own style if you want in new files. If you're changing already existing files, just stick to the style used in them. For new code, the preferred style is 4-spaces indentation, with braces on their own line: if (...) { .... } Many people feel strongly about it, and they have their own. If you don't, it's better to use the preferred one. -- Dimi.

July 24, 2003

Re: Status_Wine #2 -- lostwages

by Dimitrie O. Paun

On July 23, 2003 09:59 pm, Tom wrote: > So, may I ask if either of you plan to volunteer to write a *official* > History/Time line page ? Im no writer, really, so no, I don't plan on working on this. Hopefully a better word craftsman will volunteer soon... -- Dimi.

July 24, 2003

Re: Typelib marshalling BSTRs

by Ove Kaaven

ons, 23.07.2003 kl. 17.28 skrev Mike Hearn: > So, moving on from that problem, I think my woes (currently) are caused > by the NDR engine not handling VT_DISPATCH variants. Hmm. Oh yeah, I guess that could be a problem. > that causes VARIANT_UserMarshal to skip doing anything special for > VT_DISPATCH variants, when I think in reality, it should call > NdrInterfacePointerMarshall (btw, what's up with two spellings of > "marshal"?) to get the IDispatch* into the stream. You can't call NdrInterfacePointerMarshall, it's a NDR-engine function that depends on marshalling state that isn't available at this point. You have to use CoMarshalInterface, but of course you need an IStream interface to do this, which is probably why I haven't bothered to implement it yet. You can probably copy the IStream-related code from ndr_ole.c and adapt it for this situation. It may cause some code duplication to do that, but perhaps this undocumented WdtpInterfacePointer_UserMarshal mentioned elsewhere in this thread is actually a common CoMarshalInterface-wrapping back-end used by both NdrInterfacePointerMarshall and VARIANT_UserMarshal? In that case the IStream stuff would be implemented there, and there'd be no code duplication. As for the two spellings of marshal, I think the original DCE RPC reference code (that MS-RPC was designed as a clone of) was the original culprit, using the "marshall" spelling everywhere, and since Microsoft adopted (embraced and extended) their API, they adopted their spelling too. I assume the original DCE engineers were exactly that, just engineers, not English majors (perhaps they got confused by the unrelated noun (and name) marshall or something). Microsoft's OLE department knew how to spell, though, so that's why we have CoMarshalInterface in OLE, and Ndr*Marshall in MS-RPC.

July 24, 2003

Re: Invoke with IDispatch* params

by Ove Kaaven

ons, 23.07.2003 kl. 15.49 skrev Mike Hearn: > This comment in the code concerns me: > > /*FIXME: give pointers for the rest, so propertyget works*/ I'm not sure what this comment refers to. It looks to me like "give pointers for the rest so propertyget works" is what it's already doing. Perhaps the fixme means "this should probably be done only when appropriate, not always", or perhaps someone added it without removing the fixme. > well, this is indeed a property get, so the result should be made > available in pVarResult. > > This code looked promising: > > /* If pointer to variant, pass reference it. */ > if ((tdesc->vt == VT_PTR) && (tdesc->u.lptdesc->vt == VT_VARIANT) && > pVarResult) { > args[argspos] = (DWORD)pVarResult; > } This is just a fast-path, the other cases are handled below, in the "if (pVarResult && (dwFlags & (DISPATCH_PROPERTYGET)))" section.

July 24, 2003

Re: Typelib marshalling BSTRs

by Ove Kaaven

ons, 23.07.2003 kl. 11.41 skrev Mike Hearn: > On Tue, 2003-07-22 at 17:35, Gregory M. Turner wrote: > > I was kind of ignoring this as my brain is full with cabinet things ATM... > > but it sure sounds awfully wrong, doesn't it? > > Yeah. I have the feeling that some obscure rule of C is biting me on the > backside (again). If it helps, I've been thinking that perhaps the new strict-aliasing stuff in gcc 3.3 has something to do with it. I suppose you could try -fno-strict-aliasing or something; after all, the place where riid is written to is through a typecast, which strict aliasing is hateful of. Particularly in this case, as REFIID is so very const that you're probably not supposed to assign to a variable of this type at all, and you have to typecast to a non-const pointer type to be able to. With strict aliasing, the compiler will probably ignore the non-const alias and just optimize the initial NULL into any usage of the original const variable. Of course I could be way off. > > Perhaps, this really indicates some kind of problem with the loading / linking > > or the spec.c file or something like that? Does the behavior change if you > > take out the RpcTryFinally? I would guess not. > > It does not. To recap: > > REFIID riid = NULL; - fails, because assignments to it are silently > ignored > > > REFIID riid; > riid = NULL; - works, because ..... it confuses the gremlins? Not sure, but more likely because the compiler might actually allocate a stack slot for riid when you leave it uninitialized and then assign to it explicitly in a statement (so that the subsequent typecast will return a pointer to the same memory). With the former initialization, the compiler probably considers the riid having a predefined value (that "won't ever change" because of REFIID's constness), and hence doesn't reserve a stack slot for it; it just uses NULL wherever riid is used (and with strict aliasing, maybe just allocates temporary space for the typecasting, not a real stack slot for riid). Well, that's my theory anyway. I probably don't have your problem anyway because my own MIDL-generated oaidl_p.c uses an explicit assignment like in your latter case. Alexandre probably just changed it into the former form to avoid some compiler warnings (from assigning to a const variable, probably).

July 24, 2003

is there a "wine coding guide" available?

by Jonathan Wilson

Something that covers things like coding style, things not to do in wine (e.g. because they arent portable enough) and so on.

July 24, 2003

RE: Typelib marshalling BSTRs

by Mike Hearn

On Thu, 2003-07-24 at 03:38, Robert Shearman wrote: > Sorry, just realised that this the VARIANT_UserMarshal function is in > oleaut32. On Windows, this calls WdtpInterfacePointer_UserMarshal for both > the VT_UNKNOWN and VT_DISPATCH cases, which in turn calls > CoMarshalInterface. Thanks, I didn't know about those functions. Unfortunately I can't see the prototypes anywhere, and don't really have time right now to disassemble native code to find out. I'll have a look today and see what the best way of dealing with this situation might be....

July 24, 2003