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]

Atmapuri wrote:

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

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]

On 03/09/2006 in message
<11************ **********@74g2 000cwt.googlegr oups.comdan wrote:

>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
VirtualShellToo ls at MustangPeak - there's nothing like either in C#
without paying for them. I'm not sure that will change any time soon.

--
Jeff Gaines

[Michael S]

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

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

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

*********** End background / war story
</snip>

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

[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]

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.

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]

Andy Sinclair wrote:

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.

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]

On 04/09/2006 in message
<11************ *********@74g20 00cwt.googlegro ups.comdan wrote:

>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