wine-devel

wine-devel@winehq.org

9 participants
84458 discussions

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

Invoke with IDispatch* params
by Mike Hearn 24 Jul '03

24 Jul '03

Hi, more questions (i'll master COM yet :) HRESULT IWebBrowser2::get_Document(IDispatch **ppDisp); invocation of this method/property fails, for some reason. I'm not sure why yet, but I don't understand how this is marshalled. Presumably, OLE Automation provides a ppDisp and then dereferences it back to IDispatch which is then marshalled. In ITypeInfo::Invoke, there is this code: if (tdesc->vt == VT_PTR) tdesc = tdesc->u.lptdesc; when looping over the arguments (?). So, it seems that this code is responsible for dereferencing the pointer, but it only does it once. Shouldn't this be a loop to dereference the arg as many times as needed? I feel that's wrong even as I write it, but I'm not sure how this part should work. As it is, tdesc->vt ends up being (correctly) VT_DISPATCH but pVarResult doesn't seem to be changed....

3 4

RE: Typelib marshalling BSTRs
by Robert Shearman 24 Jul '03

24 Jul '03

> > -----Original Message----- > > From: Mike Hearn [mailto:mike@theoretic.com] > > Sent: 23 July 2003 23:09 > > To: Robert Shearman > > Cc: wine-devel(a)winehq.org > > Subject: Re: Typelib marshalling BSTRs > > > > Well, the code doesn't actually marshal IWebBrowser2, it operates > > entirely in terms of IDispatch interfaces. Once the dispatch interface > > for the WebBrowser control is marshalled into another thread, the code > > starts poking it via Invoke, in this case retrieving the Document > > property which also returns a dispatch interface. 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. I hope this helps, Rob

2 1

RE: Typelib marshalling BSTRs
by E Lea 24 Jul '03

24 Jul '03

> > Sounds like you are doing a great job, BTW! I know this stuff gets kinda > > frustrating & tedious, but remember that you are in territory that has been a > > problem for wine since time immemorial. > > Thanks. I'm hoping that when I've got a grip on all this and settled > into uni I'll be able to write some more docs so in future people don't > have to spam the list to learn Wine OLE hacking. Unless you don't like beer you'll probably find you won't have nearly as much time for hacking code when you get to Uni as you'd think, or want, or like

2 1

question about icon,bitmap,cursor resources in user.dll
by Jonathan Wilson 24 Jul '03

24 Jul '03

I notice that some of the icons, cursors and bitmaps used in the user of wine (for example, the 4 icons used in message boxes) look just like the windows ones. How can wine have them looking just like the windows ones and not violate microsoft copyright? Or are they copyright violations but WINE just hasnt been sued yet?

2 1

I need card back bitmaps
by Jonathan Wilson 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. (e.g. the empty ace piles in solitare) back 67 big red X on a dark green background (the green is RGB 0 128 0, it has to match the background used in e.g. solitare, the red should be a bright red) 68 big bright green O on a dark green background (green is as above, other green should be bright green) Basicly, I need them to not be a potential MS copyright violation but at the same time I need them to look "similar" to the MS ones so that they dont look out of place in solitare and stuff. These 3 are important because cards.dll has a 3 special drawing modes that draws them.

1 0

Re: Define WINEPREFIX if it doesn't exist
by Alexandre Julliard 24 Jul '03

24 Jul '03

Dmitry Timoshkov <dmitry(a)baikal.ru> writes: > Define WINEPREFIX if it doesn't exist. Why do you need that? -- Alexandre Julliard julliard(a)winehq.com

2 10

Re: Typelib marshalling BSTRs
by Robert Shearman 23 Jul '03

23 Jul '03

> Subject: Re: Typelib marshalling BSTRs > From: Mike Hearn <mike(a)theoretic.com> > To: "Gregory M. Turner" <gmturner007(a)ameritech.net> > Cc: wine-devel(a)winehq.com > Date: 23 Jul 2003 16:28:58 +0100 > > So, moving on from that problem, I think my woes (currently) are caused > by the NDR engine not handling VT_DISPATCH variants. > > in wire_size(): > case VT_DISPATCH: > FIXME("wire-size interfaces\n"); > > 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. I don't know about NdrInterfacePointerMarshall, but I don't think it should get there to start with (see below). BTW, I think the two spellings depends on whether the word is used as a verb or as a noun. > While rather roundabout, I think it seems clear that this is what's > needed. The problem then becomes one of NdrInterfacePointerMarshall() > needing information that isn't available from inside > VARIANT_UserMarshal, like the MIDL_STUB_BUFFER pointer. > > Greg, as you are the relevant Guru here and Ove is probably a bit pissed > off with all my questions, what should we be doing here? If we are meant > to use NdrInterfacePointerMarshall to handle VT_DISPATCH variants, how > do we get the args it needs? Ok, my name's not Greg or Ove, but I'll have a go anyway. I think the code should not try to marshal/unmarshal the data in rpcrt4, but should use the PSOAInterface code in oleaut32 (according to the registry entry for Interfaces\[CLSID of IWebBrowser2]\ProxyStubClsid32). It would probably be best to find out why this is not happening (maybe by moving some oleaut32 code to rpcrt4?). Rob

2 1

visual age c++ Project
by ahmed hafez 23 Jul '03

23 Jul '03

2 1

What's the problem with the winelib dll generated by winemaker.
by dd jj 23 Jul '03

23 Jul '03

Hello everyone, I built a ping.dll.so from windows source codes using winemaker, (these source codes works under MS visual studio, also windows version dll works find under wine.)I did in this way: 1) put all the windows version source files-pingdll.h,pingdll.c,pingdll.dll,pingdll.dsp in one directory; 2) %winemaker --lower-uppercase . 3) %./configure --with-wine-includes=/usr/local/include/wine/windows 4) %make Aftter ping.dll.so is generated, I put it under /usr/local/bin/wine/ , also change my wine config (.wine/config) by adding "pingdll" = "builtin, native"; When I run my application under wine: %wine ./ping.exe (pingdll work for ping.exe) the program terminates... when I use winedbg to run it, there's error message shown there: .... ... ... ... No debug information in 32bit DLL 'C:\WINDOWS\SYSTEM\PINGDLL.DLL' (0x40ae0000) *** Invalid address 0x400016fc8 (_end+ox401587c) No debug information in ELF '/usr/local/lib/wine/pingdll.dll.so' (0x40ada000) Invalid address for breakpoint 1, disabling it Invalid address for breakpoint 2, disabling it Process of pid=0000000a has terminated I used Redhat 9.0 and wine-2003-06-18, Could one one help me out of this? thank you very much. -Lechun --------------------------------- Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software

1 0

what is the "correct" way to put a bitmap into a resource file?
by Jonathan Wilson 23 Jul '03

23 Jul '03

I see that all the wine dlls put the bitmaps in the resource file directly... Whats the best way to do it for a 32 bit wine dll (in this case cards.dll) amd where can I find a program to do it for me?

4 3

Re: [resend] Ensure ole32.dll gets correct version number
by Alexandre Julliard 23 Jul '03

23 Jul '03

Mike Hearn <mike(a)theoretic.com> writes: > diff -u -r1.1 version.rc > --- dlls/ole32/version.rc 28 Mar 2003 19:33:04 -0000 1.1 > +++ dlls/ole32/version.rc 13 Jul 2003 13:09:17 -0000 > @@ -21,4 +21,8 @@ > #define WINE_OLESELFREGISTER > #define WINE_FILENAME_STR "ole32.dll" > > +#define WINE_FILEVERSION_STR "2.0" > +#define WINE_FILEVERSION 2,0,0,0 > + > #include <wine/wine_common_ver.rc> Version 2.0 is awfully old for ole32.dll. Why do you need that? -- Alexandre Julliard julliard(a)winehq.com

2 3

_setjmp calls in user32 cause a failure in linking on Mingw
by Steven Edwards 23 Jul '03

23 Jul '03

Here is the problem: ../../windows/cursoricon.o(.text+0x3909): In function `LoadImageA': e:/source/winehq/wine/dlls/user/../../windows/cursoricon.c:2005: undefined refer ence to `_setjmp' lstr.o(.text+0x659): In function `CharLowerA': e:/source/winehq/wine/dlls/user/lstr.c:375: undefined reference to `_setjmp' lstr.o(.text+0x709): In function `CharUpperA': e:/source/winehq/wine/dlls/user/lstr.c:402: undefined reference to `_setjmp' C:\mingw\bin\dllwrap.exe: C:\mingw\bin\gcc exited with status 1 make: *** [user32.dll] Error 1 We need to do something about the exception handling on the Mingw build for this and rcprt4. I assume the same problem will exist on cygwin. Can we set a conditional link for msvcrt/cygwin like we do for libwine? Capser has sent me this patch for exception handling but I dont really understand all of this so any suggestions? Thanks Steven Index: include/wine/exception.h =================================================================== RCS file: /home/wine/wine/include/wine/exception.h,v retrieving revision 1.22 diff -u -p -u -r1.22 exception.h --- include/wine/exception.h 4 Jan 2003 00:19:17 -0000 1.22 +++ include/wine/exception.h 9 Jul 2003 19:14:16 -0000 @@ -74,6 +74,15 @@ #else /* USE_COMPILER_EXCEPTIONS */ +#if defined(WIN32) + +#define __TRY do { do +#define __EXCEPT(func) while(0); } while(0); +#define __FINALLY(func) while(0); } while(0); +#define __ENDTRY + +#else /* !WIN32 */ + #define __TRY \ do { __WINE_FRAME __f; \ int __first = 1; \ @@ -114,6 +123,7 @@ } \ } while (0); +#endif /* !WIN32 */ typedef DWORD (CALLBACK *__WINE_FILTER)(PEXCEPTION_POINTERS); typedef void (CALLBACK *__WINE_FINALLY)(BOOL); @@ -121,9 +131,19 @@ typedef void (CALLBACK *__WINE_FINALLY)( #define WINE_EXCEPTION_FILTER(func) DWORD WINAPI func( EXCEPTION_POINTERS *__eptr ) #define WINE_FINALLY_FUNC(func) void WINAPI func( BOOL __normal ) +#if defined(WIN32) + +#define GetExceptionInformation() (NULL) +#define GetExceptionCode() (0) +#define AbnormalTermination() + +#else /* !WIN32 */ + #define GetExceptionInformation() (__eptr) #define GetExceptionCode() (__eptr->ExceptionRecord->ExceptionCode) #define AbnormalTermination() (!__normal) + +#endif /* !WIN32 */ typedef struct __tagWINE_FRAME { __________________________________ Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software http://sitebuilder.yahoo.com

1 0

Do the winelib and winegcc tools and so on define WIN32?
by Jonathan Wilson 23 Jul '03

23 Jul '03

If not, they should (IMHO). Any compiler that provides windows.h & friends and proporting to act like a win32 compiler (i.e. accepting win32 code and so on) should be defining WIN32. Testing #ifdef WIN32 is the easiest way to say "if we are building on windows do x, if not do y" And, for all practical purposes (from the perspective of source code anyway), building on winelib should be the same as building on windows (isnt that the point of winelib) MingW, Visual C++ and Cygwin with -mno-cygwin (which is basicly MingW) all define WIN32. And I would assume that Watcom, Borland and others probobly do as well although I dont have those to check.

3 2

Re: I am going to implement cards.dll
by Brian Vincent (C) 23 Jul '03

23 Jul '03

> BTW, I am going to use the cards from http://www.jfitz.com/cards/index.html. > As for the backs, anyone want to draw some? :) Sure... how many "decks" would you like? Would you like them to be the same size as the ones on that link? There's several different partial views of cards, would you like those too? I'll likely do them as a 16-color pallete unless someone has an objection. --------------- Brian Vincent Copper Mountain Telecom vincentb(a)coppercolorado.com

4 3

Visual Sourcesafe works much better than last year...
by Dan Kegel 23 Jul '03

23 Jul '03

Last time I tried running Microsoft Visual Sourcesafe's gui tools under Wine (six months or a year ago), it had Z-ordering and/or visibility problems, and was only partially usable. Now those problems are all gone, and ssexp.exe is from what I can tell quite functional (if bloody slow over smbfs). It still doesn't update the journal with your changes, so the ss admin will think you're sneaking in changes by magic, but progress is progress. Kudos! - Dan -- Dan Kegel http://www.kegel.com http://counter.li.org/cgi-bin/runscript/display-person.cgi?user=78045

1 0

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

wine-devel