wine users - Dec 2009 - Arguments for Wine on windows/incremental adoption

In short:

wine to be ported on windows, and programs to be allowed to compile partly on
native windows DLLs and partly on wine DLLs. In theory, this should permit much
faster market penetration.

More elaborate explanation:

Theres some megre effort for porting wine on windows, but this is mostly for
testing purposes. I'm proposing to port wine seriously on windows, and this
at the highest priority. In a way so that program developers can compile against
a fraction of wine DLLs, The proposal is inspired from evolution (biology),
teeth evolved incrementally from scales, so wine too should attempt a
incremental approach. Braking up development in tiny working increments its
extremely powerful strategy, this is how we got here.

advantages:

*it requires much less effort to try to port an application from 100% m$ to
99%m$ + 1% wine then to 100% wine. If program developers are particularly lazy,
they can simply test if there program works with some wine DLL with no further
fidling. Only future development will take in to account that DLLs were
replaced. This work would require much lower skills, then a full fledge port,
and even with out the source code, just take a random dude from the street, show
him how to relink a DLL, and simply test if the program performs. This could
even be partially automated.

*If Photoshop or skype, compiles even to just 1 wine DLL, it will make a lot of
publicity for wine. It seams to me that its acceptable to spend the resources
for just 1 wine DLL, instead of 100% .

*Potential to incrementally switch to 100% wine.

*Switching to even 1 wine DLL, means, that wine developers aren't alone
anymore running after bugs, the program developer will actively make sure its
product works with this particular DLL. Mechanically compatibility goes up, for
free.

*At the beginning companies may choose to do some DLLs for 1. symbolically, 2.
for marketing, 3. anti m$-resentment 4. beater negotiation position against m$
5. smoke m$ competition. I think its very reasonable to assume, google will do
this with all there software, so you'll need wine to run google earth on
windows for example. In every single sector where m$ tries to compete, there
competitors will be glad to rub there face in the dirt :) .

*Other open source projects should link by default to wine DLLs. For example, if
we arrange that firefox/Chrome links to wine DLLs, we get immediately 30% 
[Shocked]  of all PCs with wine on it. Programmers, can assume that wine exist
everywhere, like flash, and start writing code natively for wine. This would
mean, that they will be programs runing on wine, but not on windows, if this
happens with a huge thing like photoshop, its m$ that will change ITS code to
accommodate wine programs.

*If people have built in resentment against m$, they will have a chance to
proportionally vent it.

*Potential market becomes immediately 100% of PCs, not ~1%. More users, more
donations.

*Server software should lends its self more readily for this kind of
manipulation.

*Even if you think it bull shit, or if it doesn't work. It's so
"dominate the world" idea, that it should get spammed effortlessly in
the entire blogosphere.

*Benefits transferable to ALL other OSs under the sky.

*Enhanced security, because of fractionairy open source code.

*M$ just published windows 7, market penetration still very low. They are at a
vulnerable position now, it is possible that a lot of people will prefer switch
to wine platform, instead of windows 7. Wine will act as windows 7 bis. Also,
the EU is at there asses, other source for pressure and vulnerability. Yet an
other fine? Or impose something creative with wine for windows?

*Could help people switching to alternate OSs.

*Ultimate objective, is to completely remove m$ property from windows, 1 file at
a time, in such a way that all other developers and users can follow the shift.
Is this possible at the kernel level? React OS could be recruted here, again
similar benefits for that project too. A project could be started that
automatically rips out all the bling bling of m$ that was sucesfully migrated
to, and installs the alternatives.

*Wine developers should consider much more how the others will react to this
possibility, far more then its technical merits. It's a gamble that worth
taking, losses are low, and potential benefits very big.

please comment, even if its just to say that you agree. We have to do what to
propose this to wine developers? Can we do some sort of little petition among
users with this "feature" wish? Some one wants to make other
proposals/suggestions?

Most if not all of the Userspace dll's already can build for windows if
developers decide to use it.

Wined3d also works on windows.   This is supported development by visualization
software makers.

Sorry to say wine has a bug for bug policy and is not really a platform in it
own right.  Linking by default to wine dll's is not something that is
recommended.

Really we don't need to bother about wine dlls on windows platform.  Reactos
is a replacement NT core using wine dll's.   So far they are not including
16 bit support.  Important thing here why should wine run on windows so
providing windows with the same compatibility as wine + windows own?  Doing so
would undermine Reactos's efforts and any one else lining up to clone
windows.

Reactos are working on support for MS compilers and build envorment.   Wine only
worries itself about gcc.  So why duplicate effort with Reactos?

Wine better game compatibility in places brings users to Linux Solaris BSD and
Mac.   Why should we undermine this?

Next is doing what you describe would also undermine people from making cross
platform code.   So giving MS always the advantages.  One dll at a time so what
MS just releases more dlls more incompatibility you get no where.

Somehow you are making a major mistake here.   Wine is not about existing long
term.   Wine is about being a stop gap for applications you cannot get any other
way.

If every application that people wanted was released for Linux and other
platforms wine would cease to exist.  This is the preferred outcome for most
wine supporting people.

Really better support for items like QT and KDE inside wine is a far better way
forward.  Make it more profitable for developers to use cross platform toolkits
in the first place avoiding the complete windows problem.

2009/12/10 Deweirdifier <wineforum-user at winehq.org>:
> In short:
> wine to be ported on windows, and programs to be allowed to compile partly
on native windows DLLs and partly on wine DLLs. In theory, this should permit
much faster market penetration.
> More elaborate explanation:
> Theres some megre effort for porting wine on windows, but this is mostly
for testing purposes. I'm proposing to port wine seriously on windows, and
this at the highest priority. In a way so that program developers can compile
against a fraction of wine DLLs, The proposal is inspired from evolution
(biology), teeth evolved incrementally from scales, so wine too should attempt a
incremental approach. Braking up development in tiny working increments its
extremely powerful strategy, this is how we got here.

I doubt you'll get the current developers very interested in this -
those of us fiddling with Wine on Windows are doing so basically just
for fun (and people's simultaneous admiration and disgust), and even
then in a fairly desultory fashion. (I certainly am.)

However, if you produce better results, that'll definitely get attention.


- d.

> I'm proposing to port wine seriously on windows, and this at the
highest priority.
The highest priority at this point still should be to get Wine working properly
with more and more applications - in other words, "complete" the
Windows API.

DaVince wrote:
>
>
>> I'm proposing to port wine seriously on windows, and this at the
highest priority.
>
>The highest priority at this point still should be to get Wine working
properly with more and more applications - in other words,
>"complete" the Windows API.
>
+1.  The effort to run Wine with Windows DLLs should be HIGHLY discouraged,
mainly from a legal standpoint.  Read the EULA for Windows 7 and you will
understand that Microsoft understands the vulnerable place it is in and it
wishes to maintain its closed operating status excepting those who have signed
and comply with their NDA.  In other words, we cannot use Windows 7 dlls AT ALL.
All Microsoft has to do at this point is massively change the functionality of
the existing dlls and this project is dead.  So, we have to continue to enhance
the functionality of existing dlls and continue to test/probe the new dlls that
come out with Windows 7 within the 'black box/white box' that we have
been using.  Any other use of Windows 7 dlls is outside of the EULA that
accompanies it.  Windows versions prior to this version are not, according to
their EULAs, subject to this restriction AS LONG AS THEY ARE USED ON THE
LICENSED COMPUTER.  That means if I have Windows XP on the same system as I have
Ubuntu Linux, I am not violating the EULA (at least in the United Stated, EU
members may not be subject to this restriction.)  Thus, again, we have to
improve functionality of the API to the point where we do not need Microsoft
dlls.  Any other attempts may bring this project to a sudden end when Microsoft
decides (as it has in the past) that we are a pest and they need to leave us
behind (I was a member of WINOS/2 and saw what Microsoft can do up close and
very personal when it comes to modifying dlls and other code to make a project
worthless.)

Please do keep in mind that running Wine on Windows should be a good thing
because we are better at Windows98 emulation than Microsoft and there are
programs that need that version.

The legal opinions stated about the EULA are from reading the entire text of the
Windows 7 EULA and a legal opinion in the strict sense as to what Microsoft can
do if we decide to include the use of Windows 7 dll files into a public release.
Of course, these opinions are based on the enforciblility of this document in a
given legal jurisdiction.  The opinion is based upon case law in the United
States.  I am not nor do I attempt to portray myself as a lawyer or any other
legal person.  Your mileage may vary and the Microsoft EULA is worded and
enforced differently in the E.U. and other legal jurisdictions.  In other words,
you may be able to use Windows 7 dlls without legal reprecussions but in the
United States, Microsoft will take you go court if you use their dlls in other
than a test/experimentational role and even in that case, you can be sued or
ordered to 'cease and desist' if you violate the agreement, even if you
do not wish to take part in it.  Read the entire EULA of any Microsoft product
before proceeding to use it with Wine.
  
James McKenzie
>
>
>

oiaohm wrote:
>
>Most if not all of the Userspace dll's already can build for windows if
developers decide to use it.
>
Really?  Hmmm.  There is a lot of work left to fully support the Windows API. 
I've been working on a RichEdit function for over a year now to get it to
work like the WindowsXP version.  
>
>Wined3d also works on windows.   This is supported development by
visualization software makers.
>
>Sorry to say wine has a bug for bug policy and is not really a platform in
it own right.  Linking by default to wine dll's is not
>something that is recommended.
>
Correct.  Our 'bug for bug' policy is because some programs actually
DEPEND on undocumented functionality build into certain versions of Windows.  If
we 'fixed' these bugs, those programs would not function properly.  This
is because of poor coding practices actually encouraged by
Microsoft.
>
>Really we don't need to bother about wine dlls on windows platform.
>Reactos is a replacement NT core using wine dll's.
Since they do not fully follow a 'black box/white box' process, they may
find themselves in legal hot water.  The Wine project cannot use any of the
contributed code from this project because of their failure to do this.
As an example, Heath decided to create an IBM clone.  They dug through the BIOS
code.  Their clone was pulled from the marketplace at the insistance of the U.S.
Court system.  Tandy decided to watch what the BIOS was doing and found that the
system had to have the letters IBM in a certain location.  Once this was
overcome, Tandy (now Phoenix) made a better BIOS with increased functions,
including the ability to 'shadow' in memory the entire contents of the
BIOS.  This made extended/expanded memory possible.  If Tandy had not done this
we just might have two choices for a high price very slow PC:  IBM and Apple. 
We want folks to have a choice in operating systems, Windows and UNIX (Linux is
basically another type of UNIX, Linus has stated this on many occasions.)
>So far they are not including 16 bit support.
NT in its first iterations did not either.  That was what Windows 3.1 and
Windows 3.11 (Networking) was for.  Most programs are now 32 bit, but there are
a few Windows 3.1/3.11 programs that companies still rely on that there are no
replacements for in the 32 bit world.  Also, NT was basically a server OS (I was
at one of the NT 3.5.1 beta sites and it ran dog slow on a 16MB system, which
was high end for 1994/1995.)
>Important thing here why should wine run on windows so providing windows
with the same compatibility as wine + windows own?  Doing
>so would undermine Reactos's efforts and any one else lining up to clone
windows.
And why should we care what Reactos is up to?  Our position is to provide the
Windows API on any UNIX type environment, not to provide a replacement for
Windows.  The latter may make everyone who works/worked on this project subject
to the Lion of Redmond.  United we stand, but individually, in court, we
don't stand a chance.  Because Microsoft has stated it will not support
Linux in any form, makes them have to provide case law that supports us.  The
SCO situation proves that they don't have all of the information they
need....And they are still going after RedHat and a few others (Novell signed an
agreement that keeps SuSe out of the legal fray, but SuSe is delibrately broken
so that OpenOffice.org will not or should not run on it.)
>
>Reactos are working on support for MS compilers and build envorment.   Wine
only worries itself about gcc.  So why duplicate effort
>with Reactos?   
>
See my long winded explanation above or maybe I can shorten it.  In the United
States, what ReactOS is doing is illegal.  Simple fact that this may be found by
the E.U. courts.  Attempting to duplicate the functionality of an object by
observing what it does to data is a long standing and legal method, breaking
apart code is not, except for testing and evaluation.  This is what security
folks do.  They look at code for possible problems and then advise companies on
how to fix it.  We use Coventry for this function and we have been somewhat
quick at fixing buffer overflows and other coding problems.  Wine is so good
that some known userspace virii will run on it and inflict damage as if we were
running Windows.  This has been cause for concern, but Linux tends to limit the
damage to the user's available work area.
>
>Wine better game compatibility in places brings users to Linux Solaris BSD
and Mac.   Why should we undermine this?
>
That is NOT what the Wine project is about.  We are not just aiming at the
gaming community.  We want Wine used in productin systems running business
software products.  A game may bring on a million users, but the ability to run
Office 2007 might bring on 100 Million.  Which would you want?  I'd go for
both, but if I can get the second set, that is much better.  The bottom line is
that we are out to duplicate the Windows API, bugs and all, for a specific
version of Windows.  Right now, that version appears to be Windows XP SP3, which
is the most popular and installed version of Windows.  Duplicating Windows code,
line for line, should not and is not the purpose of this project and may cause
legal issues.
>
>Next is doing what you describe would also undermine people from making
cross platform code.   So giving MS always the advantages.
>One dll at a time so what MS just releases more dlls more incompatibility
you get no where.
>
You just hit upon the subject of one of my previous messages.  Microsoft will
keep the dll functionality fluid enough so that they can break this project at
any time.  I will add this statement to give you some idea of what they
attempted to do in the mid-1980s:

"DOS is not done until Lotus will not run".  During that timeframe,
Microsoft and Lotus provided competing products.  The folks at Redmond have a
track record of causing breakages in code that have caused their competitors to
go to U.S. Federal Court and receive monies for Microsoft's apparent
anti-competitive tendencies.  What do you think they could do to a project like
Wine if they decided it was worth it?  Remember, Microsoft MUST maintain its
current status or face reprecussions from its stockholders.  This project has no
such requirement and we have very few stakeholders.  We do have a company that
provides commercial support and a lot of development effort, but not at the
level that Microsoft has.
>
>Somehow you are making a major mistake here.   Wine is not about existing
long term.   Wine is about being a stop gap for
>applications you cannot get any other way.
>
Really, you have proof of this?  I have proof of the exact opposite.  This
project is over ten years old, which is a long time in the computer world.  I
expect it to be around for a long time.  There will be Windows programs that
will NEVER, EVER be ported into MacOSX versions, let alone UNIX versions.  Sure
there are Java programs, but most of them are at the server level and programs
that the average user will never see.
>
>If every application that people wanted was released for Linux and other
platforms wine would cease to exist.  This is the
>preferred outcome for most wine supporting people.
>
Nice pipe-dream as well.  As I said, there will never be certain programs for
Linux.  That is a fact.  
>
>Really better support for items like QT and KDE inside wine is a far better
way forward.  Make it more profitable for developers to
>use cross platform toolkits in the first place avoiding the complete windows
problem.
>
And there are functions in .NET that QT and KDE will never have.  Think about
this:  90+ of all computers, world-wide run Windows, even Macs.  Less than 1%
run Linux and most of them are servers.  Which audience would YOU go for?  The
one that is going to make you lots of money or the one that isn't?  Not a
question for a Rocket Scientist here.  Now, add in Wine and a fully qualified
Windows API plus the ability to add .NET and you have a winner.  Again, there
are programs that are never going to be built for Linux.  Not now, not tomorrow,
NEVER.  And programmers familiar with .NET are not going to go out and learn QT,
TCL/TK or any other 'fancy' interface because of the low numbers in the
target audience.  Even Apple has problems with folks learning to use Aqua/Cocoa
and they have about an 8% world-wide usage audience.  They provide a toolkit to
map .NET code to Cocoa code for major program manufacturers, like Adobe and even
Microsoft.
>
Maybe what I should say here is that Linux is thought of as somewhat of a joke. 
However, I know differently.  Windows is a real pain to maintain and keep
secure.  That is why I use a Mac.  I've not used Windows as my major
operating system since 1992, when OS/2 2.0 was released.  Sadly, IBM threw in
the gauntlet in 2000.  That is when I switched to RedHat Linux.  Sadly, RedHat
went 'commercial' in 2003 and I switched to Fedora (big mistake there
folks, it is and remains a wide beta test for Red Hat).  I've used CentOS,
Ubuntu, Madrivia (aka Slackware/Debian), and Knoppix.  I then switched to
MacOSX.  It appears that Apple has polished Free/Open BSD with a really good,
user friendly front-end (something that Windows Vista and Windows 7 wants to be)
without the back-end problems that have plagued Windows since Windows 2.0 (yes,
folks I go that far back.)  I really wish that Linux would take off and that
programmers would see the benefits for programming to it as well as MacOSX. 
However, when you have to feed/house/clothe the family, you are going to go
where the money is.  That is Microsoft .NET programming.  So, Wine needs to keep
on going towards full Windows API functionality and NOT be a replacement for a
seriously broken 'operating system'.

Wine + UNIX is what we really need.

We need to replicate the entire Windows API, 16, 32 and 64 bitness.  Across all
hardware platforms, across many hardware configurations.  We need to be what
Windows should be.  Solid, robust and foolproof.  (I know that two of the three
are possible, the third will take some doing.)  We need to replicate all
userspace functions.  We DO NOT need to be ReactOS or the Unified Kernel.  They
are projects that are in legal hot water and may die the first time the folks
from Redmond pay them a visit (and believe me, that is one scary place to be.)

So, we need to be a better Windows than Windows, even running on Windows.  

Sorry for the long rant, but we've been here before.  Let's all work
towards full API functionality and leave the replacements to others.

James McKenzie

@James Mckenzie

Fair enough, proper legal advice is needed.

Can you give a link to the EULA about this point, or maybe vagelly when it says
that. A web link would be nice. I think you are oversteting it, It sounds realy
draconian, how do you distinguish between normal use of libraries, and this?

If its really allowable under XP and not under 7, then it gets interesting. XP
its still very whide spread, it could be tried with XP and earlier DLLs,
meaning, if you have a legal liscence you do what the fuck you whant with them.
It could be tried to make a hybrid wine/XP distribution, that is 100% compatible
with current programms, and is incrementally "upgraded", by gradually
removing m$ propety. The only chance here is that people start installing the
hybrid on top of XP. And there's a reasonable chance of this happening with
the help, of Mozilla, google and any company that has a grudge with m$. In
general people are resistant to change, so maybe people them selves will prefer
to hack there existing XP installation, in order to prolonge its life. This will
get more important when suport for XP expires. If this gets traction, say for at
least 20-30% of world users, software publishers, WILL follow suit. This should
buy enough time, to allow for the entirety of XP to be cloned, whille its in
normall use, not when its going to be deprecated.

If its true about windows 7, then Its now or never.

http://upload.wikimedia.org/wikipedia/commons/b/b5/Operating_system_usage_share.svg

Deweirdifier wrote
>
>If its true about windows 7, then Its now or never.
>
>http://upload.wikimedia.org/wikipedia/commons/b/b5/Operating_system_usage_share.svg
>
Yes, it is true.  There are several add-ons that also state they cannot be used
under virtualized operating systems as well.  This means that they actually
detect the existance of a VM and then will not install.  Several people have
mentioned that here in the forums.  I think this is draconian as well, and the
E.U. courts have ruled most, but not all, of the Microsoft EULA unenforcable. 
Unfortunately, the U.S. Federal court system has not found reason, yet, to do
the same.  Hopefully, our small numbers will keep us as experiementers and not
mainstream usage of their products.  Several times, Winetricks was broken
because files have moved or been made unavailable.

And it will be some time before XP's numbers become smaller.  The same is
happening with Leopard (MacOSX 10.5) because Apple decided to drop Power PC
processor support.  Not all Mac owners are ready or willing to switch to Intel
based platforms :)

As to the legal status of the EULA, I will get it and read through it again. 
There may be a 'loophole' where individual dll files maybe usable in a
virtual environment (of which Wine is a virtualized version of the Windows API
on top of UNIX) and thus can be used if you possess a license, other than the
MSDN version.

In any case, my statements on ReactOS do stand.  The producers have stated in
the past that they examined dll code while it was in operation to determine what
was being done.  Sadly, that is not completely legal according to 'black
box/white box' rules and could lead to legal problems in the future.

James McKenzie

James Mckenzie: 
> Really? Hmmm. There is a lot of work left to fully support the Windows API.
I've been working on a RichEdit function for over a year now to get it to
work like the WindowsXP version.

Did I say they worked right.  I said they could be built for windows not that
they work.  If developer wanted to use them for any reason they could now.  Even
that I suspect no sane developer would touch them.

> Really, you have proof of this? I have proof of the exact opposite. This
project is over ten years old, which is a long time in the computer world. I
expect it to be around for a long time. There will be Windows programs that will
NEVER, EVER be ported into MacOSX versions, let alone UNIX versions. Sure there
are Java programs, but most of them are at the server level and programs that
the average user will never see.

Yes lot of businesses I deal with.  Wine is nothing more than stop gap.  
Programs that don't exist on Linux when equal on Linux is found those become
supported and the long term windows applications dropped completely.

> And there are functions in .NET that QT and KDE will never have.

Please list.  Don't be ASP.NET its dead in the water against PHP.    I guess
you forget QT scripting.   Most people who say .net has functions .net does not
turn out not to do there home work on how far QT and KDE extends.

> Think about this: 90+ of all computers, world-wide run Windows, even Macs.
Less than 1% run Linux and most of them are servers. Which audience would YOU go
for?
 

Now if you numbers were truly the complete number it might be correct.

QT and KDE is not about the 1% Linux market.  Its about the 60+ percent phone
market + Mac + Windows + Linux.  QT is nokia the phone maker.  All the mobile
phones will support applications built in QT.  People like to forget that.

Sorry compared to the numbers of phones out there 90+ of desktop computers is
nothing.  Seriously nothing.  40 percent of the moblie phone market is more.

So far I have not seen a single .net program without a better native program.  I
class .net programs as Visual Basic programs they come and go.  Long term fade
out of existence due to run-time issues.

You are already seeing the fade out of .net in web applications.

There is no legal .net that is trust-able that works for Linux or Mac OS.  We
will find out in 3 years time if mono is just a legal trap.

Deweirdifier wrote:
>
>
>> People already end up with QT installed and are not aware. 
http://qt.nokia.com/qt-in-use/story/app/qt-in-use/target/desktop
>
>
>I don't think you get what i'm saying. All these applications that
you mention, have to come bundled with there QT libraries. I'm
>saying, you install the full thing, so actual programs get much smaller at
download. If you install 10 QT programs, you'll get the
>same stuff 10 over, each in the installation folder of the program. And most
probably, its not the exact same version number, one
>may be 4.3.1 other 4.2.2. I'm saying that all prorammers should have the
asurance, that they will find QT, vertion X, that will be
>upgraded only at date Y (Not when QT issues a new vertion), at standard
location Z. For now QT is not a platform, its just a
>toolkit for writing programs.
>
But for Mac folks, you WILL have to include QT as it is not a standard install
for that platform.  It may also not be so for other UNIXs.  This is something
you have to keep this in mind when dealing with "users".  Some will
install only those libraries needed to get up and running.  Otherwise, you make
an assumption and users get upset.
> If you are utorrent, size matters a lot, its 300KB, but if it had to comme
with the libs it uses, it would be several MBs.
And that is a problem, how?  I've downloaded programs that were several MBs
in size from the Torrent.  Yes, it took time, but then again, the good part is
that you can download and upload at the same time.  This unless you don't
want to participate.  However, that becomes YOUR
problem...
>
>
>> The most important thing here is we take a path that gives developers
advantages by making there life simpler as well.
>
>
>Look, people ARE using windows API, there are reasons for this. If the
problem is what i'm theorizing then we can fix it. I suspect
>that the problem is not technical per see, cool coding can't help that
is. A really whant to here your input on this, and don't
>start with rants and fanboy stuff, people ARE using mickeysoft API, why? How
to fix it?
Hmmm.  That sounds like a rant in itself.  I'm NOT here to fix the API, I am
here to IMPLEMENT it, warts and all.  I am NOT here to build what MS built.  If
I wanted that, I'd be at Best Buy getting a Dell Netbook with Windows 7.  I
want to be able to run those programs that use the API on my preferred platform
for programs that will NEVER exist for it.  This is the idea behind this
project.  See, folks believe that if they programmers build only Windows
versions of programs that Linux is somehow damaged.  Sorry, but that is NOT the
truth.  This was the concept behind Java, and we all know how far that has gone.
It would be dead if it were not for SUN.  We need to build and implement the
entire API for a specific, high use version of Windows.  Then programmers might
see the value of building for Linux and move on.  That is the best sales
technique I know of.  That is why there are several virualization programs for
the Mac (VM Fusion is just one of them.)

>
>
>> Of course the platform independant api solution has to be free of
future legal problems.  Ie .net does not fit.
>
>
>:) , i was thinking deployment of QT/GTK whatever, in the same maner as
.net. With a lot of marketing.
Nope.  You are barking up the wrong tree.  Again, we have to support the entire
API, including the .NET hooks.  Lots of marketing to whom?  Programmers?  They
don't have the time to service a small and shrinking market or to learn the
tricks of a new interface.  They will stick with the high use stuff.  I know of
several .NET programmers that are learning Android interface programming because
it is the up and coming new thing.  Ask them about QT/GTK and they
laugh....
>
>> Remember opengl that is already a universal solution performs very well
under wine due to pass throughs to native.  Compared to direct x that require
emulation.
>> 
>> For games a push to provide an opengl engine would be beneficial to
gamers using wine.
>
>
>Well, obviously, opengl is doing something wrong. I hear its hard to use for
games
>
It's been around for a long time and several games WERE written to use
OpenGL.  Just is, it is a moving target and the system does not fully support 3D
graphics capabilities.
>-------------------------------------------------------------------------------------------
>
>Candidates for mass deploiment: QT GTK Java Khronos Mono opengl SDL openal
>thats what? several 100s of MB combined?
>
Really.  QT/GTK and Java?  What do you plan on running this on?  Remember, folks
are buying USD 300 netbooks that can barely run Linux, let alone any high power
stuff.
>My proposal, you create a project, from wich you download a set of standard
libraries. The vertions must stay fixed for some time,
>with only security fixes, other wise bugs will rec havoc with compatibility.
A bit like a linux distribution, but more
>conservative, because a lot of software will be closed source. You create a
foundation thing, with various promises about
>timetables.
>
Then sell this to the Linux distributions.  Try to sell it to Apple.  Then sit
back and bask in your rejection letters.  YOU will have to sell this.  And your
marketing URL is disgusting.  That is from someone who has been here for a
while.

In the meantime, we will continue to work on Wine.  Have a nice life.

James McKenzie

Failure to understand QT.  You can build 300 kb and smaller applications using
QT with no lib dependance or runtime.   Compiler of course is important
something that can static link and link time optimize well reduces the problem.

QT is also can be a platform.  People fail to notice how the numbers work 4.3.1
4.2.2  Drop the last number 4.3.x all of them are compatible with each other.  
4.2.x all of them are compatible with each other.  Last number is bug fix of
something that does not match Qt documentation.    Gets even better.  4.2.x
applications work in 4.3.x  Incompatibles where new cannot run old only happens
when the first number change.  Ie 3.x.x to 4.x.x  That was a api change.   So
yes shared lib solution could be done.

This number layout is formal to QT design.  So only 2 installed versions of qt
are required on Linux platforms.  Ie latest QT4 and QT3.  QT2 and QT1
applications will work with QT3 with compatibility libs.   Due to the api
differences between QT4 and QT3 it was decided not to fix this.

The non standard part and size are a fools argument against QT.   300 net-book
has a bigger processor and ram than what you normally use QT Embedded on.

People use QT without even knowing it.  Due to the reason it can static link out
of existence.   At this stage there is no advantage on windows or mac for
developers to leave QT programs dynamic.

Android interface is java.   Its torture to get stuff done compared to QT. 
http://wiki.forum.nokia.com/index.php/Porting_Android_%28Java%29_applications_to_Qt_for_Symbian

Even .net is huge code to get basic stuff done.   Remember larger the code more
risk of human error and problems.

 
> This was the concept behind Java, and we all know how far that has gone
LOL Java is second to PHP in web development.   The GUI coding is Java has been
long and painful and ugly.   Nothing to do with the idea if api is crap it dies.
Android is another attempt at the Java idea.   Maybe they get the GUI right this
time.

Laughing at GTK I can understand its not designed to static link out of
existence so creating highly optimized code for platform.  .net has the same
problem.  Qt is far more a different fish.

> Lots of marketing to whom? Programmers? They don't have the time to
service a small and shrinking market or to learn the tricks of a new interface.

Exactly why there is currently research to use QT on android.   So Programmers
don't have to learn to code for different market segments.

> It's been around for a long time and several games WERE written to use
OpenGL. Just is, it is a moving target and the system does not fully support 3D
graphics capabilities.

Same with Direct X by the way.   Most new engines are duel Opengl and Direct X. 
New features between Direct X releases get exposed in opengl first.   At time of
a Direct X release some new features get exposed in Direct X first.  This is the
way it always has been.   Coding in either is style.

> Then sell this to the Linux distributions. Try to sell it to Apple. Then
sit back and bask in your rejection letters. YOU will have to sell this. And
your marketing URL is disgusting. That is from someone who has been here for a
while.

No need to sell it to Linux, Freebsd or Solarias Distributions.   Solution for
them is simple all third party developers get unite decide on a loader for libs
and say stuff distributions.   Remember the Linux kernel does not know how to
dynamic link.   Its a little static userspace program that does dynamic linking.

I don't think OS X can dynamic link in kernel either and think it will
support multiable loaders as well.   So you might not need to do a single deal
with any OS maker.  Instead force them to take what ever you give.

If you want a example of a program with sound and graphics basically saying
screw distributions.   http://www.alientrap.org/nexuiz/

There is more.  The idea that you have to build for distributions is mostly a
myth if transporting dependencies is not a issue.

oiaohm wrote:
> If you want a example of a program with sound and graphics basically saying
screw distributions.   http://www.alientrap.org/nexuiz/
>
> There is more.  The idea that you have to build for distributions is mostly
a myth if transporting dependencies is not a issue.
>
>   
This is a very old project and is well known.  Games can be built to run
on just about anything.  However, can you find a commercial production
program that does the same?  (StarOffice is one that I know of, but it
requires specific code and builds for the various platforms it runs on.) 

Until something like this is available for the office environment, we
still NEED and REQUIRE Wine.  When that day arrives, many IT folks will
celebrate.

James McKenzie