Changes from VS 6 to VS NET 2003

#1 01-29-2005, 01:56

Can anyone please explain some of the changes from VS 6 to VS NET 2003 besides the GUI like Compiler specific things?

Also is there any commands to add or omit to make it compile most like VS 6 and less for .NET Standards. A lot of my code that worked before now no longer works with .NET 2003.

thanks

Hero · #2 01-29-2005, 03:30

I thinks the best answer is that there is nothing similar between these two versions!
Because in VS 2003 .NET,the VS is became behind an layer named .NET framework
and every program is written for this layer language(Don't look it the apperance
of language that compiled code in deferent.)
This is theoricaly for making VS 2003 .NET portable between deferent OSs.
VS 2003 .NET is compiling to MSIL(Microsoft Intermediate Language) but the earlier
versions will be compiled for system OS direcly(asmbelly language).
If somebody want to work with OS basic structures,Normaly should use VS 6 because
It is more powerfull than VS 2003 .NET for working with system.

sincerely yours

FEARHQ · #3 01-29-2005, 04:07

VS.NET can perfectly well produce native PE files just fine, thanks. Vc.NET has nothing to do with .NET

A difference I did notice is that you now must use the
#pragma comment(lib, "libname")
to include any library else linker will fail. That's probably what's messing you up

ArC · #4 01-29-2005, 19:10

Quote:

A difference I did notice is that you now must use the
#pragma comment(lib, "libname")
to include any library else linker will fail. That's probably what's messing you up

You can specify the libraries to use in the linker configuration tab. See the attachment.

And as FEARHQ already said, VC++ .NET can produce native win32 apps. Of course this depends on which components you install. If you only install Visual C# or Visual Basic .Net you can only produce .NET apps

In VS .NET they also updated MFC from 4.x to 7.x.. 7.x for instance supports HTML dialogs.

The debugger was improved. DLL debugging has become a bit easier.

Quote:

Also is there any commands to add or omit to make it compile most like VS 6 and less for .NET Standards. A lot of my code that worked before now no longer works with .NET 2003.

To make your code compatible at first you should look what problems the compiler/linker has (e.g. are there libraries/header files missing, does the compiler have problems with certain expressions, ....). Missing libraries/header files can possibly be fixed in short time. Same goes for certain errors during compilation. Anyways if you get errors like INTERNAL COMPILER ERROR or sth it can get a bit more complicated.

#5 01-29-2005, 20:25

Just chiming in to say Hero is indeed wrong. All versions of Visual C++, including 2002, 2003, and the upcoming 2005, can produce non-.Net pure native win32 code.

I don't understand where people get this idea stuck in their heads...

Hero · #6 01-29-2005, 20:51

Quote:

Just chiming in to say Hero is indeed wrong. All versions of Visual C++, including 2002, 2003, and the upcoming 2005, can produce non-.Net pure native win32 code.

Perhaps I make my idea unclear,I mean THAT every program that is written for .NET
is compeletly deferent from that we code in VS 6(It isn't .NET,isn't it?) because
that will compile to MSIL for framework and VS 6 is not in that way.
I know that we can make program for native win32 by VS 2003,but not in .NET
mode and we should use for example MFC.

sincerely yours

#7 01-30-2005, 00:31

Quote:

Originally Posted by ArC

You can specify the libraries to use in the linker configuration tab. See the attachment.

And as FEARHQ already said, VC++ .NET can produce native win32 apps. Of course this depends on which components you install. If you only install Visual C# or Visual Basic .Net you can only produce .NET apps

In VS .NET they also updated MFC from 4.x to 7.x.. 7.x for instance supports HTML dialogs.

The debugger was improved. DLL debugging has become a bit easier.

To make your code compatible at first you should look what problems the compiler/linker has (e.g. are there libraries/header files missing, does the compiler have problems with certain expressions, ....). Missing libraries/header files can possibly be fixed in short time. Same goes for certain errors during compilation. Anyways if you get errors like INTERNAL COMPILER ERROR or sth it can get a bit more complicated.

So do I just open up a project and set those settings and expect it to work. Is there any places where I have to say ... "no.. not .NET .... its Win32"?

Thanks. I'm accustomed to using VS 6 but I'm trying to get over to the .NET 2003 IDE.

#8 01-30-2005, 02:24

exactly don't know which are the advantages of using MSIL/.NET language ? since needs like 30 MB of libraries for .net framework crap ... program runs veryyyy slow and sure they takes more resources and ram...they believe in this way they will prevent cracker to reverse it??? 1 of the reasons.. what others they have?

microsoft should implement new programming method using MASM .... short exes, very fast and winall working...

My 1 Cent left ..

#9 01-30-2005, 03:57

@Crk:
Using the same reasoning, why Java, why C++, why C, why Macros in assembler, why not link the programs yourself, the linker adds 'bloat' too ?

I couldn't resists posting, but honestly you should really research before posting comments like that. You can do the hero programming on your own, but there are people who work in groups, on large scale projects, and need to deliver something that works and fast.

The fact that it runs inside an interpreter has more to do with having a framework that provides good memory management, built-in security, rapid development, portability than anti-reverse engineering. In fact, it has nothing to do with anti-reverse engineering since a lot of structures from the source code have to be left inside the .net code to run correctly.

#10 01-30-2005, 05:08

Quote:

Originally Posted by joejoejoe

Can anyone please explain some of the changes from VS 6 to VS NET 2003 besides the GUI like Compiler specific things?
...
A lot of my code that worked before now no longer works with .NET 2003.

I had no trouble converting VS6 projects/workspaces to VS.NET2003 solutions except for the C++ language compliance issues.
VC++6 has terrible language support, but VC++.NET2003 is the most standard compliant C++ compiler I know.
Some issues:
* for scope
Valid VS6 but invalid VS.NET2003:

Code:

for (int i = ...) {}
if (i == ... ) // supposed i is not declared before for

* template handling
it basically differs
* VS6 allows temporary objects to be passed by non-const reference:

Code:

class C { C(int); };
void f(C&);
f(5); // invalid call, but no error msg in VS6

Would you quote some error messages or some more details on what the exact problem is?

ArC · #11 01-30-2005, 17:12

Quote:

Originally Posted by joejoejoe

So do I just open up a project and set those settings and expect it to work. Is there any places where I have to say ... "no.. not .NET .... its Win32"?

If you convert a VC++ 6.0 project to VS .NET it is automatically configured to produce native Win32 apps.
If you create a completely new project you have to choose which type of project you want to create. If you decide to create a Visual C# project the output will be a .NET executable. A Visual C++ project will produce native Win32 apps whereas those projects can be configured to use the .NET framework, too. But even in that case it should still produce native apps.

Quote:

I had no trouble converting VS6 projects/workspaces to VS.NET2003 solutions except for the C++ language compliance issues.

Some time ago I compiled a project with VS .NET 2003 and I encountered an INTERNAL COMPILER ERROR. The same project compiles just fine with VC++ 6.0 + latest SP + Processor Pack.

#12 01-31-2005, 03:14

Using the same reasoning, why Java, why C++, why C, why Macros in assembler, why not link the programs yourself, the linker adds 'bloat' too ?

java is total difference than .net ... i know your point of view but also c++ and C is also totally difference,.. all of them run very stable and fast like old school ASM programing rulez... for example compile your Visual Basic 6 or C++ application like classic method.... now transform it to .NET ... don't tell me bull_shit it will be the same... and i know what i'm talking here.. i'm not kidding/playing kids games here. i'm not a programmer but i know what i wrote.
i respect your desicion and likes.. i know you like .NET but i made an opinion like anyone else .. for me .NET suc_ks ... you should respect my point of view as well.

#13 01-31-2005, 05:44

I'm not defending .NET against any other technology, I'm just stating that you have no idea what you are talking about. I'm not argueing on whether you can like the language or not; I'm pointing you the reasons for the existance of this language and why it is used.

You don't compare languages strictly by the size & speed of the the executables they produce. If that's how languages were determined as good ("assembly rulez") or bad ("30 mb crap of libraries"), we would all be programming in assembly, which clearly is not the case.

Who cares about C++ and VB... managed code is all about C#. You missed the point.

#14 01-31-2005, 17:04

Hello,

I agree with Arc, if you start a new project you'll see that only C++ has 5 subgroups (NET, MFC, Win32), so C++ will not force you to use .NET.

If you want to build Win32 apps but not using managed code, framework is not that good compared with the managed code.

Micro$soft is really pushing NET. Yesterday I installed Win2003 server and it comes with NET framework. But one thing is I do not understand why do they have two from designers in C++, one for managed code and one for unmanaged. They could come up with one designer. It seems that they won't more money from their customers.

Anyway, if you want to still producee Win32 app my advice to you is stick with the VS 6. VS.NET will not give you any real advantages when it comes to Win32 apps. VS.NET IDE is better, but VS 6.0 still rocks.

Regards,
asmith

#15 01-31-2005, 19:36

Quote:

Originally Posted by AgentSmith

VS.NET will not give you any real advantages when it comes to Win32 apps. VS.NET IDE is better, but VS 6.0 still rocks.

I would argue with this. The C++ language support is definitely a point it is worth changing for. I don't treat VS6 a C++ compiler, but for mainly C projects it is almost as good as VS.NET.