wine users - Jul 2010 - Make sure that Visual Studio works before 1.2 release

I was thinking that should be a good idea to make sure that at least Visual
Studio 2008 is properly working in wine, before 1.2 release.
In this way, we could test specific functions in wine, by creating simple test
applications to test if the system calls are working well.
I think that Visual Studio is a key application to test wine compatibility with
windows, and it is an application that can be easily and freely downloaded from
Microsoft's web site, by anyone.

> I was thinking that should be a good idea to make sure that at least Visual
Studio 2008 is properly working in wine, before 1.2 release.
> In this way, we could test specific functions in wine, by creating simple
test applications to test if the system calls are working well.
> I think that Visual Studio is a key application to test wine compatibility
with windows, and it is an application that can be easily and freely downloaded
from Microsoft's web site, by anyone.
>
I believe at this point they are doing regressions only.

John

fernandocarvalho wrote:
> I was thinking that should be a good idea to make sure that at least Visual
Studio 2008 is properly working in wine, before 1.2 release.
> In this way, we could test specific functions in wine, by creating simple
test applications to test if the system calls are working well.
> I think that Visual Studio is a key application to test wine compatibility
with windows, and it is an application that can be easily and freely downloaded
from Microsoft's web site, by anyone.
>
>   
Nice goal, but now is way too late. 

This will have to go onto the slate of items for Wine 1.4.

We are only working on regressions and minor, very minor, code changes.

James McKenzie

Then, for the next release of wine, we could make sure that every new wine
release, is capable of running Visual Studio.
So we can maintain a certain compliance with key features of windows.
If Visual Studio starts working in a good shape, we can be sure that many
applications will also work, because a great portion of them are build using
Visual Studio.

> Then, for the next release of wine, we could make sure that every new wine
release, is capable of running Visual Studio.
Visual Studio 2005 trial works mostly under current wine when
installed via winetricks.

John

fernandocarvalho <wineforum-user at winehq.org>
wrote:
>
>Then, for the next release of wine, we could make sure that every new wine
release, is
>capable of running Visual Studio.
Give us a real good compelling reason why this should be so.  We are busy enough
with trying to make 3,000 games and office applictions run (or more.)  There are
things in VS that will never work with Wine and that's just fine.  We are
trying to get MingWin to work and Cygwin to work as well.  This will allow for
building of Windows executibles from Linux/UNIX and to run them in Windows. 
That would be considered a massive step forward.
>So we can maintain a certain compliance with key features of windows.
That's why we concentrate on applications over a broad spectrum.
>If Visual Studio starts working in a good shape, we can be sure that many
applications
>will also work, because a great portion of them are build using Visual
Studio.
It won't and never will.  Applications use .NET and other 'features'
of Windows as well.  The goal should be:

1.  Get legacy applications to work in Wine as they do in Windows.
2.  Get current applications to work in Wine as they do in Windows.
3.  Get cygwin/mingwin to build Windows applications in UNIX/Linux.
4.  Get Visual Studio to work in Wine.  

The first is mainly done.  The second is where a lot of the messages in this
forum come from.  The third is a purely developer issue.  The fourth may or may
not happen as time goes along.  Remember, we are following the Microsoft path
and they have been known to throw a wrench into the works on a regular basis. 
And yes, I've been at this since the introduction of Windows95 to get Win32s
applications to run on OS/2 (Project Odinn...)

James McKenzie

My idea is to get some set of tests for the new system calls that are
implemented in wine.
For example, if some wine developer implement a DX10 function, then I 'm
going to implement an application to test if that function really works like in
windows.
If not, than we are able to tell which is the problem and help the developement.
But I think that the best way to do this is by using microsoft compiler, so we
can quickly, see if the applications will behave like in windows.

It is not that the point.
What I was thinking is in a way to better test Wine against Windows, from inside
Wine.
If Visual Studio, were really working, than we could make scripts, to execute
Wine tests, with Visual Studio tools.
This could help finding system calls that are not complying to Windows.
I don't need Visual Studio, because I don't waste my time developing for
windows.
My real go with wine is to help people get rid of Microsoft monopoly.

James - nearly all windows games are compiled by Visual C++ :-)

Anyway, the original poster should have a look at
http://wiki.winehq.org/UnitTestSuites
to see that we agree with him :-)
And he should focus on unmanaged C++ test apps for now.

DanKegel wrote:
> James - nearly all windows games are compiled by Visual C++ :-)
>
> Anyway, the original poster should have a look at
> http://wiki.winehq.org/UnitTestSuites
> to see that we agree with him :-)
> And he should focus on unmanaged C++ test apps for now.
>   
Thank you, Dan, for the URL. 

However, I work with two applications that may or may not be build with 
Visual Studio (they both use Visual Basic calls and one actually appears 
to be built on Windows98SE).

These are fine.  Getting VS???? to work with Wine is a great goal.  
Maybe we will pickup more applications along the way.

In the meantime, I have to get back to my test case that just blew up in 
my face (Job 3284 is a great example and UNICODE calls seem to not be 
working now.)

James McKenzie

Such appears perverted to me....why not use Eclipse and GCC. Those are not only
superior but also cross platform.

Creating nowadays apps with VS, means losing market share. Mac has a way to
large user base to ignore, like Win users do with Linux. Also Mac and Linux
compilations are nearly the same.

On Mon, Jul 12, 2010 at 08:23, ahso <wineforum-user at winehq.org>
wrote:
> Such appears perverted to me....why not use Eclipse and GCC. Those are not
only superior but also cross platform.
>
> Creating nowadays apps with VS, means losing market share. Mac has a way to
large user base to ignore, like Win users do with Linux. Also Mac and Linux
compilations are nearly the same.
>
The code have a much larger effect than the compiler... (If you write
ANSI C / C++ it should compile anywhere... Using platform specific
libraries breaks portability, the specific library is not relevant
(compiling a program relying on POSIX libraries under Windows is not
that much different than compiling something dependant on MFC on a
Unix))

Changing the behaviour of 3rd party developers is probably a lost cause....

(.NET code is actually about as portable as Java, except that
Microsoft only supplies an environment for Windows and developers
ignore it and use OS specific functionality (such as Windows-only
DLLs). Its quite possible for a pure .NET 2.0 application to run fine
on Windows (x86, x64 and IA-64), Windows CE (if kept within limits of
compact .NET framework) and Linux / Solaris / OS X using Mono)

Gert