Haven't tested, but it should be. Since the betas for 2005 where not publicly available early enough it would not have been possible to compile 64bit targets. So I believe it should be able - haven't tested though, alone because I lack the 64bit supportRudi De Vos wrote:My reason for moving to 2005, was that i could use one project for
CE, 32 and 64 bit. Is this also possible with 2003 ?
What for the express version? Any other edition would do, don't you think so? I personally use Standard, but it doesn't matter if it was Professional or Enterprise.Rudi De Vos wrote:An other issue, is that MS seems to have removed the 2003 express version. Is the express 2003 still availble for download ?
I guess it does not run natively on 64bit. When talking about 64bit, are you considering Itanium or the AMD64-technology (which is partially used by new Intel processors as well)? The DDK compiler for Itanium is a native one.Rudi De Vos wrote:Does 2003 run on a 64bit cpu, i special got a 64bit PC to be able
to native debug 64 bit apps applications.
If use the same compiler as the DDK (2003) you only can crosscompiler 64bit apps.
That is what I wanted to do initially. Someone said we shouldn't keep things together, though. I agree that the different sources should be kept in different places and that the parts which get in touch be kept as minimal as possible, so we could easily upgrade to a newer RVNC codebase, or ZLIB library or other library.Rudi De Vos wrote:Can't we keep project files in subdirs.. i just downloaded zlib with
VC6.0 2003 and 2005 projects
Well, you are the only one then, who knowsRudi De Vos wrote:As i ported already commercial apps to 2005, any idea about the problems.
-unstable exe ?
But what for do you want to compile 64bit binaries? Only drivers have to be 64bit on 64bit OS. The rest could be 32bit, in fact.
Okay ... and yes, shared memory can be an issue indeed, but shouldn't be as long as the usermode part allocates it. Have you considered to use different versions of the structures from the driver? Only the driver is aware of the 64bit addresses.Rudi De Vos wrote:I needed to recomile winvnc to 64bit, the 32bit version kept crashing
with the 64bit driver. Just recompiled with changing option to 64bit
and everything worked (ok, 20 lines of code needed to bechanges for 64bit, but i all placed them correct between #ifdef #else #endif)
"Shared memory between 32 and 64 bit can be an issue"
An other point is, it sells better....people with x64 want there apps to be
x64. That what they told me in Germany...
Let's check out the compatibility issuesRudi De Vos wrote:I'm not going to use the express version, but the standard, as lic came with msdn. But not all people have a license or want to spend money
for it. As MS want to push 2005, they offer the express version free,
so including 2005 project files could have it's use.
Don't call it dead before it is buried ... it is quite a good architecture but not feasible for consumers.Rudi De Vos wrote:Itanium is dead, but more and more people are starting to use amd64 or em64t as they are not longer expensive.
Good choiceRudi De Vos wrote:As i needed to be able to run driver tests, the company i develop drivers for donated a 64bit PC. As i want to keep my old PC intact, the new will only serve for compiling and debugging. 32bit (via XP) and 64bit via (XP x64) double boot.
Perhaps true.Rudi De Vos wrote:As only the project files differ, 2003 or 2005 is not realy an issue.
For end user it would even better, as they can use both.
It's your attitude or view, that it is crap(ola). I don't think so. Starting with the .NET editions MS pushed towards ANSI compliance and the resulting binaries are still among the best optimized (besides Intel's and Watcom's compiler, the Watcom compiler being freely available as well) - leaving GCC far behind. If you like your consoe, go for your consolekillersquirrel wrote:I have not gotten ANYTHING to compile correctly with VS 2005. I have no idea why anybody would want any of this MS crapola.
The sources are open, it is a misconception that the compiler would have to be OS as well. I never understood this position and still don't.killersquirrel wrote:Shouldnt we be using DevC++ to compile things? I mean, as an open source advocate, wouldn't that be the best choice? Sorry for my programming ignorance.
Oliver wrote:It's your attitude or view, that it is crap(ola). I don't think so. Starting with the .NET editions MS pushed towards ANSI compliance and the resulting binaries are still among the best optimized (besides Intel's and Watcom's compiler, the Watcom compiler being freely available as well) - leaving GCC far behind. If you like your consoe, go for your consolekillersquirrel wrote:I have not gotten ANYTHING to compile correctly with VS 2005. I have no idea why anybody would want any of this MS crapola.
I've worked with DevC++ and see no advantage over using my favorite syntax highlighting editor (ConTEXT) with the respective hotkeys defined. You have no GUI development helpers, there's no help compiler (or editor), there is no extensive help on all aspects of programming. Might be a joy to use it with an online documentation on a broadband connection, but not at 56k in my home
/* OLD CODE FOR VC7- */
/* NEW CODE FOR VC8+ */
diff -dbr C:\workspace\C++\ultravnc\original/winvnc/winvnc/vncbuffer.cpp .\original/winvnc/winvnc/vncbuffer.cpp
< for (b = 0; b < nBytesPerPixel; b++)
> for (int b = 0; b < nBytesPerPixel; b++)
diff -dbr C:\workspace\C++\ultravnc\original/winvnc/winvnc/vsocket.cpp .\original/winvnc/winvnc/vsocket.cpp
< #include <iostream.h>
> #include <iostream>
Users browsing this forum: No registered users and 3 guests