how much harder is Windows C API than C#/.NET

[dan]

For writing a Windows desktop application, how much harder is it to use
the Windows C API than C#/.NET, assuming the coding is done in an
editor? What specific aspects were more difficult? I'm looking for
responses from programmers who have tried both.

*********** Begin background / war story

I'm porting a C/Curses data analysis application called Vitalnet, with
about 70,000 lines of source code and 200,000 lines of headers files,
from a C/Curses version, to run under windows. I have used C# with the
2.0 .NET framework.

http://www.ehdp.com/vp-win/picture01.htm shows some pictures of what
the Vitalnet Windows interface looks like. I write code into vi editor,
which I prefer and is necessary to make the program so it can generate
multiple customized executables. I have not tried the C Windows API
yet. I like programming in both C and C# a lot, and did not find C#
difficult to use, but am concerned with some of .NET downsides I have
observed. The tests below are on Windows 2000, Pentium III, Seagate
7200.7 hard disk, 256 MB RAM.

Problems I found with C#/.NET that make me consider using C API:

** 1) Starts slow. Startup times (secs) on my PC:

Vitalnet .NET first time (not using ngen) = 11
Vitalnet .NET second time (not using ngen) = 5
Vitalnet .NET first time (using ngen) = 9
Vitalnet .NET second time (using ngen) = 4
Microsoft Word = 2
Vitalnet Curses = 1

** 2) Uses lots of memory. RAM used (MB) on my PC:

Vitalnet .NET = 20 (with each invocation)
Microsoft Word = 3
Internet Explorer = 1
Vitalnet Curses = 1

** 3) Runs slower when reading and parsing millions of records. The C
version uses pointers in a critical section of code. I have not really
tried optimizing that section in the .NET app, but it would be harder.
Time (secs) for two different big analyses on my PC:

Vitalnet .NET = 15 + 27 = 42
Vitalnet Curses = 14 + 16 = 30

** 4) Seems harder to install. Because .NET framework might need to be
installed. Installing to a laptop (with legal software), got various
messages from Microsoft that I think might confuse users. On the other
hand, I know the framework is automatically installed if you run
Windows Update.

** 5) Seems less secure from reverse engineering. I know it's usually
easier to just start from scratch rather than steal someone's code, but
you never know. I obfuscate function and variable names.

** 6) More difficult to maintain (in this particular case). The app has
over 1000 existing business logic C functions, plus many data
structures written in C. This is necessary to support the web-based
versions of Vitalnet, so I don't want to totally switch to C# (or
java). Using CPP macros, I incorporated the C business logic functions
into C#/.NET. I think it's OK to read, but it certainly is different
and non-standard. Maybe better to just use C.

I had the notion that programming the C API is a big pain in the neck.
But I've never tried it, so don't know. Some things that are easy in
C#/.NET, I have no idea if will be easy using C API. For example, embed
a browser within a tabbed page using the C API. Or, set up complex tree
views with many events. Or, do flowlayout. I'm not that interested in
the managed code and garbage collection benefits: I think I can handle
pointers and malloc/free fine, unless I'm missing something about the C
API. Also, code brevity by itself is of little benefit to me. I'm more
concerned about difficulty of programming the user interface, and
having to do a lot of error-prone low level details by hand.

I know Microsoft wants developers to use .NET for new apps. I don't
know how many widely used commercial desktop apps for C#/.NET have been
developed. I'm also looking into making the web version more
interactive, using AJAX. I'm not interested in MFC/C++ (already using
C, don't like C++, and MFC sounds more complex). I'm not interested in
Basic. I like Java, but it lacks some capabilities I need related to
structures and passing arguments. I already know what books and other
resources to use to learn the C API, if I decide to switch.

*********** End background / war story

So, you programmers who have tried both, how much harder is it to use
the Windows C API than C#/.NET for writing a desktop application,
assuming the programmer is coding into an editor? Or any other
comments.

Daniel Goldman

[Mark Rae]

"Atmapuri" <ja************ @usa.netwrote in message
news:Rk******** ************@ne ws.siol.net...

The Golden Section for W32 Desktop App development is
Borland Delphi 2006. If you complement it with our library,
for your type of application you can achieve fast results very fast:

Fast results very fast, eh...? Sounds pretty fast!

:-)

[Daniel James]

In article news:<11******* **************@ 74g2000cwt.goog legroups.com>, Dan
wrote:

For writing a Windows desktop application, how much harder is it to use
the Windows C API than C#/.NET, assuming the coding is done in an
editor?

The Windows C API is fairly low-level, while the .NET interfaces are
class-based and at a level more comparable to (say) Microsoft's MFC C++
API.

It's not harder, really, to use the C APIs, but it's certainly much more
work than using one of the higher-level options.

Cheers,
Daniel.

[Chris Becke]

"dan" <da*******@yaho o.comwrote in message
news:11******** *************@7 4g2000cwt.googl egroups.com...

For writing a Windows desktop application, how much harder is it to use
the Windows C API than C#/.NET, assuming the coding is done in an
editor? What specific aspects were more difficult? I'm looking for
responses from programmers who have tried both.

http://blogs.msdn.com/ricom/archive/...10/416151.aspx

[Jerry Coffin]

In article <11************ *********@74g20 00cwt.googlegro ups.com>,
da*******@yahoo .com says...

[ Warning: I'd already written virtually all of this before noticing how
heavily it's cross-posted. I'm not excited about rewriting it all, but
please resut assured that I don't mean my comments about .NET and
(especially) the newer IDEs as insults toward anybody (except, perhaps,
the people who designed them), so please don't consider this flamebait
or anything like that.]

[ ... ]

Problems I found with C#/.NET that make me consider using C API:

[ ... reasonable points elided ]

IMO, this is roughly equivalent to deciding that it's impractical to
build your own space shuttle to travel 500 miles twice a year, so you
want to know that brand of pants has the most durable material in the
knees, so you can crawl instead. You're (quite rightly, IMO) rejecting
one extreme, but that doesn't mean you have to go to the absolute
opposite extreme.

There are a number of possibilities in between .NET and the C API that I
suspect will fit your needs better than either. Based on the concerns
you've raised, I think MFC and WTL are both strong possibilities, and
either will almost certainly serve you far better than C# or pure C.

Choosing between the two may be somewhat difficult. WTL is generally a
nicer library -- but it's not directly supported by the MS IDEs. You
have a lot less code to write than you would in a pure C program, but
you still have to write all the code yourself -- there's no code
generators or anything like that to help out. You can't open a dialog
template and attach code to an control even with a single click, or
anything like that.

The result, however, is usually close to pure C in terms of size, and
will often execute a little faster -- its use of templates often allows
code to be generated inline that would typically involve something like
calling a function via a pointer in C. Depending on the kinds of things
you do, you may see anywhere from a small slowdown to a fairly
substantial speedup -- though since the "guts" of your program is
already written in C, the substantial speedup isn't very likely.

MFC isn't as well-designed of a framework. Its overall concept is
roughly similar to (and therefore almost as bad as) .NET. OTOH, it is
reasonably supported in the MS IDEs -- you get code generators and such
that are missing with WTL. The biggest problem is that the last IDE that
really worked well was VS 6.0, which is ancient, and has fairly severe
limits WRT to C++ conformance. In the newer versions, the C++ compilers
have gotten a lot better, but the IDEs have gotten at least as much
worse. For the (admittedly few) who know how to use it well, VS 6 is
still (by far) the most productive programming environment ever produced
for Windows. In fairness, the newer IDEs have improved in a few specific
areas (e.g. producing web services) but for producing a normal Windows
application, they're substantially worse (that's code for: "They blow
chunks.")

Although the newer IDEs make the programs substantially more difficult
to write, using MFC still typically produces results that are
substantially smaller and faster than their counterparts using .NET.

Another possibility would be RSWL, from www.relisoft.com. I haven't put
this to any serious use myself, but what I've seen so far looks like
it's quite well designed. This, of course, isn't supported by any code
genertors, or anything like that either. It seems to be sufficiently
well designed that this may not be a terrible loss though -- but it'll
depend heavily upon what you're doing. From the sounds of things, for
what you're doing, the code generators may easily make a bigger
difference than the library design.

I should also mention a paper on the same site titled "MFCs considered
harmful" -- even though I recommend MFC above, I'd also advise reading
this paper. Although I obviously disagree with their conclusions (at
least in part) much of what they say has at least some merit -- the
primary question is whether you're writing the kind of application where
the shortcomings of MFC have particular relevance. From what you've said
so far, my guess is they mostly don't -- but you obviously know a lot
more about your application than I do. There's no question that MFC does
have real shortcomings, and it's worthwhile to be aware of them. It's
also worthwhile to consider the degree (if any) to which they're likely
to apply in your situation, not just in some hypothetical application
that may bear little or no relationship to yours (it's also interesting
to note the number of MFC problems they cite that apply equally or even
moreso to .NET).

--
Later,
Jerry.

The universe is a figment of its own imagination.

[Michael S]

"dan" <da*******@yaho o.comwrote in message
news:11******** *************@7 4g2000cwt.googl egroups.com...

*** Here's what I've heard so far regarding my basic question:

C API OK but takes longer: Jeff Gaines prefers C# and VB6 for ease of
programming. He also likes C API, but it takes longer.

Calling C from VB6 is a nightmare. Avaid at all cost.

Delphi recommended: Atmapuri and Jeff Gaines recommend to use Delphi.
But I'm uncertain if I could incorporate the existing C code, either
directly, or called from a compiled library. Or would I need to rewrite
everything in Delphi?

I didn't know Delphi was an option.
But now that is on the table I would say it is a great option.
Delphi GUI components is extremely fast and has a rich featureset.

Delphi can call C DLL's with both standard calling convention and cdecl.

The tedious part is to translate all c-structs to pascal-records.

Too many header lines?: Michael S questioned why so many more lines of
C header files (200,000) than source code (70,000). The reason is that
the source compiles to multiple executables, one for each data-area
combination, such as Texas birth data. It's a way of simulating objects
with C, using arrays as the objects. Only certain parts of the header
files get compiled, depending on which executable is being made. It's
never been a problem.

It's no small thing you try to do.
I actually envy you for having a complex task at hand.

vi bad for C#?: Michael S questioned using vi for programming C#. I
don't have a choice. I couldn't write this kind of extensible framework
within VS. I agree if I was doing a single app that VS would probably
really speed things up.

poor poor you =)

Slow start OK?: Michael S wonders if users really demand that the app
start fast. I don't know the answer. It's just my guess. I know I get
impatient if waiting for a web page to download, or a slow app to
start. I think others would also.

Well my experience with business applications is that people start the app
monday morning and then keep it running for weeks and even months. One
application I've written logs start and stop and users shutdown when windows
needs an update.

Any other opinions on my basic question: How much harder is it to use
the Windows C API than C#/.NET for writing a desktop GUI application,
assuming the programmer is coding into an editor, and assuming a
high-quality resulting program?

GUI programming using C# or Delphi more or less demands that you code using
editors like VS and Delphi.

Coding GUI in C using VI sounds.. just tedious.

Thanks,
Daniel Goldman

Good Luck
- Michael S

[Jerry Coffin]

In article <MP************ ************@ne ws.sunsite.dk>,
jc*****@taeus.c om says...

[ ... ]

For the (admittedly few) who know how to use it well, VS 6 is
still (by far) the most productive programming environment ever produced
for Windows.

Before people start (probably rightly) jumping on this, I should point
out that I only meant to compare VS 6 to its direct predecessors and
sucessors, not to the plethora of other environments out there.
Attempting to compare (for example) VS 6 to Delphi (for only one obvious
example) wasn't my intent at all.

--
Later,
Jerry.

The universe is a figment of its own imagination.

[Ian Semmel]

Well, you might not like C++ and MFC, but I think that it would be the easiest path.

dan wrote:

For writing a Windows desktop application, how much harder is it to use
the Windows C API than C#/.NET, assuming the coding is done in an
editor? What specific aspects were more difficult? I'm looking for
responses from programmers who have tried both.

*********** Begin background / war story

I'm porting a C/Curses data analysis application called Vitalnet, with
about 70,000 lines of source code and 200,000 lines of headers files,
from a C/Curses version, to run under windows. I have used C# with the
2.0 .NET framework.

http://www.ehdp.com/vp-win/picture01.htm shows some pictures of what
the Vitalnet Windows interface looks like. I write code into vi editor,
which I prefer and is necessary to make the program so it can generate
multiple customized executables. I have not tried the C Windows API
yet. I like programming in both C and C# a lot, and did not find C#
difficult to use, but am concerned with some of .NET downsides I have
observed. The tests below are on Windows 2000, Pentium III, Seagate
7200.7 hard disk, 256 MB RAM.

Problems I found with C#/.NET that make me consider using C API:

** 1) Starts slow. Startup times (secs) on my PC:

Vitalnet .NET first time (not using ngen) = 11
Vitalnet .NET second time (not using ngen) = 5
Vitalnet .NET first time (using ngen) = 9
Vitalnet .NET second time (using ngen) = 4
Microsoft Word = 2
Vitalnet Curses = 1

** 2) Uses lots of memory. RAM used (MB) on my PC:

Vitalnet .NET = 20 (with each invocation)
Microsoft Word = 3
Internet Explorer = 1
Vitalnet Curses = 1

** 3) Runs slower when reading and parsing millions of records. The C
version uses pointers in a critical section of code. I have not really
tried optimizing that section in the .NET app, but it would be harder.
Time (secs) for two different big analyses on my PC:

Vitalnet .NET = 15 + 27 = 42
Vitalnet Curses = 14 + 16 = 30

** 4) Seems harder to install. Because .NET framework might need to be
installed. Installing to a laptop (with legal software), got various
messages from Microsoft that I think might confuse users. On the other
hand, I know the framework is automatically installed if you run
Windows Update.

** 5) Seems less secure from reverse engineering. I know it's usually
easier to just start from scratch rather than steal someone's code, but
you never know. I obfuscate function and variable names.

** 6) More difficult to maintain (in this particular case). The app has
over 1000 existing business logic C functions, plus many data
structures written in C. This is necessary to support the web-based
versions of Vitalnet, so I don't want to totally switch to C# (or
java). Using CPP macros, I incorporated the C business logic functions
into C#/.NET. I think it's OK to read, but it certainly is different
and non-standard. Maybe better to just use C.

I had the notion that programming the C API is a big pain in the neck.
But I've never tried it, so don't know. Some things that are easy in
C#/.NET, I have no idea if will be easy using C API. For example, embed
a browser within a tabbed page using the C API. Or, set up complex tree
views with many events. Or, do flowlayout. I'm not that interested in
the managed code and garbage collection benefits: I think I can handle
pointers and malloc/free fine, unless I'm missing something about the C
API. Also, code brevity by itself is of little benefit to me. I'm more
concerned about difficulty of programming the user interface, and
having to do a lot of error-prone low level details by hand.

I know Microsoft wants developers to use .NET for new apps. I don't
know how many widely used commercial desktop apps for C#/.NET have been
developed. I'm also looking into making the web version more
interactive, using AJAX. I'm not interested in MFC/C++ (already using
C, don't like C++, and MFC sounds more complex). I'm not interested in
Basic. I like Java, but it lacks some capabilities I need related to
structures and passing arguments. I already know what books and other
resources to use to learn the C API, if I decide to switch.

*********** End background / war story

So, you programmers who have tried both, how much harder is it to use
the Windows C API than C#/.NET for writing a desktop application,
assuming the programmer is coding into an editor? Or any other
comments.

Daniel Goldman

[Michael S]

"Jerry Coffin" <jc*****@taeus. comwrote in message
news:MP******** *************** *@news.sunsite. dk...

In article <MP************ ************@ne ws.sunsite.dk>,
jc*****@taeus.c om says...

[ ... ]

>For the (admittedly few) who know how to use it well, VS 6 is
still (by far) the most productive programming environment ever produced
for Windows.

Before people start (probably rightly) jumping on this, I should point
out that I only meant to compare VS 6 to its direct predecessors and
sucessors, not to the plethora of other environments out there.
Attempting to compare (for example) VS 6 to Delphi (for only one obvious
example) wasn't my intent at all.

--
Later,
Jerry.

The universe is a figment of its own imagination.

Your post was so great that I didn't even noticed the above paragraph.
But now I'll jump at it.

Visual Basic Sucks So hard It Bends Light.

But again, thanks for a insightful post

- Michael S

[Michael C]

"Jon Davis" <jo*@REMOVE.ME. PLEASE.jondavis .netwrote in message
news:eR******** ******@TK2MSFTN GP02.phx.gbl...

Are you just trying to build a class library? If so, is performance more
of an issue than ease? It sounds like you already made your decision; C#
is easy but it is not fast enough.

If you're building an application with a GUI or with GUI components, you
should consider VB6. It's "old school" but compiles to native code and is
quite fast. You won't be able to optimize it quite as fast as C but you
can interoperate with the Win32 API and the compromise of ease and
performance is there. The down side is that it is an older tool. Then
again, so is the C language.

You have got to friggin kidding. Only a complete idiot would start a new
project in vb6.

Michael

[Herfried K. Wagner [MVP]]

"Michael C" <no****@nospam. comschrieb:

>Are you just trying to build a class library? If so, is performance more
of an issue than ease? It sounds like you already made your decision; C#
is easy but it is not fast enough.

If you're building an application with a GUI or with GUI components, you
should consider VB6. It's "old school" but compiles to native code and is
quite fast. You won't be able to optimize it quite as fast as C but you
can interoperate with the Win32 API and the compromise of ease and
performance is there. The down side is that it is an older tool. Then
again, so is the C language.

You have got to friggin kidding. Only a complete idiot would start a new
project in vb6.

Hm... I would not start new projects in VB6 because of the lack of support
for VB6 development currently and in near future. However, I'd choose VB6
for technical reasons and its ease of use if this was the only criterion.
Note the "The down side is that it is an older tool" in the post you replied
to.

--
M S Herfried K. Wagner
M V P <URL:http://dotnet.mvps.org/>
V B <URL:http://dotnet.mvps.org/dotnet/faqs/>