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

Re: CoCreateInstance not working without TLS libraries

by Alexandre Julliard

Vijay Kiran Kamuju <infyquest(a)gmail.com> writes: > Can we change our linuxwrappers for a work-around? No, there's nothing we can do, it's due to the way glibc references pthread functions internally. It would have to be fixed in glibc, but that's unlikely to happen, especially since linuxthreads is (fortunately) being phased out. -- Alexandre Julliard julliard(a)winehq.org

Dec. 16, 2005

Re: CoCreateInstance not working without TLS libraries

by Vijay Kiran Kamuju

Can we change our linuxwrappers for a work-around? Thanks, Vijay On 12/16/05, Alexandre Julliard <julliard(a)winehq.org> wrote: > Cihan Altinay <cihan(a)uq.edu.au> writes: > > > Thanks for the info. I am running a Xen[1] system which currently has to > > emulate unsupported lib/tls library calls. And that makes the system very > > slow. Therefore, the Xen maintainers strictly recommend moving the /lib/tls > > folder out of the way. Everything seems to work fine except wine apps that > > use OLE. > > Do you think the dependency of wine on TLS will stay in future versions? > > Yes, it can't be fixed, our linuxthreads wrappers can't work in glibc > 2.3. They work fine with glibc 2.2 though. > > -- > Alexandre Julliard > julliard(a)winehq.org > > >

Dec. 16, 2005

Re: CoCreateInstance not working without TLS libraries

by Molle Bestefich

Alexandre Julliard wrote: > > Do you think the dependency of wine on TLS will stay in future versions? > > Yes, it can't be fixed, our linuxthreads wrappers can't work in glibc > 2.3. They work fine with glibc 2.2 though. TLS can work with Xen, but you have to patch glibc and use -mno-tls-direct-seg-refs. More info (well mostly just assembler code): http://wiki.xensource.com/xenwiki/XenSpecificGlibc

Dec. 16, 2005

Re: Create new mailing list wine-isv?

by Michael Jung

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. > 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 Bye, -- Michael Jung mjung(a)iss.tu-darmstadt.de

Dec. 16, 2005

Re: Create new mailing list wine-isv?

by Peter Beutner

Robert Shearman schrieb: > Peter Beutner wrote: > >> IMHO all this stuff goes a bit too much into the wrong direction. >> >> 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. > > > 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. > >> 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 > > 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. > >> 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. > >> Not that I generally disagree with what you wrote. Actually it's >> mostly totally fine.And it's definitly a good thing when vendors care >> about their product running with wine or companies migrating to linux >> trying to get their highly-specialized-app to work with wine. >> But imho it _shouldn't_ be the long term solution. > > > 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. > 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.

Dec. 16, 2005

Re: Wine IE6 and JVM

by Adrian Munteanu

Hi Thank you both for your reply. However the answer for both questions would be yes. I have installed J2SEE 5 from Sun for both, Windows and Linux. As far as I know both of them have JVM integrated. I've tried to install msjavx86.exe but keep telling that needs a previous version to be upgraded. My problem is that after successfully installing above mentioned the software is not integrated with IE. The problem seems to be registry related. I've checked on windows and the registry for IE seems to contain informations about JVM. However the registry used by Wine are not updated with these information, therefore the internet explorer doesn't have a checkbox for the JVM to be used. Am I on the wrong path here? Thanks and best regards Adrian Alexander N. Sørnes wrote: > Hi! > > Microsof'ts JVM is not bundled with Internet Explorer; in fact, it is > not shipped with newer versions of Windows either, because of an > antitrust settlement with Sun. Either download the Sun JVM, or search > for the Microsoft JVM in Google (it is not available from Microsoft). > > > Regards, > > Alexander N. Sørnes > > Adrian Munteanu skrev: > >> Hi guys, >> >> I am trying to use wine with IE 6. >> Most of the pages are displaying fine, however the problem is with >> pages requesting JVM running. >> So could you please help me find away, if available, to make IE use >> installed JVM? >> >> Thanks and best regards >> Adrian >> >> >> >> >> >

Dec. 16, 2005

Re: CoCreateInstance not working without TLS libraries

by Alexandre Julliard

Cihan Altinay <cihan(a)uq.edu.au> writes: > Thanks for the info. I am running a Xen[1] system which currently has to > emulate unsupported lib/tls library calls. And that makes the system very > slow. Therefore, the Xen maintainers strictly recommend moving the /lib/tls > folder out of the way. Everything seems to work fine except wine apps that > use OLE. > Do you think the dependency of wine on TLS will stay in future versions? Yes, it can't be fixed, our linuxthreads wrappers can't work in glibc 2.3. They work fine with glibc 2.2 though. -- Alexandre Julliard julliard(a)winehq.org

Dec. 16, 2005

New Wine ISV case study: Synapticad

by Dan Kegel

Thanks to Stefan Munz of ITOMIG, I now have a nice writeup by Dan Notestein about SynaptiCAD's success with Winelib; it's online at http://kegel.com/wine/isv/synapticad.html It was first written about a year ago, but languished in cyberspace. I think I've given it its first home on a web site, and updated it a bit after emailing with Mr. Notestein. - Dan -- Wine for Windows ISVs: http://kegel.com/wine/isv

Dec. 16, 2005

Re: Suggested changes to the menubuilder etc.

by Scott Ritchie

On Thu, 2005-12-15 at 09:36 -0800, Bill Medland wrote: > On December 15, 2005 01:00 am, Scott Ritchie wrote: > > On Wed, 2005-12-14 at 14:51 -0800, Bill Medland wrote: > > > I am intending doing some work and submitting some patches > > > to "improve" the integration with the operating system > > > desktop integration. Rather than waste time coding up my > > > ideas and having Alexandre reject them I thought I'd start > > > by specifying what I intend and awaiting a barrage of > > > complaints. So please do comment. > SNIP > > If you want prose, check out my (draft) spec for a super-cool > > integrated Wine in Ubuntu: > > > > https://wiki.ubuntu.com/BetterIntegratedWineSpec > > > > I would be forever grateful if you could help me get this > > working nice by doing what can be done upstream. > > > > As for where Wine needs to put .desktop files to put new > > entries in the applications menu, the standard place from what > > I hear is in ~/.local/share/applications. As for adding a new > > "Windows" program group, that has to be done somewhere else, > > but I believe that's out of the scope of Wine at the moment > > (ie: in another package). > > > > Thanks, > > Scott Ritchie > > Thanks for the comments, Scott. > > Regarding your spec: > > In Design/Nautilus and Gnome/Para 2: It is not clear which icon > you mean. Do you mean the icon that appears in Nautilus and > which the user double-clicks or otherwise "executes"? If so > then I disagree; that icon should be the executable's icon; the > package provider has gone to the trouble to produce an icon that > reflects the program and it should be used; at that level it > should not be relevant that it is running under Wine. If you > mean the "busy cursor" then maybe I agree, but what does it > achieve? Anyway, why should the Wine icon be used; does the > user really care how the program is being executed? > By this I meant the default executable icon in the nautilus explorer. An executable installed by a package wouldn't be launched in nautilus this way, nor would most Windows programs once installed (they would instead be launched in the applications menu). Thanks, Scott Ritchie

Dec. 16, 2005

Re: Create new mailing list wine-isv?

by Jeremy White

> Not that I mean to sound like a pessimist, but I'm really just calling > it as I see it. No offense to anyone intended. :) This, in a nutshell, is Wine's greatest challenge (stepping even outside ISV boundaries for a minute). I believe, either because I'm insane (the likely explanation), or because it's true, that Wine has progressed remarkably in the past 5 years, and can no longer be correctly dismissed as unstable or unusable. I think the shift from Alpha to Beta status was a more dramatic signal that anyone really realizes; I think it marks the point where Wine can reliably be used for a broad range of purposes. But, bluntly, we have to prove it. We have to start by continuing the drive to a solid 1.0; we have to continue helping a small number of ISVs really succeed. And then of course comes the fun part; we have to hold that line and not let any regressions in :-/. But I think we can do it; it's why I'm still here. Someday I hope to stop apologizing for Wine (and for Linux for that matter) and start bragging; and I don't think that day is too far ahead (it better not be, my wife is really getting mad at me :-/). Sorry, I'd type more, but these friendly men tell me they have a nice white jacket they want me to try on... Cheers, Jeremy

Dec. 16, 2005