wine-devel

wine-devel@winehq.org

4 participants
84464 discussions

Screenshots
by Mike Hearn 20 Nov '02

20 Nov '02

Hi, I'm happy to put together some screenshots on my RedHat 8 box at work (pretty much default install albiet with a slightly customised gnome2 layout). However it strikes me that having people just randomly send shots to Brian isn't the best way to go about it as nobody knows who has sent what. Have you actually got any yet Brian? If not, are there any apps you'd like to me make screenshots of? I currently have IE6 and WinZip installed, but can go install more if they are freely available on the net. thanks -mike -- Mike Hearn <m.hearn(a)signal.qinetiq.com> QinetiQ

1 0

About picture format.
by yf 20 Nov '02

20 Nov '02

I'm using a application that using 0x0010 picture format. I found that wine only support Bitmap and JPEG picture format. Where can I get some info about it. I want to implement it. Pls give me some hints about it.

2 2

Re: the dreaded rpcss patch (rpc_J_PL0)
by Alexandre Julliard 20 Nov '02

20 Nov '02

Greg Turner <gmturner007(a)ameritech.net> writes: > * configure; > configure.ac; > dlls/rpcrt4: .cvsignore, Makefile.in, rpc_binding.h, rpcrt4.spec, > rpcrt4_main.c, rpc_epmap.c (new); > include: rpcdce.h, rpcdcep.h, rpcndr.h, winbase.h; > include/wine: rpcss_shared.h (new); > programs: Makefile.in; > programs/rpcss (new dir): .cvsignore (new), Makefile.in (new), > README (new), atomicity.c (new), epmap_server.c (new), > named_pipe_kludge_client.c (new), named_pipe_kludge_server.c (new), > rpcss.h (new), rpcss_main.c (new): > Greg Turner <gmturner007(a)ameritech.net>, > Ove Kåven <ovek(a)transgaming.com> > - a preliminary implementation of endpoint-mapping via a new > on-demand server-ish process ("rpcss.exe.so") > - more header fixups > - (re)implement RpcEpRegisterA, RpcEpUnregister, and RpcEpResolveBinding > using the new rpcss functionality > - update the todo list in rpcrt4_main.c a bit A few things: - Please don't name files 'kludge_something'; this makes it impossible to implement things properly without renaming files. - Don't share C files between rpcrt4 and rpcss, just copy the stuff you need (and at least atomicity.c doesn't seem necessary at all, you could just as well make mutex calls directly). - Please get rid of the various #ifdefs. - It would be better to put the README documentation directly in rpcss_main.c, people don't notice README files in subdirectories. -- Alexandre Julliard julliard(a)winehq.com

2 4

Diablo II fails after a recent cvs update..
by Dustin Navea 20 Nov '02

20 Nov '02

Going to start Diablo II after an update last night (after not updating for a couple of days) causes a crash. What debugmsgs would be needed to fix this I dunno, but I suppose I could do a regression test.. Anyone wanna take a look after I post the results of the regression test (probably some time thursday)? -Dustin

1 0

Wine merge required: COM/OLE header changes
by Ove Kaaven 20 Nov '02

20 Nov '02

These patches are against ReWind and requires some merging work in order to apply to Wine. Could someone (hm... Greg?) do that for me? The fundamental idea here is to make sure that no files except unknwn.h ever include wine/obj_base.h directly, because the IUnknown interface definition will soon move to unknwn.h, and the API function prototypes will move to objbase.h (which indirectly includes unknwn.h through objidl.h). While I was at it, I also made sure that a couple of common to-be-IDL-generated files aren't included directly, as the headers in question have wrapper headers that are supposed to contain related API function prototypes - these prototypes will also be moved later, so I thought I might as well ensure that the wrapper headers are used now. The attached comhdr1.diff contains header changes and #ifdef guards that force a compilation error if any of these "forbidden" headers are included directly. It seems to apply to Wine as-is. (And I think the #ifdef guards should be applied to Wine even if #ifdefs aren't popular around here, because it protects against introduction of new bad code in Wine while the conversion is in progress; and when a particular header has been successfully converted, its respective #ifdef guard will of course be removed again.) The attached comhdr2.diff seems to fix all the resulting compilation errors in ReWind, and is what needs "merging". Apply as much of it as you can and fix the compilation errors that remain in Wine. Thanks.

2 1

RE: Configure question
by Patrik Stridvall 19 Nov '02

19 Nov '02

> Patrik Stridvall <ps(a)leissner.se> writes: > > > Still I think the code should verify that any assumptions > > made str really true, if possible. Like: > > > > #if defined(HAVE_GETPWUID) || defined(HAVE_GETPWNAM) || > > defined(HAVE_GETPWENT) > > # if !(defined(HAVE_GETPWUID) && defined(HAVE_GETPWNAM) && > > defined(HAVE_GETPWENT)) > > # error All or none of the functions getpwuid, getpwnam > and getpwent are > > assumed to exist > > # endif > > #endif > > There is absolutely no reason to do that, because we shouldn't assume > anything like that. As I said, if you use getpwnam() you check for > HAVE_GETPWNAM; whether getpwuid() also exists or not is completely > irrelevant. Well, the problem is it is possible that you in order to fail gracefully needs to do different things depending on whether some other function exists or not. OK, the functions meantioned above are not likely to have side effect or something else that effect the other functions in any relevant way. But there might be function pairs, tripples etc that does. Sure you can say that since any function might fail any code should always be able to handle a missing function as well since it in some abstract meaning it sufficiently similar to a normal failure. But regardless, I think it is good to make it clear that he or she who wrote expects certain things to be true and things might not work if they are not true. I somebody hits the "assertion" they can audit the code and if it seems that it doesn't matter they can modify the "assertion" to whatever is proper in the light of the new different enviroment. If it does matter they will modify the code accordingly... Somehow this seems much better than just hoping that the orginal programmer handled all error cases correctly...

1 0

RE: Configure question
by Patrik Stridvall 19 Nov '02

19 Nov '02

> Martin Wilck <Martin.Wilck(a)fujitsu-siemens.com> writes: > > > Very true. Perhaps the practical way would be to assume > > HAVE_GETPWUID == HAVE_GETPWNAM and see whether someone with > > a really strange platform complains (but see below). > > There's no reason to do that, it's trivial to check for both. If you > use getpwnam() check for HAVE_GETPWNAM, if you use getpwuid() check > for HAVE_GETPWUID. Simple, logical, and works even on strange > platforms. Of course. It was so obvious that I missed it. :-) Still I think the code should verify that any assumptions made str really true, if possible. Like: #if defined(HAVE_GETPWUID) || defined(HAVE_GETPWNAM) || defined(HAVE_GETPWENT) # if !(defined(HAVE_GETPWUID) && defined(HAVE_GETPWNAM) && defined(HAVE_GETPWENT)) # error All or none of the functions getpwuid, getpwnam and getpwent are assumed to exist # endif #endif

2 1

RE: Stub implementation of CABINET.DLL
by Patrik Stridvall 19 Nov '02

19 Nov '02

> >However, when I saw that not much happend despite > >getting code from cabextrect under LGPL I thought > >that perhaps people were having trouble on how > >to create a new DLL in Wine and how to extract > >the declarations from the Microsoft header without > >creating a derived work. I have done it many > >times before so thought why not do it... > > > >So I very happy that somebody is intrested in continuing. > > > >PS. If anybody have some other DLL that they wish to implement > >but don't now how to do it, don't hesitate to ask me to > >create a stub DLL with related headers. > > If it is not too much effort, could you elaborate on the > derived work issue. I have been thinking about trying to > stub out, then work at implementing, a particular component. > Rather than have someone else do the work, I am more > interested in learning about doing it myself, and about > any issues (legal and technical) involved. > I am not asking for a complete howto here, but even a > summary of the highlights would be quite valuable (to me > at least). First of all copyright doesn't protection facts or ideas only a specific (and unique) expression of facts and ideas. This is normally called a work. Specifically it doesn't protect any underlying functionally inherent or derivable from the work. This is normally called the implementation of the functionallity. Even more specifically it doesn't protect the way interaction with any functionallity, that is possible to derived from the work, is done. This is normally called the interface to the functionallity. Header files for the most part defines interfaces; more specifically constant declarations (read: defines), function declarations, type declarations and. So all such things are free for taking. However netherless the less, the header file is not entirely free of possible protected expression. Specifically: 1. Formatting 2. Comments 3. Inline functions and complex macros I will address each them in turn. Formatting is not normally any problem since there are not that many way to format C declarations, none of which is likely to be unique to Microsoft, let alone expressive. Still I always format the new file in a way I personally like, just in case. Comments are are probably the largest proplem. They are not strictly part of the interface so if you are unsure you can just remove them. In most cases, in fact the intresting cases, however they contains facts about the interface. Note however I said _contains_ facts not are facts. Part of them might be protected expression so we have to be careful here. Again, note that in order to be protected an expression have to unique as well as expressive. Most short sentences are neither unique, nor are they expressive, they just explain the facts in some straight forward way. Still if the not formulated in a way I as well would use the express myself I rewrite them. As for longer sentences and specificially multi sentence paragraphs. I usually delete or reformulate and often shorten it using my own words. The comments are, as I said, not strictly needed in for the header file to work. Inline function and complex macros can be a little tricky. However they are usually rare so rewriting them in a way I would have written it is not that much work and functinallity in itself is I said explain above not protected by copyright.

1 0

RE: Get rid of W->A calls: LoadImageW
by Patrik Stridvall 19 Nov '02

19 Nov '02

> > Index: wine/windows/cursoricon.c [snip] > > - if (!screen_dc) screen_dc = CreateDCA( "DISPLAY", > NULL, NULL, NULL ); > > + if (!screen_dc) screen_dc = CreateDCW( DISPLAYW, [snip] > I don't see the point of this at all. Why does it matter that we're > calling CreateDCA here? it's not as if we're losing information by > converting a Unicode to an Ascii string. Policy reason: "No Unicode function should call an ASCII function if a Unicode variant of that function exists." But sure semantically speaking it might not make any difference in this case.

1 0

Re: problem with treeview
by steve.lustbader＠philips.com 19 Nov '02

19 Nov '02

Here's the output from +treeview: <App starting up> trace:treeview:TREEVIEW_Register trace:treeview:TREEVIEW_Register trace:treeview:TREEVIEW_Register <I press button to open dialog containing treeview> trace:treeview:TREEVIEW_Create wnd 0x2006a, style 40010027 trace:treeview:TREEVIEW_SetFirstVisible (nil): <null item> trace:treeview:TREEVIEW_SetFont 0x3a6a 0 trace:treeview:TREEVIEW_Create wnd 0x20068, style 40010027 trace:treeview:TREEVIEW_SetFirstVisible (nil): <null item> trace:treeview:TREEVIEW_SetFont 0x3a6a 0 trace:treeview:TREEVIEW_DeleteItem TVI_ROOT trace:treeview:TREEVIEW_ValidItem invalid item (nil) trace:treeview:TREEVIEW_ValidItem invalid item (nil) trace:treeview:TREEVIEW_ValidItem invalid item (nil) trace:treeview:TREEVIEW_ValidItem invalid item (nil) trace:treeview:TREEVIEW_SetFirstVisible (nil): <null item> trace:treeview:TREEVIEW_DeleteItem TVI_ROOT trace:treeview:TREEVIEW_ValidItem invalid item (nil) trace:treeview:TREEVIEW_ValidItem invalid item (nil) trace:treeview:TREEVIEW_ValidItem invalid item (nil) trace:treeview:TREEVIEW_ValidItem invalid item (nil) trace:treeview:TREEVIEW_SetFirstVisible (nil): <null item> trace:treeview:TREEVIEW_InsertItemA parent 0x41230a98 position 0xffff0002: '<callback>' trace:treeview:TREEVIEW_DoSetItem setting callback, item 0x41232060 trace:treeview:TREEVIEW_InsertItemA new item 0x41232060; parent 0x41230a98, mask 5 trace:treeview:TREEVIEW_GetNextItem flags:3, item 0x41232060;returns (nil) wine: Unhandled exception, starting debugger... "Dustin Navea" <Speeddymon@ev1. To: Steve Lustbader/ANR/MS/PHILIPS@AMEC net> <wine-devel(a)winehq.org> cc: 11/19/2002 03:35 Subject: Re: problem with treeview PM Classification: Try running wine with --debugmsg +treeview and post that somewhere to look at.. -Dustin ----- Original Message ----- From: <steve.lustbader(a)philips.com> To: <wine-devel(a)winehq.org> Sent: Tuesday, November 19, 2002 1:51 PM Subject: problem with treeview > My app calls TreeView_InsertItem, which leads to a crash in ntdll.dll. > A backtrace is available at http://www.lustbader.net/bt.txt, and I can > provide any other debug output if anyone thinks it will help. > TreeView_InsertItem is called like this: > > TVITEM tviFoo; > tviFoo.mask = TVIF_TEXT | TVIF_PARAM; > tviFoo.pszText = LPSTR_TEXTCALLBACK; > tviFoo.lParam = (LPARAM)pFoo; //pFoo is guaranteed to be non-NULL > TVINSERTSTRUCT tvinsFoo; > tvinsFoo.hParent = TVI_ROOT; > tvinsFoo.hInsertAfter = TVI_LAST; > tvinsFoo.item = tviFoo; > HTREEITEM hTreeFoo = TreeView_InsertItem(m_hWndUserTree, &tvinsFoo); > > Any ideas? > > -Steve > > >

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