April 2004 - Wine-Devel - list.winehq.org

When saving a file with staroffice it is not saving with extension.

by Ravi Kumar

Hello Sir, I am working with wine for some time now. I faced with a problem, whenever i am saving a file from Windows version of Staroffice from wine it is saved without extension. I think it is a problem with wine, as staroffice in windows stores files with extensions. I am using wine-20031118 version. Can anybody help me out in this regard. I will also check out to see if it has been solved in later versions. Thanking in advance. regards, ravi.

April 2, 2004

Re: winapi_stats

by hatky

> Yes but it would still be interesting to know why the statistics where > wrong rather than just sweep the problem under the rug. As I told you, you can run the command ./tools/winapi/winapi_extract --pseudo-stub-statistics --no-verbose --no-progress > ../winapi_stats.txt and check the file (it is humanly readable), then either 1. Send a patch for that perl script your self 2. Open a bug in bugs.winehq.org 3. Report back here Remeber, this is not paid work, I do what I like, I like sites, and php, I do not know perl and have not wish to learn at this time. I know what your saying, but I have no intrest in checking it, sorry. > In your latest patch you filter out more dlls but you also duplicate Fixed and resent, 10x... -- Hatky, Worshiper of wine (http://www.winehq.org/) Impossible is only an opinion.

April 2, 2004

Re: GDI: Merge the enhmfdrv into one .c file.

by Mike McCormack

Dimitrie O. Paun wrote: > We'll, I've tried. But before objecting that strongly, hear me > out for a bit. The resulting file is not too big (~2000 lines), > which is on the order of a _small_ control. When I started working > on the listview, it was a 10000 line file. Initially I thought > this was a disaster, but after having worked with it, I wouldn't > have it much different now. > > Anyway, I don't mean to argue: you work on it, and so you get > to call the shots. All I'm saying is that judging by other > parts in Wine, is not such a bad change... Well, I think you're removing layout and order to fit this piece of code into a schema that doesn't really make sense to me. The layout of the EMF code was modelled after the X11DRV's DC implemenation. I agree that we should have one directory per dll in the dlls directory, however I don't think that means we can't have any subdirectories for various parts of the same dll in that one directory. If you go down this path, do you intend to merge dlls/user/dde and the various directories in dlls/ddraw into one directory too? Mike

April 2, 2004

Re: GDI: Merge the enhmfdrv into one .c file.

by Mike McCormack

I object! Being one of the people who sometimes works on EMFs, I don't like this change. A flat namespace in my mind meants that we have one dll's code in each subdirectory in wine/dlls, not that there's no other subdirectories under those. It's a bad precedent to set that each dll can have no further subdirectries. I don't think this change is necessary, and it's going to make the EMF code harder to manage, since the file you've created is very big. Ditto for the MF change. Mike Dimitrie O. Paun wrote: > Merge the entire enhmfdrv into one .c file. > It's not big, and it's the way we usually do > things in wine (e.g. dlls/comctl32/*.c). > Moreover, we get rid of the extra dir in > dlls/gdi/, and gets us closer to a flat > dlls/*/ namespace.

April 2, 2004

Re: GDI: Merge the enhmfdrv into one .c file.

by Dimitrie O. Paun

On April 2, 2004 1:37 am, Mike McCormack wrote: > I don't think this change is necessary, and it's going to make the EMF > code harder to manage, since the file you've created is very big. Ditto > for the MF change. We'll, I've tried. But before objecting that strongly, hear me out for a bit. The resulting file is not too big (~2000 lines), which is on the order of a _small_ control. When I started working on the listview, it was a 10000 line file. Initially I thought this was a disaster, but after having worked with it, I wouldn't have it much different now. Anyway, I don't mean to argue: you work on it, and so you get to call the shots. All I'm saying is that judging by other parts in Wine, is not such a bad change... -- Dimi.

April 2, 2004

Re: Developer's path to Windows/*NIX multi-platform?

by Dimitrie O. Paun

On April 1, 2004 6:30 pm, greensh(a)knology.net wrote: > I'd have to say, so far from what I've seen Wine still has a long way to go > before it's ready for production, and reliable use... it's getting there > but just not there yet. It's great for porting apps, but too poorly > documented for actual development. You are correct in that we're not as good as we'd like to be. We've done a lot of work, yet there's plenty more in front of us. That being said, I'd like to note a few things: 1. Qt/wxWindows/etc. is a good cross-platform solution if you start afresh. However, I strongly feel Wine is a better tool if you're porting a large application. 2. Even if you start fresh, there may be reasons you would still want to use Wine: you don't want to use C++, you know Win32 and you don't want to learn something else, you don't want to buy the commercial Qt license, you have some 3rd party binary DLLs that you have to use. 3. I don't think we suffer from so poor documentation. 99.9% of Wine is all about Win32, and the MSDN is a pretty good, freely available over the web source of documentation. Not to mention innumerable number of books and so on on the subject. We try hard to fit into existing standards, and in theory you should require very little Wine-specific documentation. We're not there yet, so in the interim feel free to ask on wine-devel. Bottom line, Wine is IMO an interesting option for a lot of projects. We just need a bit more manpower to iron out some of our bugs :) -- Dimi.

April 2, 2004

Re: abnt2 delete keys problem

by Dmitry Timoshkov

"Rafael аvila de EspМndola" <rafael.espindola(a)ic.unicamp.br> wrote: > > As far as I can see that's an X behaviour, we can do nothing about it. > > All I can suggest is to send a bug report to XFree86 people. > I don't think so. Both delete keys work with xterm, Qt and GTK2. Qt and GTK are known to use their own keyboard input modeles without relying on X. For instance dead-keys, Euro sign and national characters do not work in Wine (which uses pure X11 protocol) while they work in GTK and Qt applications. Your xev trace clearly shows that output in Wine exactly matches events generated by X server. Am I missing something? -- Dmitry.

April 2, 2004

Re: winapi_stats

by hatky

On Thursday 01 April 2004 22:40, Francois Gouget wrote: > Did you find what caused the API count discrepency for winearts.drv and > others? You said remove them................... > > I checked a bigger dll: user32 and got slightly different results. I > believe this is because your script worked on a slightly older version > of Wine. It is true I ran api_extract a few weeks ago and do not regenrate it each time, the main site will only regenerate it ever version that comes out, it was noted someplace.... > > In any case, here is how I checked so you can verify a few other dlls. > Count various categories of lines: All of numbers are take from the perl script winapi_extract with the fallowing line running it ./tools/winapi/winapi_extract --pseudo-stub-statistics --no-verbose --no-progress > ../winapi_stats.txt My work is only formatin this text file to an HTML page, you can run it, then my php script and it there are missmaches plz tell me If the txt file comming out is wrong, check that perl script to see what's wrong and either submit a patch or post to winedevel... -- Hatky, Worshiper of wine (http://www.winehq.org/) Impossible is only an opinion.

April 2, 2004

RE: MFC app compile problems with AFX

by Robert Shearman

Shaun wrote: > > /usr/local/include/wine/windows/rpcndr.h:383: error: non-local function ` > <anonymous struct>* NDRSContextUnmarshall2(void*, void*, long unsigned > int, > void*, long unsigned int)' uses anonymous type I can't see anything wrong with this declaration as it is in CVS. NDR_SCONTEXT (which is presumably what it is complaining about) is declared near the top exactly how it is in the MS SDK. You could try changing the declaration of NDR_SCONTEXT to use "typedef struct _NDR_SCONTEXT ..." instead of "typedef struct ...". > In file included from afxdtctl.h:19, > from StdAfx.h:18, > from ArbreNiv.cpp:2: On the headers that I have (VS6) afxdtctl.h doesn't directly include any rpc headers. > afxdisp.h:75: warning: malformed '#pragma pack(push[, id], <n>)' - ignored > afxdisp.h:1182: error: friend declaration requires class-key, i.e. `friend > struct COleDateTimeSpan' You need to fix the header to include the "class" keyword before the class name. > afxdisp.h:1259: error: friend declaration requires class-key, i.e. `friend > class COleDateTime' Ditto. > afxdisp.h:1408: warning: #pragma pack (pop) encountered without matching > #pragma pack (push, <n>) Looks harmless. > In file included from afxdisp.h:1413, > from afxdtctl.h:19, > from StdAfx.h:18, > from ArbreNiv.cpp:2: > afxole.inl: In constructor `COleVariant::COleVariant(const CHAR*)': > afxole.inl:97: error: `vt' undeclared (first use this function) > afxole.inl:97: error: (Each undeclared identifier is reported > only once for > each function it appears in.) > afxole.inl: In constructor `COleVariant::COleVariant(unsigned char)': > afxole.inl:101: error: `bVal' undeclared (first use this function) > afxole.inl: In constructor `COleVariant::COleVariant(const > COleCurrency&)': > afxole.inl:103: error: `cyVal' undeclared (first use this function) > afxole.inl: In constructor `COleVariant::COleVariant(float)': > afxole.inl:105: error: `fltVal' undeclared (first use this function) > afxole.inl: In constructor `COleVariant::COleVariant(double)': > afxole.inl:107: error: `dblVal' undeclared (first use this function) > afxole.inl: In constructor `COleVariant::COleVariant(const > COleDateTime&)': > afxole.inl:109: error: `date' undeclared (first use this function) > afxole.inl: In member function `DWORD COleSafeArray::GetDim()': > afxole.inl:283: error: `parray' undeclared (first use this function) Presumably some of them are caused by the friend errors above. > Can anyone help? Any ideas for me to try? I can run the winders > executable > with wine, but it's very buggy and will crash easily, so I wanted to use > winelib. Unfortunately, it is unlikely to improve the situation by compiling as winelib. Of course, you can debug the program slightly easier but at some point you will have to fix the same bugs in Wine. Rob

April 1, 2004

Re: ANNOUNCE: CVS to arch gateway

by Bruce Mellows

Troy Rollo wrote: > On Thu, 1 Apr 2004 23:37, Mike Hearn wrote: > >>On Thu, 01 Apr 2004 14:26:49 +0100, Mike Hearn wrote: >>Oh one other thing to mention is that hard linking trees together >>like the merge script does is sort of experimental with Wine. I've tried >>it and not seen any big issues as long as you use an editor that breaks >>hard links, but if you spot wierdness related to that let me know. > > > I'm surprised to hear there are any UNIX or Linux editors that break hard > links (which I take to mean that an edit should sever the link so that the > other location keeps the old copy). > > There are many situations in which I rely on the fact that vi and vim do not > break hard links. > > there was a discussion on this topic quite recently in the vimdev mailing list http://groups.yahoo.com/group/vimdev/message/35276?threaded=1

April 1, 2004