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

[Michael C]

"Herfried K. Wagner [MVP]" <hi************ ***@gmx.atwrote in message
news:et******** ******@TK2MSFTN GP04.phx.gbl...

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.

Although I've done projects in vb6 before I would never choose it again even
if it was still supported. It is amazingly fast for a basic language but has
too many problems for large projects. The op has a fairly large project at
270,000 lines and VB stuggled badly with one of my projects at 130,000
lines. It's also very limited with API usage which the OP needs to use
heavily.

Michael

[Michael S]

"Michael C" <no****@nospam. comwrote in message
news:eB******** ******@TK2MSFTN GP03.phx.gbl...

"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

Hehe. The post has on error resume next and so it shows despite its flaws.
In a OO environment it would throw a whole bunch of exceptions =)

OldSchoolNotSup portedException
NativeCodeMyAss Exception
FastForASnailEx ception

Just no name a few =)

Nice Name
- Michael S

[Michael C]

"Michael S" <[e-mail] e in message
news:ur******** ******@TK2MSFTN GP06.phx.gbl...

NativeCodeMyAss Exception
FastForASnailEx ception

Despite all it's faults VB6 does compile to native code and is very fast.

Michael

[Jerry Coffin]

In article <um************ **@TK2MSFTNGP06 .phx.gbl>, [e-mail] says...

[ ... ]

Your post was so great that I didn't even noticed the above paragraph.

Thank you.

But now I'll jump at it.

Visual Basic Sucks So hard It Bends Light.

I sure am glad I didn't recommend VB anywhere... :-)

From what I've seen, some people have gotten excellent use out of VB, so
I'm not sure I'd say it's really all that awful. It doesn't look like
it's suited to _this_ project at all, but it seems to work all right for
a pretty fair number of smaller projects, at least for some people.

In fairness, however, I have to admit that this assesment IS based
almost entirely upon things I've seen others do -- my own use of it has
been relatively minimal.

--
Later,
Jerry.

The universe is a figment of its own imagination.

[Michael C]

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

From what I've seen, some people have gotten excellent use out of VB, so
I'm not sure I'd say it's really all that awful. It doesn't look like
it's suited to _this_ project at all, but it seems to work all right for
a pretty fair number of smaller projects, at least for some people.

IMO that is VB6s biggest fault, that it doesn't support large projects very
well.

Michael

[Michael C]

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

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.

The other thing that can be a bit fiddly is structs, quite often you need to
muck around with attributes (example below). Some structs don't translate
across too well, for example if they have a union it's sometimes necessary
to define the params as pointers and resolve them manually. And one other
issue is arrays, if you need to pass a large array to an api it will copy
the entire array to a new memory location and potentially back again. There
could be ways around that I believe by pinning the array but that's extra
work again. Not that all this is a show stopper.

Michael

[StructLayout(La youtKind.Sequen tial), ComVisible(fals e)]
public class DIBSECTION
{
public SafeNativeMetho ds.BITMAP dsBm;
public SafeNativeMetho ds.BITMAPINFOHE ADER dsBmih;
[MarshalAs(Unman agedType.ByValA rray, SizeConst=3)]
public int[] dsBitfields;
public IntPtr dshSection;
public int dsOffset;
public DIBSECTION();
}

[Leslie Milburn]

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

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?

Daniel Goldman

Hi Daniel,

I have been programming windows since Win286, my original background being a
Pyramid Unix System. It has been years since I used Curses before the days
of 'X' even. My batch file to launch the Brief editor is still called vi.bat
:-) My language of choice is C calling the Win32 API and it always will be
until I am forced to do something different. My latest application contains
approx 300,000 lines of C code fully commented. I do not use any IDE. I use
Brief as my code editor and compile using make files from the command line.

I am not a fan of .net becuase it has many problems - speed being one of
them. Sure it might give portability in certain circumstances but if you go
..net you might find yourself locked into a Microsoft solution. Remember all
of these higher level languages eventually call the API so effectively they
are just layers of stuff that you might not need which only cause bloating.

The secret to success is use a modular design and create Windows Objects (as
opposed to C++ classes) which are self contained in DLL's. This way once a
Dynamic library has been written and tested it can be reused again and
again.

So to give one piece of advice, just have a look at some of the forums and
you will see that many modern programmers simply do not understand the
fundamentals of Windows Programming that was mandatory in the beginning of
time. This is not intended as a criticism but rather an observation. This
has come about because of things like C++ classes, .net and even Delphi and
C++ Builder being the tool of choice. Ask many modern programmers about make
files and they would be able to create, let alone read one.

To make a comment on Visual Basic, I am sorry to say that as far as
programmers of my era are/were concerned VB was a great Prototyping Tool and
thats it !! You would never ever write a serious application using it.

To make a comment on Delphi, ask any modern Delphi programmer about the BDE
and all they will tell you is about the Delphi objects such as TDatabase and
TTable objects - they will not tell you about the API because again the
majority don't know how to use the API.

To make a comment on C++, I am not a fan of classes or how they are defined
in header files. I am not a fan of what appears to be the norm of C++ code
actually being embedded in the class definition in header files. I am not a
fan of being able to declare a variable where ever I want - this reminds me
of the bad old days of Level II BASIC and what was commonly referred to as
spaghetti code. IMO, C++ encourages spaghetti programming.

So at the end of the day, if you are comfortable with C, stick with it.
Win32 is simply an API just like any other, it gives you full control, it
gives you speed, its gives you a small footprint. All you have to do is
learn it. Coming from a Unix background this should not be difficult for you
at all.

Leslie.

[Leslie Milburn]

has come about because of things like C++ classes, .net and even Delphi
and
C++ Builder being the tool of choice. Ask many modern programmers about
make
files and they would be able to create, let alone read one.

and they would ^ not ^ be able to create, let alone read one.

[Charlie Gibbs]

In article <vv************ *************** *****@4ax.com>, [e-mail]
(Andy Sinclair) writes:

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.

I ported a 200,000 line curses project from MS-DOS to Windows. Mind
you, that was back in the 3.1 days - but we had to continue support
both for MS-DOS and Unix, so portability was a must. The project
already had the equivalent of dialog boxes using a table-driven
library module (which had the advantage that you could build the
table on the fly and have dynamically-reconfigurable screens).
I ported this module to Windows - not using standard dialog boxes,
but by building up my own with appropriate child window controls.
It still works just fine, and still is fully portable.

Of course, I always was a low-level type. I'm still happy working
in straight C through the Windows APIs. For me, it would be far
more complicated to learn and convert to all the latest toolkits -
and I'd lose my portability.

I say go for it. Get a copy of Petzold, start reading, and do lots
of experiments. IMHO it's worth it. All of my .EXEs are free-standing
(not a DLL anywhere to be seen), the biggest .EXE is 250K, and the
programs run fast. It's a bit more work up front, but now that I have
the framework in place it's a dream. Best of all, I'm not vulnerable
to the foibles of the myriad toolkits I'd have to work with - if
something needs fixing, it's my own code and I can fix it.

--
/~\ cg****@kltpzyxm .invalid (Charlie Gibbs)
\ / I'm really at ac.dekanfrus if you read it the right way.
X Top-posted messages will probably be ignored. See RFC1855.
/ \ HTML will DEFINITELY be ignored. Join the ASCII ribbon campaign!

[Cor Ligthert [MVP]]

Michael,

It's also very limited with API usage which the OP needs to use

I surely would not write this to Herfried or Mattias, in my idea are they
able to do everything with API's in whatever program language.

Cor

>