December 2005 - Wine-Devel - list.winehq.org

Re: Create new mailing list wine-isv?

by Marcus Meissner

> The point is that it won't be integrated in neither kernel or glibc. At > least I can't imagine that this will happen. Why should anybody integrate > another binary loader/memory layout into the kernel/libc where there is > already a fully working one? > Just because some people don't want to spend time/money to port their code > to linux? > I don't think with an argument like that you get this stuff included > somewhere :/ > (not even mentioning the flaws in the "windows mechanism"). > > So no, I don't believe that the environment(e.g. kernel/libc) will be > adapting to wine in this aspect. > > Don't get me wrong I still think it is perfectly valid that wine is doing > that sort of hack to get existing windows applications working but you > really shouldn't advertise it as a solution to platform independence and > encourage developers to go this way. Wine is doing fine already in regards to randomization (or not), mostly thanks to wine-preloader. I see no need for action. Ciao, Marcus

Dec. 16, 2005

Re: Create new mailing list wine-isv?

by Dmitry Timoshkov

"Peter Beutner" <p.beutner(a)gmx.net> wrote: >> Why? Wine is effectively just a different toolkit, like QT or GTK >> (albeit much larger) that give applications a Windows, KDE and Gnome >> look respectively. Take Notepad for example - with some slight >> modifications you could even modify the File Open dialog to only show >> the Unix namespace. Is there any reason that this application can't be a >> fully fledged part of the desktop? > > Wine is _not_ just a different toolkit. Just look at all the "nasty" stuff wine has to do > to emulate the windows process environment. This is not exactly what I would prefer as an > ideal environment when I had to develop an application. Since Wine is not a trivial thing written in 3 lines of code and it has huge compatibility requirements it must to do all kinds of things to make you (a developer) not to do that kind of things in your own code. Think about that. Said that, nothing makes it a different from another toolkit, no matter what Wine haters think about it. >> Sure. While you're at it give them some docs about globalization >> practices and efficient CPU usage. These are all nice to have things, >> but you have to face it that if you're a developer at a software company >> with a deadline then these are the first things to be ignored. You also >> have to bear in mind that it is incredibly difficult to do platform >> idependent GUI programming, whilst still maintaining the Windows look. > Nobody said it's easy or that it will happen over night. But it can/should be the long > term goal. Besides gtk+/qt are imho quite mature to use as cross-plattform gui toolkits. I don't understand why you can't include Wine in that list. Is that an ignorance or a result of hate to all which goes from windows world? >> It is the cheapest way for companies and it gives good results for the >> users. What's wrong with that? > See above. Wine does a lot of "tricks" to emulate windows behaviour. And the more you use > some complex window api the more is the chance that wine just can't implement it the way > it works in windows but has to use all sorts of workarounds to get it to work under linux. Sounds like a popular Wine myth. Anyone who ever seen a working MS Office 97/2000/XP/2003 or any other not trivial application working under Wine wouldn't tell anything like that, especially if he is a knowledgeable developer and not another member ./ crowd. > Sure all that probably won't interest any manager in a company and probably won't stand > against the "money" argument. But as a developer I would always vote for doing a little > bit of extra thinking by going the platform independent way. > >> >> Wine is a very good way of testing the waters with a Linux market. If a >> significant part of the market share starts coming from Linux or other >> Unix operating systems then the company can start offering winelib >> extensions that integrate better with the environment in which they are >> running. > I doubt that this will happen. If the windows version works with wine the company will > more likely continue to work on that. See your money argument. Another myth about Wine. >> However, you have to face facts that Linux is a hostile environment for >> commercial companies - constantly changing APIs, lack of regression >> testing by distributions, lots of variations meaning lots of testing >> needed and different standards on different distributions. Wine is a >> layer on top of that, which provides a degree of stability. > As long as wine doesn't break. And we all have seen how easy wine gets messed up when > something in underlying linux software changes. May it be the kernel or X. > Besides wine doesn't do all the testing for you. You still need to do a lot of testing on > different configurations. Which is the case for every other toolkit, it's not Wine specific. -- Dmitry.

Dec. 16, 2005

Re: Create new mailing list wine-isv?

by Peter Beutner

Michael Jung schrieb: > On Friday 16 December 2005 12:54, Peter Beutner wrote: > >>Let's just look at the problem with the memory layout. Wine relies on the >>possibility to load certain codes at fixed addresses as this is how it >>works under windows. Linux choose exact the opposite direction, i.e. try to >>ensure that libraries are loaded at random places in the memory. This is >>not a missing feature it is a complete different design decision. And I >>seriously doubt that the kernel/or glibc guys will import the security flaw >>from windows to always load code at fixed positions. So wine will have to >>live forever with it's custom preloader hack to emulate the windows process >>environment. > > > Well, wine is loading code at fixed positions. So we are bypassing this > security mechanism, right? If I understand correctly, if the kernel/glibc > guys will "fix" this, Wine will have major problems. > > This means there are many people (all wine users) dependend on being able to > load stuff at fixed positions. Since we are doing it anyway, and if the PE > loader would be integrated with the standard ELF loader, the kernel could > make an exception for PE executables. That's what I mean about the > environment adapting to given usage scenarios like wine. If this is too much > of a security problem for a given system, one would'nt install wine anyway. The point is that it won't be integrated in neither kernel or glibc. At least I can't imagine that this will happen. Why should anybody integrate another binary loader/memory layout into the kernel/libc where there is already a fully working one? Just because some people don't want to spend time/money to port their code to linux? I don't think with an argument like that you get this stuff included somewhere :/ (not even mentioning the flaws in the "windows mechanism"). So no, I don't believe that the environment(e.g. kernel/libc) will be adapting to wine in this aspect. Don't get me wrong I still think it is perfectly valid that wine is doing that sort of hack to get existing windows applications working but you really shouldn't advertise it as a solution to platform independence and encourage developers to go this way.

Dec. 16, 2005

Re: Create new mailing list wine-isv?

by David Gümbel

On Freitag 16 Dezember 2005 10:49, Peter Beutner wrote: > Robert Shearman schrieb: > > Peter Beutner wrote: > >> Maybe it's just me but when reading all this I got the feeling that > >> writing windows applications(which work with wine) is just *the* way > >> to go. > > > > It is the cheapest way for companies and it gives good results for the > > users. What's wrong with that? > > See above. Wine does a lot of "tricks" to emulate windows behaviour. And > the more you use some complex window api the more is the chance that wine > just can't implement it the way it works in windows but has to use all > sorts of workarounds to get it to work under linux. Sure all that > probably won't interest any manager in a company and probably won't stand > against the "money" argument. But as a developer I would always vote for > doing a little bit of extra thinking by going the platform independent > way. That's perfectly valid from a technical point of view. However, I do think you're grossly overestimating both financial and HR capabilities of most ISVs on the market. Moreover, there's the risk factor: Why should an ISV start changing their code base to be more cross-platform while having a pretty high risk that in the forseeable future, revenue generated by this move might be very close or equal to zero? As a technician, I absolutely see your points and find most of them perfectly valid. As a businessman, however, I think Wine is in many cases a very attractive - and in some cases, the only viable - approach for cross-platform efforts an ISV might make in a short to mid-term timeframe. Which approach they take depends on many factors, but helping them in case they decided to go the Wine way is definetly good for both them and the Wine project. David

Dec. 16, 2005

Re: Create new mailing list wine-isv?

by Michael Jung

On Friday 16 December 2005 12:54, Peter Beutner wrote: > Let's just look at the problem with the memory layout. Wine relies on the > possibility to load certain codes at fixed addresses as this is how it > works under windows. Linux choose exact the opposite direction, i.e. try to > ensure that libraries are loaded at random places in the memory. This is > not a missing feature it is a complete different design decision. And I > seriously doubt that the kernel/or glibc guys will import the security flaw > from windows to always load code at fixed positions. So wine will have to > live forever with it's custom preloader hack to emulate the windows process > environment. Well, wine is loading code at fixed positions. So we are bypassing this security mechanism, right? If I understand correctly, if the kernel/glibc guys will "fix" this, Wine will have major problems. This means there are many people (all wine users) dependend on being able to load stuff at fixed positions. Since we are doing it anyway, and if the PE loader would be integrated with the standard ELF loader, the kernel could make an exception for PE executables. That's what I mean about the environment adapting to given usage scenarios like wine. If this is too much of a security problem for a given system, one would'nt install wine anyway. > But this only applies to wine, not to software companies trying to make > money with their work? Is it too much to expect that enthusiasm from them? > Or how should I interpret this? All I meant to say is that Wine is great and very successfull at working against the odds. Bye, -- Michael Jung mjung(a)iss.tu-darmstadt.de

Dec. 16, 2005

Re: Create new mailing list wine-isv?

by Markus G�mmel

Hi, > I'll vote against a wine-isv list. History has shown we're not > responsible enough to have many mailing lists. Sure, if it takes > off.. great. But more than likely we'll be having a discussion on > wine-devel in 18 months about getting rid of the list because only a > handful of people are subscribed. In the mean time, the 3 or 4 people > who ask questions on wine-isv will get incomplete answers or referred > to wine-devel. Let's have the documentation refer the users to > wine-devel with questions. If things get off topic or wine-devel gets > overwhelmed, then make the list. That's also my experience. I would be the perfect man for such a new group, cause my partner and I are developing Windows applications (http://www.emtec.com) Seeing Wine some months ago fascinated me a lot, so since then I'm spending one or two hours a day trying to bring our applications to work under Wine, too... But it's clear that there are not enough ressources there to help ISVs like me out of some problems. Sometimes I have contact with one of the developers after submitting a bug, or writing something into the wine-devel list, but without doing a lot of clarification before (like looking into the Wine sources, close in the problem area, and asking really specific questions to the corresponding 5 or 10 lines of code in the Wine sources) nobody really have time to help. That's clear to me, cause the project is huge and the developing stuff is relatively small, so it is as it is. Only if the whole project would find it a main goal to support ISVs with there products, and some personal ressources are available, such a new list would be of any help. Don't understand me wrong, I'm a total Wine fan, but at the moment it looks to me that supportings ISVs which are more interested in their own product as on Wine is not realistic... Cheers Markus

Dec. 16, 2005

Re: Create new mailing list wine-isv?

by Peter Beutner

James Liggett schrieb: >>I really fear that this will end up with vendors loudly advertising linux support and >>proudly putting linux stickers on their products where everything you find inside are just >>the same windows .exe files and a readme stating that these will work fine with wine. >>Which at least is not what I would like to see. > > I agree. :) > >>The main thing the _developers_ should be pointed to(if they care about their product on >>other platforms then windows) are some decent docs about platform-independent programming :p > > Yes, they should. I think developers think about abstracting their > development around cross-platform toolkits like Gtk or QT But, then > again, far too many developers don't now, and probably won't ever. So > what then? So tell them about it ;) If the care a bit about other platforms they will at least think about it. And if they can't rewrite their existing software because it would be too much work or the product is no longer in development you could still point them to wine and try to work together to get it run on wine.But imho it should be in this order and not the other way around.

Dec. 16, 2005

Re: Create new mailing list wine-isv?

by Peter Beutner

Michael Jung schrieb: > On Friday 16 December 2005 10:49, Peter Beutner wrote: > >>Wine is _not_ just a different toolkit. Just look at all the "nasty" stuff >>wine has to do to emulate the windows process environment. > > > I guess in the long term a project like wine, if successfull, doesn't have to > live with the restrictions put up by the environment. If I understand > correctly, the reason we have to do this nasty stuff, is because the kernel > is missing functionality, which the NT kernel provides. Linus has stated that > he thinks the Wine project is pivotal for Linux success as a desktop > operation system. The kernel guys have been pretty cooperative before and I'm > sure if we tell them what we need, or even better help out implementing it, > Wine could be just another toolkit, perfectly well integrated _with_ the > Linux environment. Let's just look at the problem with the memory layout. Wine relies on the possibility to load certain codes at fixed addresses as this is how it works under windows. Linux choose exact the opposite direction, i.e. try to ensure that libraries are loaded at random places in the memory. This is not a missing feature it is a complete different design decision. And I seriously doubt that the kernel/or glibc guys will import the security flaw from windows to always load code at fixed positions. So wine will have to live forever with it's custom preloader hack to emulate the windows process environment. > > >>As long as wine doesn't break. And we all have seen how easy wine gets >>messed up when something in underlying linux software changes. May it be >>the kernel or X. > > "Success is measured by your ability to maintain enthusiasm between failures." > - Sir Winston Churchill But this only applies to wine, not to software companies trying to make money with their work? Is it too much to expect that enthusiasm from them? Or how should I interpret this? > > Bye,

Dec. 16, 2005

Re: msvcrt: Printf Integer Conversions

by Alexandre Julliard

Jesse Allen <the3dfxdude(a)gmail.com> writes: > Changes: > Add support for I64 integer sizes in printf. Handle I and I32 sizes > using libc's printf. The tests fail: printf.c:45: Test succeeded inside todo block: Problem with long long printf.c:46: Test succeeded inside todo block: return count wrong printf.c:51: Test failed: I0d failed printf.c:63: Test failed: I64D failed: %D printf.c:106: Test failed: #+25.22I64u conversion for -1 failed: got ' 0018446744073709551615', should be ' 18446744073709551615' -- obscure windows msvcrt bug? printf.c:114: Test failed: Problem with "ll" interpretation printf.c:115: Test failed: return count wrong printf.c:369: Test succeeded inside todo block: Problem with long long -- Alexandre Julliard julliard(a)winehq.org

Dec. 16, 2005

Re: DirectDraw over Direct3D

by Roderick Colenbrander

> > Second the required 3d functionality is VERY limited. Basicly the only > > thing the videocard needs support is texturing which all cards do. > > But that's obviously wrong - the video *driver* also needs to support it. > And the current 3D video driver situation in Linux is horrible. > Yeah linux drivers are crap for videocards from companies like S3/Via, XGI/Sis and also Intel. Most cards have some basic 3d driver support (the newer S3 ones not yet) but this basic support is enough. Texturing is something that is supported by all those basic drivers and cards. If your card can play Quake I it can also be used for the ddraw over direct3d renderer. A simple voodoo1 would even be fast enough (although this card can't do more than 16bit). The card also doesn't have to be fast. For instance your 2d game works at 800x600 and you use double buffering. You need to process half a million pixels for a single frame. That voodoo1 about which I talked already has a fillrate of 60MPixels so it can already do it fast enough. (one of the bottlenecks is the uploading of textures which happens through PCI / AGP / PCI-Express but this bottleneck appears for all drawing operations) Roderick -- Telefonieren Sie schon oder sparen Sie noch? NEU: GMX Phone_Flat http://www.gmx.net/de/go/telefonie

Dec. 16, 2005