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

cXXFrameHandler

by Steven Edwards

Just wanted to say thanks and let you know that geoshell now works in WINE on my slackware 8 box. This is great because once the ReactOS boys get the windowing work done it wont take much adapting at all for us to have this as our shell. And for the time being I have a good interface to CVS under linux. =) Thanks Again Steven __________________________________________________ Do You Yahoo!? Yahoo! Health - Feel better, live better http://health.yahoo.com

July 28, 2002

Re: CUPS and Wine

by Joshua Thielen

Andreas Mohr wrote: > AFAIR we also have a bug reported for that, and if there isn't one, > then it's about high time to create one. Yep, I entered a bug report on this a while ago. It is bug #823 (http://bugs.winehq.com/show_bug.cgi?id=823) -Josh Thielen

July 28, 2002

Re: CUPS and Wine

by David D. Hagood

Andreas Mohr wrote: > Add to that the fact that CUPS gets rather completely rid of the useful > Unix filter machanism, and you really start to wonder whether CUPS really > is better than say lpd+printtool. Quite the other way around or so... Actually, I do beleive that CUPS does use a filter mechanism internally. But I do agree - I'm not as sure that CUPS is all that much better. But to REALLY fix printing would mean far more than what CUPS can do - IMHO what we need is more of a RPC style system, where the client app communicates bidirectionally with the print server, so that the client can ask "What can you do for me?", the server responds "I can staple, collate, bind, and add gold leaf inlay", and the client can present that to the user. Maybe some sort of XML/SOAP sort of thing.... (-1, Offtopic). > Known problem :-\ > CUPS *should* be totally easy to set up in Wine, yet for some reason > Wine stumbles hard and dies instantly. Then I respectfully suggest the the documentation should reflect this - I had a perfectly good LPRng system running, and the only problem was getting Wine to talk to my color printer. "CUPS is GREAT" sayth the docs, so installth CUPS shall I do.... > If noone has a stab at fixing this, then maybe I'll have some time to fix > it. Don't ask for a close look at my ToDo list, though... ;-) Know the feeling... > AFAIR we also have a bug reported for that, and if there isn't one, > then it's about high time to create one. > I was going to do this very thing (I am a big champion of Bugzilla at my place of employ - I have the attitude of "If there ain't a bug agin it, it don't exist!") but when I try to query the Bugzilla database, I get: Please stand by ... Content-type: text/html Software error: SELECT bugs.bug_id, bugs.groupset, substring(bugs.bug_severity, 1, 3), substring(bugs.priority, 1, 3), substring(bugs.rep_platform, 1, 3), map_assigned_to.login_name, substring(bugs.bug_status,1,4), substring(bugs.resolution,1,4), substring(bugs.short_desc, 1, 60) FROM bugs, profiles map_assigned_to, profiles map_reporter LEFT JOIN profiles map_qa_contact ON bugs.qa_contact = map_qa_contact.userid, longdescs longdescs_ WHERE bugs.assigned_to = map_assigned_to.userid AND bugs.reporter = map_reporter.userid AND bugs.groupset & 0 = bugs.groupset AND longdescs_.bug_id = bugs.bug_id AND (bugs.product = 'Wine') AND (bugs.bug_status = 'NEW' OR bugs.bug_status = 'ASSIGNED' OR bugs.bug_status = 'REOPENED') AND (INSTR(LOWER(longdescs_.thetext), 'cups')) GROUP BY bugs.bug_id ORDER BY bugs.priority, bugs.bug_severity: Can't write, duplicate key in table 'longdescs_' at globals.pl line 231. For help, please send mail to the webmaster (webmaster(a)codeweavers.com) giving this error message and the time and date of the error.

July 27, 2002

Re: CUPS and Wine

by Michael Stefaniuc

On Sat, Jul 27, 2002 at 11:53:57PM +0200, Andreas Mohr wrote: > On Sat, Jul 27, 2002 at 12:13:57PM -0500, David D. Hagood wrote: > > I've been having trouble with my RH7.2 LPRng based printing, so I > > decided I'd try installing CUPS. After fighting for hours to get this > > so-called easier printing system installed and working, I finally got to > > where I could print from Linux apps. Now, however, Wine steadfastly > > refuses to bring up a meaningful print dialog. > Yep, I've always been asking myself how this company came to name itself > Easy Software Products. > At least the CUPS install on Debian is rather problematic. > You even have to type in printer URLs *by hand* in several cases ! > The menu choices are not exactly non-confusing. > A web-based system could be considered to be *made* for a good > context-sensitive help system, yet there's none to be found. > > I also encountered some string garbage (typical stray pointer or so) > in the printer URL input some months ago. > > Add to that the fact that CUPS gets rather completely rid of the useful > Unix filter machanism, and you really start to wonder whether CUPS really > is better than say lpd+printtool. Quite the other way around or so... It IS realy better, especialy if you have a lot of machines and real printers with many options (different trays, duplex, etc.). And the non technical people just love the graphical print tools (qtcups, gtklp kprinter). And the best feature (best for me :) of cups is that it significantly reduces the "I can't print" helpdesk requests. Setup the printserver and for the clients all what you need to do is to install cups and start it, nothing more. You can still use filter, you can define them in ppd file, but normaly you don't need them because today most people print from applications and not from the command line and the applications use postscript as output. bye michael -- Michael Stefaniuc Tel.: +49-711-96437-199 System Administration Fax.: +49-711-96437-111 Red Hat GmbH Email: mstefani(a)redhat.com Hauptstaetterstr. 58 http://www.redhat.de/ D-70178 Stuttgart

July 27, 2002

Re: CUPS and Wine

by Andreas Mohr

On Sat, Jul 27, 2002 at 12:13:57PM -0500, David D. Hagood wrote: > I've been having trouble with my RH7.2 LPRng based printing, so I > decided I'd try installing CUPS. After fighting for hours to get this > so-called easier printing system installed and working, I finally got to > where I could print from Linux apps. Now, however, Wine steadfastly > refuses to bring up a meaningful print dialog. Yep, I've always been asking myself how this company came to name itself Easy Software Products. At least the CUPS install on Debian is rather problematic. You even have to type in printer URLs *by hand* in several cases ! The menu choices are not exactly non-confusing. A web-based system could be considered to be *made* for a good context-sensitive help system, yet there's none to be found. I also encountered some string garbage (typical stray pointer or so) in the printer URL input some months ago. Add to that the fact that CUPS gets rather completely rid of the useful Unix filter machanism, and you really start to wonder whether CUPS really is better than say lpd+printtool. Quite the other way around or so... > I've gone into system.reg and win.ini and removed all the entries > relating to the printing system, to no avail. Wine sort of recognises > that there is a printer named "Color" managed by CUPS, but it cannot get > any kind of properties for it - no paper size, no queue, and any attempt > to accept the dialog is either ignored or results in a fault. > > This is with a CVS pull and clean rebuild as of 30 minutes ago. > > Where do I go from here? Known problem :-\ CUPS *should* be totally easy to set up in Wine, yet for some reason Wine stumbles hard and dies instantly. If noone has a stab at fixing this, then maybe I'll have some time to fix it. Don't ask for a close look at my ToDo list, though... ;-) AFAIR we also have a bug reported for that, and if there isn't one, then it's about high time to create one. -- Andreas Mohr Stauferstr. 6, D-71272 Renningen, Germany Tel. +49 7159 800604 http://mohr.de.tt

July 27, 2002

Re: CallNextHookEx16 strageness

by Michael Stefaniuc

On Tue, Jul 23, 2002 at 03:18:04PM -0700, Alexandre Julliard wrote: > Michael Stefaniuc <mstefani(a)redhat.de> writes: > > > It seems that we don't have an implicit transformation of a HHOOK to a > > HANDLE16. Most of the internal HOOK_* functions are using HANDLE16's and > > the few functions that accepts as parameter a HHOOK are checking for the > > presence of the HOOK_MAGIC and are doing the conversion to a HANDLE16 > > with LOWORD(hhook). > > Well yes, the hook functions are mostly using HANDLE16 internally, but > it would be much better to change them to use HHOOK. There isn't much > point in making HHOOK work with -DSTRICT if we don't use it anywhere. Hmm ... looking at windows/hook.c i guess that we have to keep using with HOOKDATA, MESSAGEQUEUE, USER_HEAP_LIN_ADDR, etc. and this ones are using HANDLE16. HOOK_systemHooks could be changed to HHOOK, but this would introduce a lot of conversions. I've changed all internal HOOK_* functions to pass only HHOOK's to each other. I've kept the use of HANDLE16 in functions that make extensive use of HOOKDATA and MESSAGEQUEUE but changed the variables name from hook to handle to not produce confusion. > - return CallNextHookEx16( WH_SHELL, code, wParam, lParam ); > + return CallNextHookEx16( (HHOOK)MAKELONG(WH_SHELL, HOOK_MAGIC), code, > + wParam, lParam ); > > WH_SHELL is not a valid hook handle, this code is broken (of course it > was broken before too). ShellHookProc is only a win < win95 function and I couldn't find any documentation for it (searching on msdn revealed nothing) so i've made a separat patch for it, but it's a pure guesstimation. License: LGPL, X11 Changelog: Michael Stefaniuc <mstefani(a)redhat.com> - converted HHOOK to a void* - changed the internal HOOK_* functions to pass only HHOOK's between them - fixed wrong HHOOK <-> HANDLE16 conversions bye michael -- Michael Stefaniuc Tel.: +49-711-96437-199 System Administration Fax.: +49-711-96437-111 Red Hat GmbH Email: mstefani(a)redhat.com Hauptstaetterstr. 58 http://www.redhat.de/ D-70178 Stuttgart

July 27, 2002

Re: PATCH: temp fixes, again

by Joerg Mayer

On Sat, Jul 27, 2002 at 09:13:09AM -0700, Alexandre Julliard wrote: > The bug is that the temp file is created with mode 0666. But you can't > do a configure check for a run-time feature/bug anyway. Well, this bug doesn't really matter. If it matters, people will long have installed a fixed libc, if they don't care, it doesn't matter. There are tons of programs out there that use this function, why should wine be the one application that cares about the existence of old bugs. You are right about checking for runtime bugs, though. ciao Jörg -- Joerg Mayer <jmayer(a)loplof.de> I found out that "pro" means "instead of" (as in proconsul). Now I know what proactive means.

July 27, 2002

question on _lclose16

by Rafael Kitover

In files/file.c, line 1351: HFILE16 WINAPI _lclose16( HFILE16 hFile ) { if (hFile < 5) { FIXME("stdio handle closed, need proper conversion\n" ); SetLastError( ERROR_INVALID_HANDLE ); return HFILE_ERROR16; } .... What does this mean? Taking it out doesn't seem to hurt anything. I understand from this block: static void FILE_InitProcessDosHandles( void ) { dos_handles[0] = GetStdHandle(STD_INPUT_HANDLE); dos_handles[1] = GetStdHandle(STD_OUTPUT_HANDLE); dos_handles[2] = GetStdHandle(STD_ERROR_HANDLE); dos_handles[3] = GetStdHandle(STD_ERROR_HANDLE); dos_handles[4] = GetStdHandle(STD_ERROR_HANDLE); } why we don't want to close those handles probably. But why would I see that message, do sloppy windows programs try to close a range of handle numbers or something? Tell me what needs to be properly converted to what and I'll try to do it :P

July 27, 2002

CUPS and Wine

by David D. Hagood

I've been having trouble with my RH7.2 LPRng based printing, so I decided I'd try installing CUPS. After fighting for hours to get this so-called easier printing system installed and working, I finally got to where I could print from Linux apps. Now, however, Wine steadfastly refuses to bring up a meaningful print dialog. I've gone into system.reg and win.ini and removed all the entries relating to the printing system, to no avail. Wine sort of recognises that there is a printer named "Color" managed by CUPS, but it cannot get any kind of properties for it - no paper size, no queue, and any attempt to accept the dialog is either ignored or results in a fault. This is with a CVS pull and clean rebuild as of 30 minutes ago. Where do I go from here?

July 27, 2002

Re: PATCH: temp fixes, again

by Andreas Mohr

On Sat, Jul 27, 2002 at 09:13:09AM -0700, Alexandre Julliard wrote: > Marcus Meissner <meissner(a)suse.de> writes: > > > This has been some time ago, and those old libc versions should not be used > > anymore for security reasons. > > Well the man page says "Don't use this function", and if it's broken > in old glibc it can be broken on other systems too. I think it's safer > to do the open ourselves, especially since this is pretty trivial to > do. I think X11 is pretty arcane and not very flexible. Thus we should probably write our own display interface. And last time I checked, Linux froze my whole system due to sound bugs, and as they don't fix it, Linux is totally unreliable, so let's write our own sound hardware driver for Wine (and thus of course replace the whole OS). That ok for you ? I guess not. Modularity is there for a reason, so if we can make use of it, we should. Now if the phrase "Don't use this function" does have some real reason for its existence, then we should rewrite the functionality, of course. (note that some people believe that man pages are always outdated) Otherwise just use that function, I'd say... (OTOH it's pretty small, so maybe really give up and just write our own) -- "My attitude is, everybody should try competing with Microsoft once in their life. Once." - Marc Andreessen, former Netscape lead employee, in a "browser wars" interview

July 27, 2002