Fog Creek Software
Discussion Board




API vs .NET

I'm am currently learning C++, but the class I'm taking only deals with console applications. Eventually I'll need to learn about implementation of user interfaces. I went to msdn and starting looking at info about Win32 API (I was advised to steer clear of MFC), but there was so much information there, that I thought a book might help. A search at Amazon brought up tons of stuff but what stood out to me the most was the whole Win32 API vs .NET thing. I guess there is no longer a Win32 API, but .NET has taken it's place? There was a whole book dedicated to work-arounds for stuff that's missing from .NET that used to be in Win32 API.

Ack... I'm confused. There's simply too much info to try to wade through when you don't know what you're looking for! Can anyone give me a simple explanation of the two, and why/how they are different?

HeyCoolAid!
Wednesday, March 19, 2003

The Windows API are the "handles" that Windows provides which software applications can take hold of to manipulate the things Windows does (display, file system, network, printers, etc)

.Net is an application programming language that "hides" the API's from the application developer, doing the work for the developer. Since the API landscape is so vast, it has missed some spots. [grin]. However I've also found that because .Net has so radically changed the model for developers, often you can't find what's staring you in the face - looking for it in the same old place comes up empty, so "they must have left it out"

Finally, if you want to learn C++ development in Windows you want to look into Templates, ATL, and WTL. However doing so without the fundamentals you're being taught in CLI land may lead to injury. ;-)

Philo

Philo
Wednesday, March 19, 2003

But can API still be used... or do you have to use .NET?

HeyCoolAid!
Wednesday, March 19, 2003

You can definitely still use the win32 API.

If they ever disabled it, 95% percent of windows software would suddenly stop working.

Benji Smith
Wednesday, March 19, 2003

what do you want to do with the stuff you learn?

anon
Wednesday, March 19, 2003

What do I want to do? Well, I'm currently a multimedia programmer (Macromedia Director / Lingo) transitioning to C++. I have written quite an extensive user application in Lingo (by myself... took a long time). Future versions of the software, as well as other apps, will need more flexibility in development... hence a much lower level language. That's why I'm learning C++. Version 3.0 will be built by myself and a very experienced C++ programmer. I don't want to come into the deal with an empty tool box. The more things I know how to implement, the better. I would at least like to speak his same language and make myself understood when it comes time to design and build the system. User interface plays a very important part in the app(s) we're going to build.

HeyCoolAid!
Wednesday, March 19, 2003

Oh and...

>You can definitely still use the win32 API.

...but for how long? How soon will support for this end? Would I be better off going with .NET since I haven't learned and API stuff yet? Can I avoid going with .NET since I'm programming in Visual C++ .NET?

HeyCoolAid!
Wednesday, March 19, 2003

If Microsoft were to approach a completely managed operating system, no doubt they would layer Win32 on top of it for backward compatibility.

Win32 APIs will be supported for what is essentially the indefinite future.

Brad (dotnetguy.techieswithcats.com)
Wednesday, March 19, 2003

Isn't Windows NT already a managed operating system, in a way?

Frederik Slijkerman
Wednesday, March 19, 2003

Is OOP more then just some Fluffy GOOP?

While traditional VB is not considered real OOP language, it does offer class objects.  I am not convinced that lack of inheritance was a big deal for most applications that I have developed.

However, VB.net really will force all us VB developers to jump on the OOP bandwagon. Of course, this really is a requirement due much to the whole .NET framework class library. There is no doubt that this library is the key to the whole .net thing.

Without a OOP language, then one cannot really reap the benefits of that framework library. I suppose without inheritance it could be just a real nice starting library, and we could always have been forced to wrap these base library objects into our own objects. However, this would not bode well for future extensions, and not allow us to create our own objects for windows forms etc that properly inherent all the nice .net stuff to come.

Ok, so, now one has to jump on this OOP goop.

I actually think that the whole frame work thing and getting rid of having to use the *messy* win32 api is really a fabulous idea.

So, while one can still use the win32 api, I can’t really see why one would?

Does this make sense? Am I missing something big here?

Future OOP programmer
Albert D. Kallal
Edmonton, Alberta Canada
Kallal@msn.com

Albert D. Kallal
Wednesday, March 19, 2003

Attempting to learn to program in win32 initially is not fun.  In fact I would describe it as painful.  You are far better off learning something like .NET and then picking up peices of Win32 that you might need to improve your programs.

Knowing about win32 is still definately advantageous at present - although I'm guessing MS is going to try to move away from it completely, eventually.  This does not mean that you want to program complete programs  in it.  It is the slowest and most complex way to construct a windows program.  Of course it does give you the most control, but unless your programs are going to be really inventive with their use of the ui you will find most of this a waste of time.

Using .NET on the other hand will allow you to create programs very quickly and a lot more easily by comparison.  It is also the intended and supported route Microsoft are providing us so I would suggest you will find it a lot easier.

Colin Newell
Wednesday, March 19, 2003

I guess... unless they pull an Apple-like stunt. There was a thread going here a few days ago which contained a link to an article. Can't remember now what the thread was, but that excruciatingly long article was all about M$ and what they are planning for their future. One of the things it implied was that an OSX-non-backwards-compatible type stunt was highly likely.

HeyCoolAid!
Wednesday, March 19, 2003

Oops... my comment was in reference to:

>Win32 APIs will be supported for what is essentially the indefinite future.

HeyCoolAid!
Wednesday, March 19, 2003

Use the best tool for the job.  In most cases, this will probably be .NET.  The do a good job of wrapping the Win32 API in a way that makes it more accessible than it originally was.

I'm a VB.NET guy, but for your purposes I would recommend you stick to C#, not only because the guy you're working with comes from a C++ background, but because C# supports unsafe code which is necessary to use some of the Win32 APIs that aren't wrapped by the .NET Framework.

From what I have seen, .NET and native Win32 APIs work together fairly well.  For example, GDI+ is the managed wrapper around the GDI API.  When you need to do a BitBlt'ing graphics operation (which GDI+ doesn't wrap), you just drop into unmanaged code to do your pointer-based operations (using the "unsafe" keyword), and then continue in a managed context for the rest.  For many API functions you can stay entirely in managed code by using COM Interop.

The next version of the .NET Framework will continue to provide managed wrappers for more and more of these APIs, such as DPAPI.  Eventually I would assume they could do away with many of the original APIs and implement them entirely through managed code.

The safest (and quickest) path is to go with .NET managed libraries and only drop down to raw API calls where absolutely necessary.

ODN
Wednesday, March 19, 2003

Forget MFC and the Win32 API for user interface work.  You can write your low-level non-GUI code in C++, and use another toolkit such as wxWindows or Qt for the GUI.  Or even use Delphi or VB, which can both talk to libraries written in C++.

T. Norman
Wednesday, March 19, 2003

Frederick, no, NT is not a "managed" operating system in the sense of the word that describes the .NET platform.

Brad (dotnetguy.techieswithcats.com)
Thursday, March 20, 2003

It was more a philosophical question. NT can be seen as managed because it shields applications from hardware in much the same way .NET shields an application from accessing memory directly.

Frederik Slijkerman
Thursday, March 20, 2003

The Win API isn't going away. It's the core of the operating system.

While you will probably never write an application directly with the Win API, it can be quite helpful to understand it since .NET and MFC are both built upon the Win API.

Albert, there are still places where using the Win API is still necessary and the "fluffy goop" just won't cut it. I've been working on a server application written in C++ using Windows IO Completion Ports. No MFC, certainly no .NET, just Windows API calls. And that's really about the only way to do this.

That being said....I would heartily recommened someone learning .NET. Just don't be afraid to peek under the hood every so often to learn more about what's really going on.

Mark Hoffman
Thursday, March 20, 2003

<Luddite-Rant>

Marketing rationales aside, I think that MS dumping the Win32 API or making it inaccessible or demoting it to the level of a "legacy" interface is a horrible idea. It's just never appeared to me to be necessary. I wish someone would flame me with compelling reasons why .Net is The Second Coming Of Computer Languages That Makes Everything We Did Before Look "Retarded".

The ".Net Everywhere" mentality seems to consist in the notion that a high level P-code is sufficient for all application programming needs. Fine. (UCSD Pascal, anyone? Like .Net is really a new idea.) But if you need to do something not handled directly by .Net, you drop into unmanaged code, and you must still code to Win32 to do that specialized function. So the universality of Win32 in pre-.Net apps is replaced by a higher level language supplemented by a lower level language - like C++ calling assembler... which is never all that much fun.

Programmers in the mainstream - which means NOT 'elite' and very sharp product developers as found on this list, rather the people that write VB or ASP code for their vertical market employers, or who develop internal applications - have a hard enough time mastering good, basic programming skills, while overbearing employers who only care about manufacturing grommets or whatever other stupid blue collar crap are hovering over their heads. We don't all work in tech friendly environments and areas with sharp, supportive co-workers. (I don't think I've run into anyone at clients in the last 5 years who watched *any* Star Trek.... :-( )


So .Net churns the programming tools landscape with yet  another unnecessary paradigm shift that makes the creation of complete applications just that much more distant from the competencies of "B" student or non college educated average developers. 


I recall the first major paradigm shift in Windows development ten or so years ago - Windows 16 bit to Win32. That was painful but was necessary to buy a quantum more stability in delivered products. The concurrent shift in tools taking place at that time from procedural languages to OOP was highly painful as well but brought great productivity gains and allowed bigger and better programs to be structured. The change now occurring from API to .Net appears to be just as universal but with a negative twist - there's NOTHING being created as a new capability that an end user will see, understand and appreciate as a unique accompanying advantage to newer applications.  Is there? Someone PLEASE tell me if this is not the case.


As far as 'safe' and 'managed' programming, there's always been VB.

I see no accompanying advantage to .Net except that it gives MS the license to obsolete everyone's skills and force feed a new OS to the masses. It pisses me off that a skill set in something as rich and flexible as the Win32 API is being defined down as legacy.  Yeah, because I know it, so that makes my opinion tainted I guess. But also because it's fast, crisp, can be debugged by a mere mortal w/o a layer of run time crap in the way, and it works already.

</Luddite-Rant>

Bored Bystander
Thursday, March 20, 2003

I see more productivity gains from .NET than any other paradigm shift I've ever made. Microsoft will never kill Win32 entirely, so continue on in what you were doing. If you feel like your time is best spent with pointer manipulation and worry about who's going to free something, and how it was created, then you're more than welcome to it.

Like MFC killed off most "pure Win32", so too will .NET kill off most "unmanaged C++". And hey, I've used C++ for more than a decade. I'm pleased as punch not to have to write it any more.

Anybody who thinks .NET is anything like the old VB environment is clearly not at all familiar with either.

Brad (dotnetguy.techieswithcats.com)
Thursday, March 20, 2003

Brad:

On productivity gains - fair enough.


But I would like to ask you:


1) Do you believe that mastery of .Net only will be sufficient for a commercial software developer? Or will the developer have to not only know .Net but also the legacy languages to which they must interface?


2) Forget the productivity gains and niceness for a second. Most users, and even many clients and employers just dont' care if the programming enviroment is nicer. It's the strong exception that anyone who uses your stuff or pays the bills wants you to have more fun programming. So, will the end user see obvious benefits with .Net based software?


3) Is .Net solid enough to compete with a (theoretically perfect) compiled program in terms of speed and stability?  And to eliminate the rare and occasional need to single step through assembler or just above machine language to pin down a problem?


The point is, I don't have a problem with .Net if it's all encompassing, reliable, and supports at least the same level of software experience that current tools do.


I do have a problem with it if it gets in one's way to give customers what they want. I'm unclear that .Net has been established as a good thing that willl be apparent to unwashed end users.


Worst case, .Net runtime gives SW developers yet another (actually good) reason to blame the ghost in the machine for customer's deployment problems...

Bored Bystander
Thursday, March 20, 2003

I'n not Brad, but I'd like to chime in here anyway. And I expect he'll agree with what I say here:

1) Is mastery of just .NET sufficient?

I would argue the answer to this question is no. However, I would also argue that only understanding VB, or MFC, or C++ is insufficient. In general, to be a good developer, you need to understand both the tool you work with, and the layer that your tool sits on.

2) Will customers gain from increased productivity for developers?

Yes. They'll get software that has fewer bugs in less time. Those bugs that do exist should be fixed faster. .NET eliminates entire CLASSES of hard crashes that happened all the time in C++.

3) Is .NET solid enough to compete with the theoretically perfect compiled program?

Theoretically, yes. :-) In practice, it depends on what you're doing. The .NET runtime has been VERY solid in my experience; I've never had it crash on me. As far as dipping into assembly; I've very seldom needed to do that. Usually when I do it's because of either a memory trashing error (doesn't happen in .NET unless you're using unsafe code) or because an API is underdocumented and I don't know what it does. The latter is well handled because most of the class framework is written in .NET, and there are tools that can decompile IL into readable C#.

Typically, the only way a user will know that the app was written in .NET is because the installer put the framework on their machine.

Chris Tavares
Thursday, March 20, 2003

Ok, so the answer is... everybody has their own opinion, and I'd better just go out and form my own.

;)

HeyCoolAid!
Thursday, March 20, 2003

Chris -

You offer compelling reasons to consider .Net. But....


Here's my further opinion. Everyone seems to compare .Net languages to two somewhat crippled and individually inadequate prior languages - Visual C++, and Visual Basic.


This is the argument for the benefits of .Net - that VC++ is too difficult and fussy (no argument there), and VB is not completely well suited to the needs of serious product developers with full OOP support and low level component creation capability.


My answer to these strawmen arguments is that one hated, villified, ignored, PHB-managers-all-afraid-of  language - Delphi. It offers ease of development similar to VB, it has a much more usable component architecture than VB or C++,  and it doesn't require runtimes, either for the application or for most bolt on components.


The point that nobody seems willing to understand is that poor, crippled existing tools *aren't*by themselves a good reason to dump a workable API in favor of a bloated framework with acres of new classes to learn.

If the tools suck, fix the damned tools. But no, that doesn't sell OSs.
Developers embracing .Net languages because the current crop of Win32 MS languages are so poor, is like burning a house down in order to make it easier to remodel the bathroom. Here Mr. Handyman, I will torch my house because you are getting roughed up trying to put in that sink.

In a way I'm tilting against a windmill here. I, you, we will all eventually be compelled to learn .Net in order to stay with this industry. That doesn't mean that it's the best use of anyone's time in terms of delivering completed, working applications to users.  Far from it, in fact. Knowns are always preferable to unknowns in this game.

My $0.02.

Bored Bystander
Thursday, March 20, 2003

1. Is mastery of .NET sufficient?

I don't hire based on the tools people like, I hire based on their ability to adapt and solve problems. If you come to work for us, that will mean .NET -- right now. What will I be using in 5 years? Whatever lets me get my job done quickly and accurately.

2. Will the end user see benefits?

Definitely. The get more feature complete deliverables, which are more stable, and they get them faster.

3. Is .NET solid? Will I single step through assembler?

In my experience, it's miles better in terms of performance and stability for web development vs. ASP, and speed competitive with compiled languages. This will become even more true as the JIT gets more advanced, generating code that's CPU specific and hot-spotting.

As to whether you'll single-step through assembler, I haven't yet, and I've been using it for more 2 years, though an alpha and multiple betas.

Brad (dotnetguy.techieswithcats.com)
Thursday, March 20, 2003

I don't see the argument of ".NET == more OS sales". .NET runs on all supported Win32 OSes, which means 98, Me, NT4, 2000, and XP.

Can you please clarify what you mean?

Brad (dotnetguy.techieswithcats.com)
Thursday, March 20, 2003

Sometimes the new API's are a significant improvement on the old ones, though. For example, have you looked at the Windows crypto API's at all? They're a nightmare from C. However, in the .NET class library it's a simple process to create an object and hand it a string. It's simple and easy to use and I don't need a whole lot of brain power to use it.

As far as Delphi - I've heard lots of people say that Delphi is great. For me, I don't use it because I don't like Pascal. I used it back in college. Heck, I used it in high school. The syntax was wordy, and picky, and I never did figure out the semicolon rules. I was very happy to drop Pascal for C.

So now we have Object Pascal. From what I can tell, the underlying object model of Object Pascal is fairly similar to what's in C++. If I'm going to do that, I'll just use C++.

Yes, the Delphi tools and libraries are supposed to be fantastic; I'll take your word for it. I don't want to deal with Pascal to use them.

I don't WANT a better C++. I don't want just better libraries. I want an environment that does more of the heavy lifting for me. For example - does Delphi have code access security? Can I write an app that allows plugins, and lock down plugins from the host so they can't do what I don't allow them to?

Does Delphi have built in automatic object serialization, with customization if I want it? Reflection? Contexts?

There's a lot to the CLR (common language runtime, the "virtual machine" that forms the basis of .NET) that you simply can't get without going to some kind of managed environment.

Chris Tavares
Thursday, March 20, 2003

A lot of the libraries in .NET actually look like Delphi, because they share a common vision. There are certain key technologies that .NET brings that are really hard to understand how valuable they are until you use them. Aside from the obvious garbage collection (elimination of double frees, cycles, some classes of leaks, etc.), it's hard to imagine how valuable things like Object.ToString() and Reflection are until you really leverage them.

Brad (dotnetguy.techieswithcats.com)
Thursday, March 20, 2003

Chris, there's also C++ Builder from Borland, which supplies the same libraries, but using C++ instead of Object Pascal. The strength of Delphi/C++ Builder is that you can create user interfaces and database apps quickly with reusable components. Unlike VB, the components are extensible through inheritance, and you can easily write your own. Basically, Delphi offers a component/control framework that resembles the .NET environment in many ways.

And about the semicolon rules in Pascal: put a semicolon after each statement, *except* before ELSE. And don't tell me semicolon placement in C++ is straightforward. :-)

Frederik Slijkerman
Thursday, March 20, 2003

As I said above:

I don't want a better C++.

C++ builder doesn't offer enough. I want reflection. I want transparent proxies. I want code access security. I want an environment which allows me to manipulate types as objects at runtime.

I can get all of that with .NET (or Java, or Python) for free. I have to pay for the priviledge of using C++ builder.

Maybe my perspective would be different if I mainly wrote database apps. I don't.

Chris Tavares
Friday, March 21, 2003

*  Recent Topics

*  Fog Creek Home