|
Is it advisable to start coding the '.net' way or remain using
the Win32 api / mfc? Will .net objects replace win32 as the native api?
|
|
|
|
|
UGenn wrote:
Will .net objects replace win32 as the native api?
Eventually I think they will. Once the .net framework is standard with all copies of Windows, it makes sense for developers to use the higher level objects to write apps.
However I will be writing Win32/MFC/ATL apps for quiet a while. It all depends on what my customers want. I know MFC and Win32 very well, changing now would only slow down my development time and introduce new bugs into my systems.
I will change eventually but at the moment I've got too much invested in the existing technologies.
Michael 
|
|
|
|
|
IMO, it would be a huge mistake for someone wanting to be a professional programmer to pin their future on a technology like .net. Web "applications" and other kinds of form based programming are going to continue to evolve into ever simpler methodologies. At the same time, every school in the country is trying their best to produce new generations of "computer literate" kids, which means that ever larger percentages of them are going to have the basic skills needed to put together web pages and "form based" applications (ie. a dialog box populated with some data bound controls) with these ever more simplified technologies. Heck, most of my son's 13 year old friends can already build fairly sophisticated web pages. This trend is only going to continue. Soon, doing that kind of stuff is going to be considered a basic secretarial level skill set.
However, no language is ever going to refine away the complexity inherent in a large application. A programmer is going to need to bring extensive knowledgeability of some kind of C/C++ level skills to the table to get a big job done. C# might replace C++ in this role, but I very much doubt it. MFC may evolve away or be replaced by something else, but I think it is going to be around for a long while yet, because dispite all of its flaws, it remains the most practical method of cobbling a large scale application together quickly in a windows environment.
"There's a slew of slip 'twixt cup and lip"
|
|
|
|
|
you seem to have gone off a different tangent. the original pt is not about c++ but rather the relevance of the win32 api in the future.
|
|
|
|
|
Fair enough. I'll try again. I am saying that a basic knowledge of win32 (with C++ or not) will remain important for serious windows programmers. .net is only in its infancy and, if it is successful, will continue to evolve in the direction of making simple programming tasks more quick and efficient. Which is a good thing. But it will not change the fundamental nature of programming. You *will* continue to need a good understanding of what is going on at the lowest levels in order to successfully tackle large scale projects in the future just as you have done in the past. I am also saying that if you commit yourself to a .Net view of the world, than you are going to be forced to compete against an ever growing number of people who are going to possess an ever more significant portion of your skill set. I certainly feel as though that is Microsoft's goal with this technology. Therefore, my point is that .Net is important, but a win32 oriented skill set (or a basic knowledge of any lower level OS api) remains more than relevant, it is essential. If that is not true, then we are all in deep do-do.
"There's a slew of slip 'twixt cup and lip"
|
|
|
|
|
Can I use .NET platform on win98 and NT too?
Mazy
"So,so you think you can tell,
Heaven from Hell,
Blue skies from pain,...
How I wish,how I wish you were here."
Wish You Were Here-Pink Floyd-1975
|
|
|
|
|
Yep.
.NET is available for NT4, Win98, Win98SE, WinME, Win2K, WinXP Home, and WinXP Pro.
.NET development is available for Win2K and WinXP Pro, it might also be possible with NT4 but I'm not positive.
ASP.NET hosting can be done with Win2K and WinXP Pro.
James
Sonork ID: 100.11138 - Hasaki
"I left there in the morning
with their God tucked underneath my arm
their half-assed smiles and the book of rules.
So I asked this God a question
and by way of firm reply,
He said - I'm not the kind you have to wind up on Sundays."
"Wind Up" from Aqualung, Jethro Tull 1971
|
|
|
|
|
Let me make it clear for myself:
James T. Johnson wrote:
.NET is available for NT4, Win98, Win98SE, WinME, Win2K, WinXP Home, and WinXP Pro.
It means I can run my applications in those OS.
James T. Johnson wrote:
.NET development is available for Win2K and WinXP Pro, it might also be possible with NT4 but I'm not positive.
This means I can write for example C# or VB.NET codes only in those one.
James T. Johnson wrote:
ASP.NET hosting can be done with Win2K and WinXP Pro.
I know this one.;)
Mazy
"So,so you think you can tell,
Heaven from Hell,
Blue skies from pain,...
How I wish,how I wish you were here."
Wish You Were Here-Pink Floyd-1975
|
|
|
|
|
Correct
Sonork ID: 100.11138 - Hasaki
"I left there in the morning
with their God tucked underneath my arm
their half-assed smiles and the book of rules.
So I asked this God a question
and by way of firm reply,
He said - I'm not the kind you have to wind up on Sundays."
"Wind Up" from Aqualung, Jethro Tull 1971
|
|
|
|
|
Mazdak wrote:
James T. Johnson wrote:
.NET development is available for Win2K and WinXP Pro, it might also be possible with NT4 but I'm not positive.
This means I can write for example C# or VB.NET codes only in those one.
Yes and no.
technically... you can write C# and VB.net code on any system that has a comiler that can produce IL from C# or VB.net. if you go check out www.go-mono.com, you'll see that you can actually write C# code on linux, compile it there, and copy the dlls to windows and they'll work. ( not quite there yet, but that's the goal )
however... practically... you'd be best served with NT/2K/XP because that's the only platforms on which the Microsoft SDK and Visual Studio.net will install.
|
|
|
|
|
I have just started to get my feet wet with .NET (C#) and I just have one question so far...
Whose cruel joke was it to make the Left, Top, Right, and Bottom properties of the Rectangle Object READ-ONLY! 
Yes, I know the X, Y, Width, and Height are writable, but it doesn't do me much good when I am porting some of my C/C++ drawing code that doesn't think in those terms.
Now that I have that of my chest, I feel much better.
Thanks...
|
|
|
|
|
To make your transition easier could you just create your own rectangle class that falls back on the System.Drawing.Rectangle class when needed? 
If you got really enterprising you could write an implicit operator so it would cast to a S.D.R silently (for using in GDI+ for example).
James
Sonork ID: 100.11138 - Hasaki
"I left there in the morning
with their God tucked underneath my arm
their half-assed smiles and the book of rules.
So I asked this God a question
and by way of firm reply,
He said - I'm not the kind you have to wind up on Sundays."
"Wind Up" from Aqualung, Jethro Tull 1971
|
|
|
|
|
Good Idea and something I thought about myself.
Although, the code that I am working with at the moment does *allot* of small rectangle adjustments during the drawing and I am a bit worried about what the performance is going to look like under .NET.
I am currently starting to re-think things, and either I am going to change the drawing logic (I doubt) and/or, to fall back and to code up a rectangle variant that allows L,T,R,B adjustments and translate those into X,Y,W,H adjustments *auto-magically*.
Regards
|
|
|
|
|
I have a C++ method in a component that expects a pointer
to a long as one of its parameters (ie. String*, long*,
long, long). When I try to use this method from VB, the
compiler gives me error "BC30657 'method' has a return
type that is not supported or parameter types that are not
supported". I've narrowed it down to the second
parameter. VB has no problem with the other "longs". It
appears that the pointer to the long is the problem. If I
define it as an Int32*, VB is happy. I'd like to be able
to define it as long* so I don't have to re-write some of
the C++ code. Does anyone know what's happening here? Is
there a work around?
Thanks for any help...
|
|
|
|
|
i'm going to assume you mean vb.net
i'm no c++ guy or vb.net guy ( c# is my cup of tea ), but i'm thinking it is because c++'s "long" is not marshaling correctly over to the managed/clr world. what is a "long"? Int32? Int64?
Since it is a pointer to a long... maybe it should be specified as an IntPtr?
But really... if you are planning on making these things public in a managed environment, you should stick to using types which are CTS compliant... and I believe a pointer to a long... isn't
|
|
|
|
|
Andy:
Thanks for the reply. The problem, as I see it, is that .NET does not know how to resolve the "long*" parameter. It has no problem with the other native C++ types (ie. long, int, etc.). It appears to have problems with pointers to these types. I've verified this by looking at the assembly manifest. It shows pointer syntax for the "long*" parameter. For other parameters that are pointers to CTS types, it shows them as references. The work around appears to be that you can only use CTS types anywhere a pointer to a native C++ type is expected. I'm not sure if this a failing of VB.NET, or, .NET in general.
|
|
|
|
|
well...
I wouldn't call it a "failing" per se.
The CTS defines a LCD of Types that languages must support to be .net compliant. using public variables not CTS compliant WILL result in cross-language problems.
Would you call it a "failing" of C++ if it failed to automagically recognize some arbitrary datatype of some other language that targets the clr? I wouldn't. I'd tell the person using that data type in a public interface to wrap up his language's idiosyncracies in a CTS compliant interface.
The reason the clr isn't having a problem with the other non-pointer datatypes nor pointers to reference types, is because there are direct CTS equivalents. A pointer to a Value Type is implemented as a IntPtr, I believe. check out the docs on it here.
|
|
|
|
|
I've been given the task of coming up with a proposal for our .NET strategy. Does anyone know of a place where I can get detailed information comparing C# and VC++.NET, in particular we need to know which language we should default to so that we
a) keep up with the industry
b) get the results we need in the quickest possible time
Development is currently (in the main) in VC++6 with MFC, so VC++.NET seems like the obvious choice to me, but with all the talk of C# I'm really struggling to know which way to turn, any ideas folks? What would you default to and why? 
Dylan Kenneally
London,UK
|
|
|
|
|
Dylan,
I don't know offhand precisely where to look for such information. However, I'm pretty sure you'll find something in the online MSDN Library msdn.microsoft.com/library.
As to which language to choose, it depends on exactly what you intend to do with .Net. Will you be writing clean slate applications or wanting to leverage existing components?
The consensus seems to be that if you're writing brand new .Net apps., and your developers have a C++ background, then you should go for C#. The alternative is Managed C++ but this is really best-suited for wrapping legacy C++ or Com components for the .Net environment rather than new code.
Of course, it may be that you will be moving over to .Net gradually. In which case you may need to adopt a twin strategy - MC++ for leverage, C# for new stuff. But don't be fooled into thinking that because you are C++ developers therefore MC++ will get you results in the quickest time. C# was *designed* for .Net. MC++ has been *adapted* for .Net. You will find C# to be very elegant and easy to pick up. The biggest learning curve is the .Net framework itself rather than any particular language.
If your developers have a Visual Basic background then the jury is still out. VB .Net is sufficiently different from VB 6 that many VB programmers have gone for C#.
Kevin
|
|
|
|
|
Try these URLs
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/cscon/html/vclrfgettingstarted_pg.asp
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/vcmex/html/vcconfeaturesofmanagedextensionsforc.asp
Kevin
|
|
|
|
|
What advantages are there for using the .NET platform and C#? From what I understand it will not write code for Linux or MAC, C# exists only on Win2K,XP platforms, you can't even write for win98 either. C# uses mile long names with system.windows.form.something.add.more.names.please and a bases for creating file data structures in XML instead of binary code? Doesn't anyone beleive in making files compact anymore? I am trying to decide if I want to buy it or not. I have a lot of addins that I use for VC6, and I understand that they are not compatible with .NET are they? VC6 can write code which I can recompile on Linux, or MAC without a problem. Are they reasons that I am not aware of as to why I would want to switch over ot .NET, C#, and C++.NET?
Nothing is impossible, It's merely a question of figuring out HOW?
|
|
|
|
|
Aqiruse wrote:
From what I understand it will not write code for Linux or MAC
MS has provided the specification so that you can write applications for other operating systems. There are currently 3 projects to create a .NET for *nix, GnuNET (or maybe it was .Gnu?), Rotor, and Mono. I haven't heard of such a project for Mac but there will probably be one with in the next year.
Aqiruse wrote:
C# exists only on Win2K,XP platforms, you can't even write for win98 either.
Incorrect, C# is a part of the .NET platform; the .NET platform is available on NT4, Win2K, XP, Win98, Win98SE, and WinME. Win95 users are SOL.
Aqiruse wrote:
C# uses mile long names with system.windows.form.something.add.more.names.please
using System.Windows.Forms;<br />
.....<br />
TextBox b = new TextBox();
The using statement makes it so that you don't have to type the whole thing out. The reason for such long names is to be clear and to package it up nicely. Its no worse than some of the security API names in the Win32 API.
Aqiruse wrote:
bases for creating file data structures in XML instead of binary code
The whole point is to interact with other programs written in different languages running on different platforms on the other side of the world. XML is the means, if you don't like it you can serialize to binary form if you wish but you take yourself out of the XML WebServices market.
Aqiruse wrote:
Doesn't anyone beleive in making files compact anymore?
Its merely a tradeoff. Interact with a J2EE webservice with almost no code or create a wrapper to interact with it by hand so that you achieve the smallest filesize as possible.
Modems do a great job of compressing text (which XML is) so there isn't much of a reason not to use it.
Aqiruse wrote:
I have a lot of addins that I use for VC6, and I understand that they are not compatible with .NET are they?
Nope, I belive the DOM changed for VS.NET; but any macros you have should come over with only a few fixes.
Aqiruse wrote:
VC6 can write code which I can recompile on Linux, or MAC without a problem.
You must be writing console programs then, because VC doesn't create windows code that can be taken to other platforms, or you are using a third-party windowing library which is not that same as "VC6 can write code...".
Aqiruse wrote:
Are they reasons that I am not aware of as to why I would want to switch over ot .NET, C#, and C++.NET?
That depends on what kind of stuff you are writing. Since you are currently writing VC6 applications you should give Visual Studio.NET Pro a try; I believe MS offers a 120 day trial CD which would give you ample time to experiment a bit with C# and .NET. If you don't like it stick to VC6 or move to VC7 (which has better standards compliance).
James
Sonork ID: 100.11138 - Hasaki
"Smile your little smile, take some tea with me awhile.
And every day we'll turn another page.
Behind our glass we'll sit and look at our ever-open book,
One brown mouse sitting in a cage."
"One Brown Mouse" from Heavy Horses, Jethro Tull 1978
|
|
|
|
|
Thanks for taking the time to explain it to me. Some of the things I had heard, were incorrect then. In VC6 you can write multi-platform code for linux and MAC. You can get the MFC commercial libraies for Linux if you want to go the MFC way. Or there are about 15, (some free some not) platform libraries that work on Windows, MAC, and Linux (wxWindows and FLTK being free) enabling you to write code and then just recompile (From within Linux or MAC) for the other OS's. That allows you to code GUI applications from within your favorite OS, and have them run on other systems as well. I will take a look at the Trial then, and exam further if its something I want.
Nothing is impossible, It's merely a question of figuring out HOW?
|
|
|
|
|
Aqiruse wrote:
You can get the MFC commercial libraies for Linux if you want to go the MFC way.
Who makes those? I've seen something endorsed by Microsoft for Unix, but when I first looked at it they didn't support Linux.
James
Sonork ID: 100.11138 - Hasaki
"I left there in the morning
with their God tucked underneath my arm
their half-assed smiles and the book of rules.
So I asked this God a question
and by way of firm reply,
He said - I'm not the kind you have to wind up on Sundays."
"Wind Up" from Aqualung, Jethro Tull 1971
|
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
