DDraw issues, etc.
Hi all, I've implemented SetClipList and GetClipList in the DirectDraw Clipper, and I'm wondering how I should go about implementing clipping in DirectDraw's Blt() (if it isn't already done somewhere). M$'s documentation isn't too great, so I figured I should ask around. There's a game one of my relatives wants to run under Linux (it's a children's program), and the major problem is that it dosen't seem to handle clipping properly when blitting. (e.g. every time you move the mouse, it calls SetClipList). FYI, the binkw32.dll that came with the program was originally causing it to hang, but I patched the DLL and it works fine. If anyone else has had such problems, I could provide a patch. Also, I'm going to take a look at some of the DirectSound stuff too. The sound isn't very good quality for some reason, but under the WineX 3.3 CVS, sound works perfectly. Tim
Re: Should winemaker be able to handle this
On April 2, 2004 4:01 pm, Francois Gouget wrote: > These options are global, i.e. they are supposed to be effective in > every makefile makefile generated by winemaker. For this reason they > used to go in the Make.rules.in file. That way one could later modify > them in one place instead of having to manually edit tens or hundreds of > makefiles. OK, so let's look at the problem. We have basically two distinct use cases here: A. We have a .dsp that we can convert to a Makefile B. We don't have a .dsp, so we autoguess a Makefile For (A) to work, we need to integrate the dsp2make, this is in the works (or at least we plan on doing :)). For this case, we don't need those options, but rather we need a _reliable_ conversion from .dsp -> Makefile. By reliable I mean that the result need not be handedited, so that on updates to the .dsp we can regenerate the Makefile. Moreover, we can not assume this to be the real project Makefile, we should generate it in such a way that another GNU Makefile can include it (using the include GNU extension; other makefile systems support this extension BTW in some form on another). For (B), the generation of the Makefile is a one time thing. After first generation, it should be properly maintained manually. We can not pretend to autoguess any Makefile right, but the trivial ones, and encouraging regeneration like this is just dangerous. So for this case we don't need those options either, the user can simply edit the resulting Makefile and add them in there just as easily. In other words, I think we should get rid of those options altogether, and focus on supporting the .dsp2make stuff, this is where the money is. -- Dimi.
Re: Should winemaker be able to handle this
On Fri, 2 Apr 2004, Bill Medland wrote: [...] > What I used toi have was: > #! /bin/bash > # Run this script in order to pass the correct arguments to winemaker so that > # it can set up the build environment > winemaker --nosource-fix --nogenerated-specs --dll --single-target mytarget > --nomfc -DMY_SETTING -I$MY_INC_DIR -L$MY_LIB_DIR -lmylinuxso . > > I see that we don't bother with generating spec files any longer. However I > see that the -D, -I, -L and -l options don't find their way into the Makefile > these days. Is that by design or a bug? (i.e. do I have to fix winemaker or > do I need to look at a different way of doing it) These options are global, i.e. they are supposed to be effective in every makefile makefile generated by winemaker. For this reason they used to go in the Make.rules.in file. That way one could later modify them in one place instead of having to manually edit tens or hundreds of makefiles. But ever since Dimitrie removed autoconf support we don't have a Make.rules.in file anymore and thus are completely ignored. Maybe we should re-add support for autoconf. Or maybe we should duplicate these settings in every makefile that we generate. -- Francois Gouget [EMAIL PROTECTED]http://fgouget.free.fr/ f u kn rd ts, ur wy 2 gky 4 ur wn gd.
Re: When saving a file with staroffice it is not saving with extension.
On Fri, 2 Apr 2004, Mike Hearn wrote: > Interesting bug report. Not sure what might cause that, but it does beg > the question - why aren't you using the native Linux version of StarOffice? First, I think it's a good test case for wine, so it's good that he does it. Second, in terms of practical application, it may make sense to use the Windows version of cross platform apps like Mozilla and StarOffice, as they may be better optimized, less bugs, etc. So no, I don't think this is an unreasonable thing to do. -- Dimi. P.S. I always wanted to see how the Linux Mozilla compares to the Win32 Mozilla under Wine...
Should winemaker be able to handle this
I haven't been following the winemaker stuff so I don't know whether it is supposed to be able to handle this (and is broken) or not. I am having to play with the "build a builtin dll to wrap a linux so" concept again after a year or so since the last time, as discussed in the Winlib manual, chapter 5. I see that winemaker has changed since then. In particular the bit that is not working for my case is the -D, -I, -L and -l options. What I want is to run winemaker to generate the build environment and then do the build. What I used toi have was: #! /bin/bash # Run this script in order to pass the correct arguments to winemaker so that # it can set up the build environment winemaker --nosource-fix --nogenerated-specs --dll --single-target mytarget --nomfc -DMY_SETTING -I$MY_INC_DIR -L$MY_LIB_DIR -lmylinuxso . I see that we don't bother with generating spec files any longer. However I see that the -D, -I, -L and -l options don't find their way into the Makefile these days. Is that by design or a bug? (i.e. do I have to fix winemaker or do I need to look at a different way of doing it) -- Bill Medland mailto:[EMAIL PROTECTED] http://webhome.idirect.com/~kbmed
Re: winapi_stats
> 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.
Development CDs for Windows
I have a large amount of Windows Development CDsi am wondering if these would be of any interest to the Development team of Wine I think that these would become very usefull at developing for Wine as well as alot of what Windows does is still most of the same. They are Windows NT 4 development kits and much much more. We where going to chuck them at my school...but salaviged them Please let me know Thanks -- Steven Pignataro A+ Partner/ CSO Computer Vision Networks, Inc. Toll Free: 866-897-8896 Phone: 269-979-5582 Fax: 269-288-0418 http://www.computervisions.net/ (c)2002-2004 --
Re: When saving a file with staroffice it is not saving with extension.
On Fri, 02 Apr 2004 18:03:05 +0800, Ravi Kumar wrote: > 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. Interesting bug report. Not sure what might cause that, but it does beg the question - why aren't you using the native Linux version of StarOffice? thanks -mike
Re: Developer's path to Windows/*NIX multi-platform?
On Fri, 02 Apr 2004 14:54:30 +, [EMAIL PROTECTED] wrote: > Well not to start a KDE vs Gnome debate, but Gnome is way behind KDE > development... hehe, hint, that's not a good way to "not start a KDE vs GNOME debate" > it doesn't even support Superkaramba (last I checked). SuperKaramba is KDE specific by the way it's coded. There is an equivalent in the form of GDesklets, and works much the same way. > You only pay licensing if your Qt app is commercial. ... or runs on Windows ... > The free version is perfect for opensource (ie GPL software) hence ... unless you want a non-X11 port ... > It requires too many code changes (at least in Python) for easy > cross-compiling. In Qt you simply generate a .pro file for the platform. Since when does Python require cross compiling? I think I was just trolled
Personal tree with interesting patches
Hi, As I'm pretty busy right now and won't have time to work on the various misc projects I've been working on up until recently for the foreseeable future, I'm checking them into my personal arch archive for people to play with and maybe work on themselves. My archive co-ordinates: http://navi.cx/~mike/archive/2004 [EMAIL PROTECTED] so, you'd use: $ tla register-archive http://navi.cx/~mike/archive/2004 There are currently only two interesting branches: wine--mainline--0.9: misc patches that were never applied for whatever reason, debug delay, lockwindowupdate (disabled), that sort of thing as i find more patches around my system i'll check them in for safekeeping wine--loadarea-reserve--0.9 execshield/prelink work, see the log message in patch-1 for details on what remains to be done Have fun! thanks -mike
Re: GDI: Merge the enhmfdrv into one .c file.
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 1 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
When saving a file with staroffice it is not saving with extension.
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.
Re: Developer's path to Windows/*NIX multi-platform?
Mike Hearn wrote: On Thu, 01 Apr 2004 17:39:14 -0500, Dimitrie O. Paun wrote: Do you think Wine is the way to go for me, or am I better off writing individual versions and keeping the Windows software native and then producing QT or GTK versions for *NIX? I'm at a cross-roads here, since I'll be dedicating years of work in whatever direction I take. What is native? I'd say a native app is one that feels like it was written for the platform. That normally means, native UI, good desktop integration, that sort of thing (in a desktop app). WineLib is a great way to do this. Pure WineLib apps will not feel native, because you're using a clone of the win32 widget set - suck it up ;) However, WineLib lets you use a native toolkit like GTK+ *and* keep using Or better yet, lets you use a "native" toolkit like wxWindows. Think about it! regards, Jakob
Re: GDI: Merge the enhmfdrv into one .c file.
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.
Re: Developer's path to Windows/*NIX multi-platform?
> integration. Ideally, we will have a GTK theme and a QT theme > that just calls the respective toolkit's theming code, so a > Wine app will look native both in GNOME and in KDE. I 100% agree > that native integration is paramount, and this is why we will > have it. This sounds very good. Maybe someday. > Since you've mentioned the toolkits, a small comment on that. > Of the two only QT is a serious option for cross-platform development. > It's a good option, but it's not perfect because your application > will not be native in GNOME, Well not to start a KDE vs Gnome debate, but Gnome is way behind KDE development... it doesn't even support Superkaramba (last I checked). Gnome users typically do not prefer KDE or Qt, and part of that stems from that KDE was developed using Qt and it's integration is woven throughout. > you will not be using the native toolkits > in Windows, you have to pay a lot of licensing fees, etc. You only pay licensing if your Qt app is commercial. The free version is perfect for opensource (ie GPL software) hence why it's included in almost all linux distros and you can D/L the same version for winders. Maybe > wxWindows is a better option... It requires too many code changes (at least in Python) for easy cross-compiling. In Qt you simply generate a .pro file for the platform. Shaun > > -- > Dimi. > > > > >
Re: Developer's path to Windows/*NIX multi-platform?
On Fri, 02 Apr 2004 08:31:38 -0500, Dimitrie O. Paun wrote: > Since you've mentioned the toolkits, a small comment on that. > Of the two only QT is a serious option for cross-platform development. > It's a good option, but it's not perfect because your application > will not be native in GNOME, you will not be using the native toolkits > in Windows, you have to pay a lot of licensing fees, etc. Maybe > wxWindows is a better option... What's wrong with GTK+/Win32? Last time I checked it used the native XP theming engine and looked right in Win2K/98 as well. There are a lot of open source apps with thriving win32 ports using it, and it's been integrated with the main tree.
Re: winapi_stats
On Sat, 3 Apr 2004, hatky wrote: > 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... Yes but it would still be interesting to know why the statistics where wrong rather than just sweep the problem under the rug. In your latest patch you filter out more dlls but you also duplicate some entries like 'winenas.drv'. Maybe the dlls were already correctly filtered out and the only problem was that the page I looked at was way out of date... -- Francois Gouget [EMAIL PROTECTED]http://fgouget.free.fr/ "Lotto: A tax on people who are bad at math." -- unknown "Windows: Microsoft's tax on computer illiterates." -- WE7U
Re: Developer's path to Windows/*NIX multi-platform?
On April 2, 2004 5:03 am, Robert van Herk wrote: > For me, as a user, I am > always aware of the fact that it is running on a compatibily layer. > > If you want something that really looks Linux-like, I'd go with QT > and/or GTK. Indeed, currently Wine makes it painfully clear that it's not native. Unfortunately for Linux (and fortunately for my point), the stupid Qt/GTK problem means that whatever you choose, it will not feel native. But look at the big picture: we are actively working on uxtheme, and it's a matter of time before we will have _very_ good L&F integration. Ideally, we will have a GTK theme and a QT theme that just calls the respective toolkit's theming code, so a Wine app will look native both in GNOME and in KDE. I 100% agree that native integration is paramount, and this is why we will have it. Since you've mentioned the toolkits, a small comment on that. Of the two only QT is a serious option for cross-platform development. It's a good option, but it's not perfect because your application will not be native in GNOME, you will not be using the native toolkits in Windows, you have to pay a lot of licensing fees, etc. Maybe wxWindows is a better option... -- Dimi.
Re: Developer's path to Windows/*NIX multi-platform?
On Fri, 2004-04-02 at 13:14, Jakob Eriksson wrote: > Or better yet, lets you use a "native" toolkit like wxWindows. Think > about it! Yeah, I'm not a big fan of toolkit abstractions. Stuff like wxWindows tends not to work well for the same reasons that implementing comctl32 on top of GTK would not work well - widget toolkits vary too much to be easily abstracted.
Re: Developer's path to Windows/*NIX multi-platform?
On Fri, 2 Apr 2004, Uwe Bonnes wrote: [...] > Mike> WineLib is a great way to do this. Pure WineLib apps will not feel > Mike> native, because you're using a clone of the win32 widget set - > > Is Motif Look and Feel "native", is XAW "native"? > Winelib is a Library like any other, also with some strange concepts... Is 'C:\My Documents' native? No. Wine/WineLib is more than just a GUI toolkit. Sure with WineLib you might be able to hide the Windows drive letters but we don't have that kind of code yet. And yes, a Gnome/KDE user may not consider Motif, Xaw and especially Athena applications to be native because they don't look like the others. The same would be true of a Wine application... at least until uxtheme is more advanced (uxtheme has the potential to make pretty nice eye candy, btw). -- Francois Gouget [EMAIL PROTECTED]http://fgouget.free.fr/ Demander si un ordinateur peut penser revient \xE0 demander si un sous-marin peut nager.
Re: Developer's path to Windows/*NIX multi-platform?
> "Mike" == Mike Hearn <[EMAIL PROTECTED]> writes: Mike> On Thu, 01 Apr 2004 17:39:14 -0500, Dimitrie O. Paun wrote: >>> Do you think Wine is the way to go for me, or am I better off >>> writing individual versions and keeping the Windows software native >>> and then producing QT or GTK versions for *NIX? I'm at a cross-roads >>> here, since I'll be dedicating years of work in whatever direction I >>> take. Mike> What is native? Mike> I'd say a native app is one that feels like it was written for the Mike> platform. That normally means, native UI, good desktop Mike> integration, that sort of thing (in a desktop app). Mike> WineLib is a great way to do this. Pure WineLib apps will not feel Mike> native, because you're using a clone of the win32 widget set - Is Motif Look and Feel "native", is XAW "native"? Winelib is a Library like any other, also with some strange concepts... Bye -- Uwe Bonnes[EMAIL PROTECTED] Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt - Tel. 06151 162516 Fax. 06151 164321 --
Re: winapi_stats
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.
Re: Developer's path to Windows/*NIX multi-platform?
On Thu, 01 Apr 2004 17:39:14 -0500, Dimitrie O. Paun wrote: >> Do you think Wine is the way to go for me, or am I >> better off writing individual versions and keeping the Windows software >> native and then producing QT or GTK versions for *NIX? I'm at a cross-roads >> here, since I'll be dedicating years of work in whatever direction I take. What is native? I'd say a native app is one that feels like it was written for the platform. That normally means, native UI, good desktop integration, that sort of thing (in a desktop app). WineLib is a great way to do this. Pure WineLib apps will not feel native, because you're using a clone of the win32 widget set - suck it up ;) However, WineLib lets you use a native toolkit like GTK+ *and* keep using the same code that you use elsewhere for doing the actual work of the app. For instance, you don't have to rewrite code to use malloc vs HeapAlloc - if you app uses COM you can still do that, if you use the win32 multimedia functions etc, you can keep that. This means you can produce a program that LOOKS and FEELS native in much less time than would otherwise be required (ie you don't need to rewrite all the code). It also lets you break it up into chunks and port one at a time - for teams without a lot of resources this is a valuable thing indeed. thanks -mike
Re: Developer's path to Windows/*NIX multi-platform?
I am willing to re-write my best Windows software from scratch, but I insist that the result is native or almost on Linux so there are not any weird GUI glitches. Do you think Wine is the way to go for me, or am I better off writing individual versions and keeping the Windows software native and then producing QT or GTK versions for *NIX? I'm at a cross-roads here, since I'll be dedicating years of work in whatever direction I take. I'm sorry, Dimitrie, but I'd say that if nativity of your solution is your primary goal, you shouldn't go with wine. IMHO, Wine is for when you want to have one application that works on both win32 and Linux. Still though, a application running in Wine will look like a _MS_Windows_ application running inside Linux. For me, as a user, I am always aware of the fact that it is running on a compatibily layer. If you want something that really looks Linux-like, I'd go with QT and/or GTK. However, you have to decide for yourself what you think is more important: the time that you will safe by going the Wine-way, or the Linux look&feel you will get by going the Linux way. Grtz, Robert
