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

Direct access to LPT1
by E Lea 24 Jul '03

24 Jul '03

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.

2 1

Re: wine/. configure.ac configure
by Marcus Meissner 24 Jul '03

24 Jul '03

On Wed, Jul 23, 2003 at 07:09:52PM -0500, Alexandre Julliard wrote: > ChangeSet ID: 8863 > CVSROOT: /home/winehq/opt/cvs-commit > Module name: wine > Changes by: julliard(a)wine.codeweavers.com 2003/07/23 19:09:52 > > Modified files: > . : configure.ac configure > > Log message: > Disable gcc strict aliasing optimization for now. > > Patch: http://cvs.winehq.com/patch.py?root=/home/winehq/opt/cvs-commit&id=8863 > > Old revision New revision Changes Path > 1.167 1.168 +9 -0 wine/configure.ac > 1.442 1.443 +52 -0 wine/configure Which file/functions gets broken by strict aliasing? Ciao, Marcus

2 1

Re: ddraw patch
by Lionel Ulmer 24 Jul '03

24 Jul '03

Some comments : + case D3DRENDERSTATE_LINEPATTERN: { + D3DLINEPATTERN pattern; + #ifdef WORDS_BIGENDIAN + pattern.wRepeatFactor = *((WORD*)&pattern + 2); + pattern.wLinePattern = *((WORD*)&pattern); + #else + pattern.wRepeatFactor = *((WORD*)&pattern); + pattern.wLinePattern = *((WORD*)&pattern + 2); + #endif Why not someting 'simple' as pattern = *((D3DLINEPATTERN *) &dwRenderState); ? Your code is not working anyway because (AFAICS) you never actually store something in 'pattern'. + if(pattern.wRepeatFactor) { + glEnable(GL_LINE_STIPPLE); + FIXME("implement wRepeatFactor parameter for glLineStipple\n"); + glLineStipple(1, pattern.wLinePattern); + } else { + glDisable(GL_LINE_STIPPLE); + } + break; + } + Well, as long as you are here, I would rather do something like that : if(pattern.wRepeatFactor > 256) { FIXME("not supported in OpenGL - clamping to 256"); } glLineStipple(pattern.wRepeatFactor, pattern.wLinePattern); Because, from what I can see in the man page, the first parameter of the LineStipple call is exactly equivalent to 'pattern.wRepeatFactor'. By the way, which game uses this rendering state ? @@ -921,16 +940,16 @@ case CONVERT_PALETTED: { IDirectDrawPaletteImpl* pal = current_surface->palette; BYTE table[256][4]; - int i; - int x, y; + unsigned int x, y; BYTE *src = (BYTE *) (((BYTE *) src_d->lpSurface) + (bpp * rect->left) + (src_d->u1.lPitch * rect->top)), *dst; - + if (pal == NULL) { /* Upload a black texture. The real one will be uploaded on palette change */ WARN("Palettized texture Loading with a NULL palette !\n"); memset(table, 0, 256 * 4); } else { /* Get the surface's palette */ + unsigned int i; for (i = 0; i < 256; i++) { table[i][0] = pal->palents[i].peRed; table[i][1] = pal->palents[i].peGreen; And what are the reasons for all these changes ? I do not see why it's better to have the loop variables signed instead of unsigned (except if you have a compiler warning about signed / unsigned comparison). Lionel -- Lionel Ulmer - http://www.bbrox.org/

1 0

Re: Status_Wine #2 -- lostwages
by Joel Carr 24 Jul '03

24 Jul '03

I also would help, except I'm so short on time I know I wouldn't actually do anything, so I won't volunteer... I've been lurking around these lists for about 4 or so years now, so I've got a bit of an idea about some of the stuff that's happened. Maybe in the future I'll lend a hand. If I recall correctly, the 'history of wine' has come up a few times, so there may already be some material that could be used. Here are a couple of short threads about it from last year: http://www.winehq.com/hypermail/wine-devel/2002/11/0910.html http://www.winehq.com/hypermail/wine-devel/2002/11/0378.html Some of the people who have had a dab at the history of wine are still active on this list and may have some material. Anyway, didn't Alexandre give a presentation on the history of wine at Wineconf 2002? Certainly according to this page he did: http://kt.zork.net/wine/wn20020325_118.html I don't know how extensive the presentation was, but if there are records of it, it may be a good starting point. Don't know if this helps at all, Probably everyone knew all this anyway ;) Joel Carr -- __________________________________________________________ Sign-up for your own FREE Personalized E-mail at Mail.com http://www.mail.com/?sr=signup CareerBuilder.com has over 400,000 jobs. Be smarter about your job search http://corp.mail.com/careers

1 0

Fwd: [Bug 1528] wineps printing to lpr issues
by Dustin Navea 24 Jul '03

24 Jul '03

--- Wine Bugs <wine-bugs(a)winehq.com> wrote: > From: Wine Bugs <wine-bugs(a)winehq.com> > To: wine-bugs(a)winehq.com > Subject: [Bug 1528] wineps printing to lpr issues > Date: Thu, 24 Jul 2003 09:29:37 -0500 > > http://bugs.winehq.com/show_bug.cgi?id=1528 > > > > > > ------- Additional Comments From ktaylor(a)daac.gsfc.nasa.gov 2003-24-07 > 09:29 ------- > Is anyone out there? Are there any comments, or help that can be offered? > > -- > Configure bugmail: http://bugs.winehq.com/userprefs.cgi?tab=email > ------- You are receiving this mail because: ------- > You are the assignee for the bug, or are watching the assignee. > ===== -- Dustin Navea Minor Contributor, winehq.com Buzilla Janitor, bugs.winehq.com Network Admin, irc.blynk.net (down) __________________________________ Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software http://sitebuilder.yahoo.com

1 0

typelib caching
by Mike Hearn 24 Jul '03

24 Jul '03

Well, it works, finally. No more crashes/hangs :) That is - sort of. Unfortunately, it's a bit too slow to be usable. A few wild stabs in the dark and some timing traces showed the culprit to be LoadTypeLibEx: trace:ole:LoadTypeLibEx File L"C:\\windows\\system\\SHDOCVW.DLL" index 1 trace:ole:LoadTypeLibEx returns 00000000, in 15 milliseconds trace:ole:LoadTypeLibEx File L"C:\\windows\\system\\SHDOCVW.DLL" index 1 (hmmmm, we load it again?) trace:ole:LoadTypeLibEx returns 00000000, in 46 milliseconds (odd, slower than last time) trace:ole:LoadTypeLibEx File L"C:\\windows\\system\\mshtml.tlb" index 1 trace:ole:LoadTypeLibEx returns 00000000, in 1208 milliseconds (over a second parsing the type library? well, maybe it is quite large) trace:ole:LoadTypeLibEx File L"C:\\windows\\system\\mshtml.tlb" index 1 trace:ole:LoadTypeLibEx returns 00000000, in 6689 milliseconds (almost 7 seconds to parse the type lib a second time!?!) trace:ole:LoadTypeLibEx File L"C:\\windows\\system\\mshtml.tlb" index 1 trace:ole:LoadTypeLibEx returns 00000000, in 42139 milliseconds Waaaaaaah, 42 seconds! There's a big source of the sluggishness. So, a few questions that I can chew on tomorrow: * Shouldn't typelib loading be cached somewhere? Reparsing typelibs like this seems rather wasteful. * Why on earth would the time taken go up so massively on each run? * Where abouts in the typelib parsing could the speed hit be? Pretty clearly no typelib is going to be so complex it takes an Athlon 1200 almost a minute to parse, there is a nasty bug there somewhere. thanks -mike

1 0

Re: Status_Wine #2 -- lostwages
by Jakob Eriksson 24 Jul '03

24 Jul '03

Tom Wickline wrote: > > Hi, > > I updated the cabinet.dll status per greg.. > Fix bullet links again.. > We have the History of wine as Poor *I* changed it to Adequate as there > is a changelog going back 5+ years. > My impression of "History of Wine" was that it should go into details about how the project started in the beginning. Like anecdotes and stuff... I may have totally misunderstood. :-) Jakob

5 4

Re: I need card back bitmaps
by Brian Vincent (C) 24 Jul '03

24 Jul '03

> 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

1 0

Re: Typelib marshalling BSTRs
by Ove Kaaven 24 Jul '03

24 Jul '03

man, 21.07.2003 kl. 17.31 skrev Mike Hearn: > On Mon, 2003-07-21 at 12:55, Ove Kaaven wrote: > > > fixme:ole:PointerUnmarshall unhandled ptr type=12 > > > > This means that null pointers may not be handled properly (but non-null > > pointers will still work). However, I have yet to see a situation where > > I needed to handle it, but then again I've only worked on InstallShield. > > I suppose it's possible that you need to if you're working on something > > else (but I don't think IDispatch is an interface where you need to > > worry about it). > > IDispatch::Invoke has an riid parameter, that the docs say is reserved > and must be IID_NULL. In the current custom marshallers, trace > statements reveal that the stub receives this as NULL, not IID_NULL. Are > they equivalent in this context, or is that being marshalled > incorrectly? Not exactly equivalent here. The ptr type is not 0x12 here, I think; supplying NULL here is completely invalid and the MIDL code in oaidl_p.c will raise an exception, completely refusing to marshal the call at all. If supplying NULL is supposed to be valid at the API level, it must be handled by the IDispatch_Invoke_Proxy wrapper in usrmarshal.c, converting the NULL to IID_NULL, before passing it off to the MIDL-generated marshaller. (This Invoke wrapper already treats some other can-be-NULL arguments in this manner, so this would just be yet another case of this.) > > You probably just need to marshal an extra flag saying > > whether the pointer is null or not, but since I haven't seen the DCE RPC > > spec I don't know what the flag should look like. > > Is that just a case of adding another IStream::Write call, and having > the equivalent read in the custom demarshaller? That would probably work, except that MIDL-based marshallers and rpcrt4 don't use IStream... > > Hmm. It could still be in Wine code, since NdrComplexArrayUnmarshall > > might be trying to unmarshal an array of variants, which is a custom > > type. The custom-marshalling code for variants is in > > dlls/oleaut32/usrmarshal.c, and there is a VariantInit in the > > VARIANT_UserUnmarshal function in there (though it probably shouldn't > > have shown up in a relay trace). > > I found that it's in IDispatch_Invoke_Stub - it calls IDispatch::Invoke > on the actual object and crashes, in native shdocvw code. So, I guess > the inputs its given there are incorrect somehow. I'll look into it some > more. OK.

4 13

is there a "wine coding guide" available?
by Jonathan Wilson 24 Jul '03

24 Jul '03

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

2 1