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

 

[Atmapuri]

Hi!

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.

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:

www.dewresearch.com

Delphi has the productivity of C# and speed of C. And some
things you cant do in C# or C++ (for science and engineering):

http://www.dewresearch.com/Delphi2006Demo.html

(but click on the link only if you have a fast internet).

Best Regards!
Atmapuri

 

[dan]

Hi!


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:

www.dewresearch.com

Delphi has the productivity of C# and speed of C. And some
things you cant do in C# or C++ (for science and engineering):

http://www.dewresearch.com/Delphi2006Demo.html

(but click on the link only if you have a fast internet).

Best Regards!
Atmapuri

I thought I had ruled out the Delphi programming language, because of
my need to incorporate large amounts of existing C code and header
files (reason #6 in my original post), but I'll take another look. If
it looks like a possibility, I'll make a separate post.

Back to my original question: I'm interested in getting feedback, based
on experience, 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.

Daniel

 

[Jeff Gaines]

Back to my original question: I'm interested in getting feedback, based
on experience, 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.

I've always used the IDE rather than an editor. I would put C# alongside
VB6 for ease of programming, it is very quick indeed to put an app
together. I like C and the API but it takes longer (in my experience) to
put an app together. If you plan to do 'serious' programming you will need
to use the API in C# anyway, great chunks of it are missing from C#, it's
its biggest weakness in my view. There is a lot of help now though as
experience has built up in the community. MS really need to accept the
need for this and issue a proper API library. Also missing is the #include
statement - if you write, say, a control using several files you need to
manually link each one to your project each time you use them - an
absolute pain!

A C app using the API will start a lot quicker and can be compiled to work
stand-alone. Delphi is still ahead in terms of compiling a stand-alone app
and speed of starting, I still get tempted to go back to it. There are
also far more free utilities for Delphi, it has always had a great
community spirit. A good example is Mike Lischke's Virtual TreeView and
VirtualShellTools at MustangPeak - there's nothing like either in C#
without paying for them. I'm not sure that will change any time soon.

 

[dan]

I've always used the IDE rather than an editor. I would put C# alongside
VB6 for ease of programming, it is very quick indeed to put an app
together. I like C and the API but it takes longer (in my experience) to
put an app together. If you plan to do 'serious' programming you will need
to use the API in C# anyway, great chunks of it are missing from C#, it's
its biggest weakness in my view. There is a lot of help now though as
experience has built up in the community. MS really need to accept the
need for this and issue a proper API library. Also missing is the #include
statement - if you write, say, a control using several files you need to
manually link each one to your project each time you use them - an
absolute pain!

A C app using the API will start a lot quicker and can be compiled to work
stand-alone. Delphi is still ahead in terms of compiling a stand-alone app
and speed of starting, I still get tempted to go back to it. There are
also far more free utilities for Delphi, it has always had a great
community spirit. A good example is Mike Lischke's Virtual TreeView and
VirtualShellTools at MustangPeak - there's nothing like either in C#
without paying for them. I'm not sure that will change any time soon.

About C API vs C# - Yes, I am doing "serious programming". Did you do
your C API programming in an editor? Were there any particular C API
areas that you found "tricky" or arduous?

About #include statements - Yes, I find using #includes and other C
preprocessor directives invaluable for what I do. I run the C# through
CPP before using the C# compiler.

About Delphi - If I used Delphi, could I incorporate the existing C
code, either directly, or called from a compiled library? Could I reuse
the C header files somehow? Or would I need to rewrite everything in
Delphi? Could I write the interface functions in Delphi, and retain the
C business logic functions? Could a single Delphi source code system
compile to Windows, Linux, and Mac?

Daniel Goldman

 

[Michael C]

About C API vs C# - Yes, I am doing "serious programming". Did you do
your C API programming in an editor? Were there any particular C API
areas that you found "tricky" or arduous?

There is a fair bit more work involved in c# because you have to import
everything. This is all very tedious work but doesn't require a huge amount
of brain power. Most of the time the API work straight off but other times
you need to do a bit of tweaking, usually with passing string buffers. I
haven't found any APIs I couldn't call. With C++ it's all there for you (or
just an #include away). I wouldn't say it's a reason not to use c# however
it could be a reason to write individual components in C.

About #include statements - Yes, I find using #includes and other C
preprocessor directives invaluable for what I do. I run the C# through
CPP before using the C# compiler.

Someone mentioned that it was possible to use #include in c# or it was going
to be possible but I have not confirmed this.

Michael

 

[Michael S]

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.

I've tried both and you can use both if you want to.
It is not as easy as it sounds, as I guess you allready fathom.

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,

I would say that is your true problem,
200/70 seems like a weird ratio, but then I don't know how headers may
explode when using c++ for windows apps. If it is not 200/700 you do got a
headache.

It could be 1000/70 or 1000/1000 or 500/1000.. you'd still be in trouble.

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,

If you are going for C#, VI won't hack it.

We can compare competition with you using VI and your worst enemy using VS
2005, The IComparer can take a Coyote and a Road-Runner and we'll see who
wins.

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

If you solve this, you get a medal from the high magi.
With managed code and managed data, the jitter must compile.

Our only hope is that someone comes up with a THz cpu and similar memory
bus.

But are you sure that this is what your 'customer' and 'users' demand. To
start fast?
Or is it just you who compile and restart all the time?

What may be your problem is not nececcary your users problem. How often do
they start the software? Can they leave it on at night?

** 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

'Vitalnet.Not' doesn't use a lot of memory. .NET does.
..NET is a hog when it comes to memory... Which is a good thing.
If .NET can find unfragemented memory for you app, it will allocate as much
as it wants and pick a fight with the kernel if it windows thinks it's too
much.

Try running a few other .NET apps side by your app and you will see that the
allocs won't go up.

If the memory do go up, you got a memory-leak and you are as *fruited* as if
you was back in C++. Have fun =)

** 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

Too complex for me to just write a line about it. Others will ask you to
post code for analysis.

** 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.

Yes, this is a problem, and the fun has just begun.
Soon ms wants us to move to vista. Let the circus begin.

You must tell 'management' and 'customer' that this is no easy shift.

** 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.

Have you heard of the giant penguine that has a brain the size of a human?
It was very tall...
Well, Monty Python presented this but then said that it was to be known as
the 'Complete Waste Of Time Theory'

Obfuscate away and make maintainance hard, secure in the knowledge that many
people in this forum would have no problem decompiling it. Heck, I bet the
decompilier would give the code better names on variables that you did when
you hid them.

Try a good decompiler. On .NET and C++, be niké, just do it!
It's almost a scary moment when you see how well these decompilers can
almost redo the code you written.

** 6) More difficult to maintain (in this particular case). The app has

*********** 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.

Maybe it is time for a total re-design.
I remember a famous qoute:

- C++ is like jamming a helicopter inside a Miata and expecting some sort of
improvement. (Drew Olbrich)

And that was from going from C to C++.
What you must do is to embrace C# and .NET, tell management that your huge
project cannot be ported.

Be strong now and back off, or resign or why not play mad.. or your project
will wind up on The Daily
WTF in a few months.

Daniel Goldman

Sincerely
- Michael S

 

[Cor Ligthert [MVP]]

Jeff,

If you plan to do 'serious' programming you will need to use the API in C#
anyway, great chunks of it are missing from C#, it's its biggest weakness
in my view.

There is not much in C#, however it has an it seems for me endless class
library as it is in .Net that you can use, which make the possibilities so
wide as I have never seen in any programming language. Are you *completely*
common with this in all versions of the Framework? (With other words do you
know all classes for WindowsForms, HTTP, ASPNET, Mobile, Data etc etc?)

Cor

 

[Michael C]

There is not much in C#, however it has an it seems for me endless class
library as it is in .Net that you can use, which make the possibilities so
wide as I have never seen in any programming language. Are you
*completely* common with this in all versions of the Framework? (With
other words do you know all classes for WindowsForms, HTTP, ASPNET,
Mobile, Data etc etc?)

This is what I use in my app that's not included (all the major areas really

DirectShow
Burn CD via IMAPI
Twain
Windows Image Aquisition
Video For Windows
plus plenty of smaller functions.

Michael

 

[Jon Davis]

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.

To answer your question, yes, building a complete Windows app using only C
and Win32 is much harder than with C# and Visual Studio. Much of .NET's core
functions build on Win32 while adding functionality. The application
development of the C language with only Win32 to support you is very
barebones and although you can accomplish most anything you have to manually
implement most everything. Grab Charles Petzold's book Programming Windows,
Fifth Edition, and take a look at the code samples. Find out for yourself.
The book strictly Win32 ("C API for Windows") and it's the thickest book in
my library. Your solution will execute fast but the GUI development process
will require perhaps 1000% as much effort (perhaps less but perhaps more) as
it takes you to build a GUI-enabled app with C# or VB6. That's my estimate.
Just tracking mouse and keyboard tasks is a manual task. The bulk of your
labors will be debugging and QA'ing a buggy solution that could have been
built much more stable if you had stuck with libraries and tools that
already implemented a solid infrastructure for your components.

The reason why .NET is slower is because it is allowing you to build on
heavily QA'd componets that are much more stable and that have a very
comprehensive and consistent feature set. Delphi and C and the like are
stable and comprehensive while also being very fast, but by not letting the
tool build such things for you behind your back as memory management, API
visibility, common GUI functionality (such as docking and consistent
properties), OOP, etc., you'll find yourself slapping features together in
custom code that will not be consistent or will be prone to
mis-implementation (buggy), and the end result very likely be very kludgy
and unstable.

Jon

 

[Andy Sinclair]

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.

Writing a GUI app in C API has a steep learning curve, but is not too
bad once you get the hang of it. Your application will run much
faster and be more compact if it's written without .NET.

From the screenshots it appears your application has a fairly basic
user interface (i.e. Dialog boxes containing list and editboxes), with
the complexity in the processing.

Dialog boxes are fairly easy to do in C, and it will be easy to
inteface to your current code.

Regards
Andy Sinclair

 

[dan]

Writing a GUI app in C API has a steep learning curve, but is not too
bad once you get the hang of it. Your application will run much
faster and be more compact if it's written without .NET.

From the screenshots it appears your application has a fairly basic
user interface (i.e. Dialog boxes containing list and editboxes), with
the complexity in the processing.

Dialog boxes are fairly easy to do in C, and it will be easy to
inteface to your current code.

Regards
Andy Sinclair

*** 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.

C API OK but takes fiddling: Michael C says the API works fine most of
the time, but other times has to do a fair amount of tweaking, usually
with passing string buffers.

C API much, much harder: Jon Davis says C Win32 development is very
barebones and you have to manually implement most everything. The GUI
application process will take about 1000% more effort that C# or VB.
You have to track mouse and keyboard tasks. You have to slap things
together in custom code that will not be consistent or will be buggy.
The end result will likely be kludgy and unstable.

C API OK for Vitalnet: Andy Sinclair says C API has steep learning
curve, but not too bad once you get the hang of it. He notes that the
Vitalnet interface has a pretty basic interface (I agree), so using the
C API wouldn't be too difficult.

*** Here are some other comments I've gotten:

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?

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.

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.

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.

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?

Thanks,
Daniel Goldman

 

[Atmapuri]

Hi!

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?

You would have to build dll's from your C files and then write Delphi
import files, which can be a lot of work and is I admit a problem.
Other than that you can work the same as in C# 95% of time...

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?

Using C++ against C# is a big difference. Typical rule of thumb is
that your cost goes up 3-5x.. assuming that you are expirienced
programmer building UI in C++...

Regards!
Atmapuri

 

[Jeff Gaines]

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?

There is a tool to convert Delphi to C++ Builder at:
http://www.thinkershome.com/d2c/index.htm

I haven't used it so this is info not a recommendation

 

[Jeff Gaines]

Jeff,


There is not much in C#, however it has an it seems for me endless class
library as it is in .Net that you can use, which make the possibilities so
wide as I have never seen in any programming language. Are you completely
common with this in all versions of the Framework? (With other words do
you know all classes for WindowsForms, HTTP, ASPNET, Mobile, Data etc etc?)

Cor

I certainly don't know all the classes!!!

I know my way around those I use. I was thinking of areas like a file
manager using the system icons (with masks) where I have to resort to the
API. Even a simple beep means a visit to the API.

 

[Daniel James]

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.

 

[Jeff Gaines]

There is a tool to convert Delphi to C++ Builder at:
http://www.thinkershome.com/d2c/index.htm

I haven't used it so this is info not a recommendation

And that's not what you want :-(

Try again, this one is supposed to work in the opposite direction:

http://cc.borland.com/Item.aspx?ID=23991

 

[Chris Becke]

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/2005/05/10/416151.aspx

 

[Jerry Coffin]

[ 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).

 

[Michael S]

*** 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