As far as code compatibility, let's start with the fact that MinGW is
constantly behind the curve on the Windows API and always will be.
Yes, but it's quite easy to add missing libraries and headers, when
necessary.
Quite easy? No, far from it. Witness how long it has taken to resolve
the
One further note on this-- I have now successfully built and run the
64-bit version of vncviewer using MinGW64. The version of the compiler
I'm using is mingw-w64-1.0-bin_i686-mingw_20100405.zip, which I just
unzipped into c:\mingw. It seems that this version defines
CLSID_ActiveDesktop in its
On Mon, May 17, 2010 at 07:18:41PM +0200, Peter Åstrand wrote:
On Mon, 17 May 2010, DRC wrote:
Windows developers would still be able to edit and browse the source
with Visual Studio, even if they need to build with MinGW.
Per my previous message, there are a lot of additional components
On 5/18/10 5:35 AM, Adam Tkac wrote:
I just tested the MS Visual C++ Express 2010 and I have to agree with
you the code compatibility is a valid point. Visual C++ prints bunch
of stupid warnings, like hey, this function is not thread safe.
Seems that non-threaded Windows program is simply a
On Tue, May 18, 2010 at 1:12 PM, DRC d...@virtualgl.org wrote:
On 5/18/10 5:35 AM, Adam Tkac wrote:
I just tested the MS Visual C++ Express 2010 and I have to agree with
you the code compatibility is a valid point. Visual C++ prints bunch
of stupid warnings, like hey, this function is not
On Mon, 17 May 2010, Adam Tkac wrote:
As I wrote above I will test MS Visual Studio 2010 Express. If it will
work fine then I will update *dsp build scripts and I will start to
maintain them, it shouldn't be so hard. I agree with you that for
Windows only developers Visual Studio environment is
On Mon, May 17, 2010 at 04:52:09PM +0200, Peter Åstrand wrote:
On Mon, 17 May 2010, Adam Tkac wrote:
As I wrote above I will test MS Visual Studio 2010 Express. If it will
work fine then I will update *dsp build scripts and I will start to
maintain them, it shouldn't be so hard. I agree with
On 5/17/10 9:52 AM, Peter Åstrand wrote:
Wouldn't it make more sense to fix the problems with MinGW instead? If
the official downloads are bad, we can provide our own
MinGW-for-windows. Shouldn't be very difficult. Sounds more fruitful
than trying to maintain multiple build systems.
Windows
I personally find IDE's more of a struggle than command line tools.
Plus, switching to a new IDE would be a lot more trouble than simply
converting and fixing the existing DSP files. Additionally, we'd still
have to use Visual C as the underlying compiler. It's not that building
TigerVNC from
On 5/17/10 12:18 PM, Peter Åstrand wrote:
Per my previous message, there are a lot of additional components
required, not just MinGW. We'd have to distribute the necessary MSYS
components as well.
MSYS is a part of the MinGW project; not a big problem.
In total, this would amount to
10 matches
Mail list logo
