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

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

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

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

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

Atmapuri wrote: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

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

On 03/09/2006 in message
<1157324380.635902.105210@74g2000cwt.googlegroups. comdan wrote:
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.

--
Jeff Gaines

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

"dan" <dagoldman@yahoo.comwrote in message
news:1157320709.462994.90670@74g2000cwt.googlegrou ps.com...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 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.
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.
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?

'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 =)

Too complex for me to just write a line about it. Others will ask you to
post code for analysis.
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.
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>*********** End background / war story
</snip>
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.
Sincerely
- Michael S

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

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

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

dan wrote: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

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

Andy Sinclair wrote:*** 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

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

Hi!
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...
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

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

On 04/09/2006 in message
<1157357898.145467.48390@74g2000cwt.googlegroups.c omdan wrote:
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

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

"Atmapuri" <janez.makovsek@usa.netwrote in message
news:RkIKg.4811$oj5.1836112@news.siol.net...
Fast results very fast, eh...? Sounds pretty fast!

:-)

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

In article news:<1157320709.462994.90670@74g2000cwt.googlegro ups.com>, Dan
wrote: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.

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

"dan" <dagoldman@yahoo.comwrote in message
news:1157320709.462994.90670@74g2000cwt.googlegrou ps.com...http://blogs.msdn.com/ricom/archive/...10/416151.aspx

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

In article <1157320709.462994.90670@74g2000cwt.googlegroups.c om>,
dagoldman@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.]

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

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

"dan" <dagoldman@yahoo.comwrote in message
news:1157357898.145467.48390@74g2000cwt.googlegrou ps.com...Calling C from VB6 is a nightmare. Avaid at all cost.

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.

It's no small thing you try to do.
I actually envy you for having a complex task at hand.
poor poor you =)
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.
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.
Good Luck
- Michael S

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

In article <MPG.1f6620e6315dff9c98972e@news.sunsite.dk>,
jcoffin@taeus.com says...

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

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

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

dan wrote:

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

"Jerry Coffin" <jcoffin@taeus.comwrote in message
news:MPG.1f662a87283cb45598972f@news.sunsite.dk...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

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

"Jon Davis" <jon@REMOVE.ME.PLEASE.jondavis.netwrote in message
news:eRotQB$zGHA.4932@TK2MSFTNGP02.phx.gbl...You have got to friggin kidding. Only a complete idiot would start a new
project in vb6.

Michael

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

"Michael C" <nospam@nospam.comschrieb: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/>

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

"Herfried K. Wagner [MVP]" <hirf-spam-me-here@gmx.atwrote in message
news:etlMfGH0GHA.3512@TK2MSFTNGP04.phx.gbl...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

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

"Michael C" <nospam@nospam.comwrote in message
news:eBFRlwG0GHA.3568@TK2MSFTNGP03.phx.gbl...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 =)

OldSchoolNotSupportedException
NativeCodeMyAssException
FastForASnailException

Just no name a few =)

Nice Name
- Michael S

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

"Michael S" <no@no.nowrote in message
news:urRtLfH0GHA.3440@TK2MSFTNGP06.phx.gbl...Despite all it's faults VB6 does compile to native code and is very fast.

Michael

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

In article <umzK4TG0GHA.4228@TK2MSFTNGP06.phx.gbl>, no@no.no says...

[ ... ]
Thank you.
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.

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

"Jerry Coffin" <jcoffin@taeus.comwrote in message
news:MPG.1f666b91a2c66110989732@news.sunsite.dk...IMO that is VB6s biggest fault, that it doesn't support large projects very
well.

Michael

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

"dan" <dagoldman@yahoo.comwrote in message
news:1157357898.145467.48390@74g2000cwt.googlegrou ps.com...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(LayoutKind.Sequential), ComVisible(false)]
public class DIBSECTION
{
public SafeNativeMethods.BITMAP dsBm;
public SafeNativeMethods.BITMAPINFOHEADER dsBmih;
[MarshalAs(UnmanagedType.ByValArray, SizeConst=3)]
public int[] dsBitfields;
public IntPtr dshSection;
public int dsOffset;
public DIBSECTION();
}

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

"dan" <dagoldman@yahoo.comwrote in message
news:1157357898.145467.48390@74g2000cwt.googlegrou ps.com...
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.

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

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

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

In article <vvmnf29tahtr98o36q7pjrcf77neu2ak32@4ax.com>, me@privacy.net
(Andy Sinclair) writes:
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.

--
/~\ cgibbs@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!

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

Michael,
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

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

Michael,

In my idea does it needs VB6 forever a special runtime. (As almost all
program languages beside the managed languages needs)

Cor

"Michael C" <nospam@nospam.comschreef in bericht
news:e9hTslH0GHA.5072@TK2MSFTNGP03.phx.gbl...

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

Herfried,

You are so young and now already nostalgie. Try to come over that. I have
seen so many program languages, and beside the so called 4th generation
languages it was everty time better.

Cor

"Herfried K. Wagner [MVP]" <hirf-spam-me-here@gmx.atschreef in bericht
news:etlMfGH0GHA.3512@TK2MSFTNGP04.phx.gbl...

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

"Cor Ligthert [MVP]" <notmyfirstname@planet.nlwrote in message
news:eIICYjK0GHA.3656@TK2MSFTNGP04.phx.gbl...I'm pretty much able to do anything API in VB6 myself. Besides matt curland
(who was on the vb6 team) I was the only person to subclass in vb3 without
an external component. However I would still call vb6 extremely limited in
regards to API because you have to jump through so many hoops to get it to
do even some of the simplest things (such as calling a function that is not
stdcall or using some com compoents such as directshow). The common
techniques for getting around the limitations include assembly code in a
byte array, external type libraries (which isn't coding in vb6 anyway) or
lots of memcopies. Most of the time these special techniques take longer to
do and give a worse result than writing in C, so make it unfeasible for a
professional project. VB really has only has 1 method of interacting with
API which is the declare statement, which only works on standard call
functions in a standard dll. The large majority of the calls to the newer
technologies are via IUknown com interfaces which vb6 has no support for at
all.

Michael

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

"Cor Ligthert [MVP]" <notmyfirstname@planet.nlwrote in message
news:uwGDbkK0GHA.2072@TK2MSFTNGP06.phx.gbl...I'm not quite sure what you're saying. VB6 does have runtime files but these
are just dlls with functions similar to the dlls required for mfc.

Michael

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

In article <aQ6Lg.23547$rP1.11482@news-server.bigpond.net.au>,
CDB4W@NOSPAM.bigpond.com says...

[ ... ]
I started on Windows with version 1.03. Before that, I wrote various
stuff going back as far as FORTRAN on a Control Data mainframe.

[ ... ]
While I've little doubt this is A possible route to success, it seems
fairly clear that there are quite a few others -- at least in part
because there are quite a few different definitions of "success."
The beginning of time stretches back to a LONG ways before the beginning
of Windows programming.
I can probably do more with makefiles than at least 99% of the
programmres on earth -- but I (for one) realize that this is mostly a
matter of knowing a lot of what should really be useless trivia. The
fact of the matter is that we've had the technology to render make 100%
obsolete for decades. Most of what goes into a makefile is basically
just dependencies -- exactly the sort of thing a computer can do far
better than almost any person alive.
From the sound of things, I suppose I'm from a somewhat earlier era. I
certainly hope, however, that the younger generation doesn't consist
exclusively of narrow-minded bigots like the opinion above implies.

I won't try to respond any further on a point-by-point basis -- it
simply reminds me of something I heard somewhere else on Usenet, that
seems to be true of a whole lot of people:

Everything invented before you remember is old and boring.
For a while, anything new is exciting and good.
After that, anything new is wrong and unnatural.

Most of the opinions of VB, Delphi, etc., seem (to me) to follow pretty
directly from the above. According to the old saw, REAL coders can write
FORTRAN in any language -- but that doesn't make it a good thing to do.

I sometimes worry that my opinions of the newer versions of Visual
Studio (for one example) are really from the same source. When I try to
use them, however, I'm quickly convinced otherwise -- I just can't get
them to do what I want. When I ask the advocates how to do the job, the
usual reply is "Oh, you do that by hand..." Even so, I caution almost
anybody reading my earlier posts in this thread to keep in mind that my
opinions may result as much from my age as real shortcomings in some of
the newer products.

--
Later,
Jerry.

The universe is a figment of its own imagination.

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

"Jerry Coffin" <jcoffin@taeus.comwrote in message
news:MPG.1f66cade1269f068989734@news.sunsite.dk...
I was going to reply but then I read this last comment and it says it all. I
am afraid to say that you are a worn out old programmer who has alot to say
but nothing to offer.

So heres my adivce to you. New is not always best. Old is not always bad.
You've got to keep it in perspective. So to go from a C/Unix environment to
a Delphi/Windows envrionment will cost dollars.

And yes, real programmers can write anything in C.
Leslie.

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

In article <5E9Lg.23635$rP1.16995@news-server.bigpond.net.au>,
CDB4W@NOSPAM.bigpond.com says...

[ ... ]
Well, that's certainly possible.
All of that seems to be statements, not advice...
I guess if I'm just a washed up old has-been, at least it's some comfort
that you've apparently classed me along with Ada Lovelace, Alan M.
Turing, John Von Neumann and Admiral Grace Hopper.

As far as writing anything in C, it's always fun to see what it takes.
Just for example, consider something trivial like this:

#include <string>
#include <set>
#include <algorithm>
#include <iostream>

int main() {
std::string line;
std::set<std::stringlines;

while (std::getline(std::cin, line))
lines.insert(line);

std::copy(lines.begin(), lines.end(),
std::ostream_iterator<std::string>(std::cout, "\n"));
return 0;
}

And figure up with it takes to duplicate the functionality in C.

Even when you do manage to do the job, there's the minor problem that C
is so often so much slower. Just for one simple example:

#include <vector>
#include <algorithm>
#include <stdlib.h>
#include <time.h>
#include <windows.h>

int compare(void const *a, void const *b) {
if (*(int *)a *(int *)b)
return -1;
if (*(int *)a == *(int *)b)
return 0;
return 1;
}

const int size = 200000;

typedef unsigned long ul;

int main(void) {
static int array1[size];
static int array2[size];

srand(time(NULL));

for (int i=0; i<size; i++)
array1[i] = rand();

for (int i=0; i<3; i++) {
memcpy(array2, array1, sizeof(array1));
clock_t start = clock();
qsort(array2, size, sizeof(array2[0]), compare);
printf("qsort took: %lu ticks.\n", (ul)(clock()-start));
}

for (int i=0; i<3; i++) {
memcpy(array2, array1, sizeof(array1));
clock_t start = clock();
std::sort(array2, array2+size);
printf("std::sort took: %lu ticks.\n", (ul)(clock()-start));
}
return 0;
}

I've tried this with compilers since before C++ had a standard right up
to Microsoft's latest and greatest 64-bit behemoth -- and no matter what
I've done, std::sort has beaten qsort every time. But I suppose being
concerned with speed, or relying on measurements instead of prejudices
just shows how old and tired I really am. :-)

--
Later,
Jerry.

The universe is a figment of its own imagination.

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

On 05/09/2006 in message <2393.473T1726T12794895@kltpzyxm.invalidCharlie
Gibbs wrote:
This thread is making me nostalgic, I just installed VB6 to remind myself
what is was like :-)

What development tools/IDE do you use for C programming? I have VS6
somewhere, and a Borland tool - version 4.2. Are these older tools
'better' for straight C programming? It seems to me that VS2005 is much
happier with C++ and I never got a grip on that.

--
Jeff Gaines

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

Well I guess there are a lot of "complete idiots" out there who are building
working solutions that run fast and are easy to write.

Don't get me wrong, I would thoroughly hate VB6 if it wasn't still handy.
But it's still a tool that I keep coming back to for quickly prototyping
extremely lightweight and blazing fast solutions without putting any mental
effort into things.

I can't guess that the people who make comments such as yours without
discussing reasoning are anywhere near the "complete idiots" group who are
smart enough not to throw a good tool away when it still does a job well,
despite it being pooh-poohed by its vendor.

Jon

"Michael C" <nospam@nospam.comwrote in message
news:eBFRlwG0GHA.3568@TK2MSFTNGP03.phx.gbl...

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

"Michael C" <nospam@nospam.comwrote in message
news:uWDiSVH0GHA.1040@TK2MSFTNGP06.phx.gbl...LOC in itself is not much of a limiting factor of VB scalability except for
project management. The nature of VB is that it works well scaling out,
using COM and business objects and multiple projects in a consolidated
project group, but COM marshalling comes at a price. I don't know where your
failure points were, but one must make significant architectural and design
considerations with a larger VB project. COM noted, some stuff is best built
in C for optimized algorithms, while the RAD work is best built in RAD
environments. C is not a RAD environment and it is not easy.

As for API usage limitations, I'm not sure that they affect the OP; the
Win32 API is relevant in C because of such things as GUI programming, but
when you're in VB you will not be doing GUI programming with Win32. All that
stuff is wrapped.

Jon

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

Limitations don't necessarily mean inabilities. Michael C has a point, and
the API limitations in VB6 come in the form of difficulty and awkwardness.
Working with function pointers and callbacks with C DLLs is not my idea of a
good time.

Jon

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

"Michael S" <no@no.nowrote in message
news:urRtLfH0GHA.3440@TK2MSFTNGP06.phx.gbl..."The post has an on error resume next and so it shows"; are you referring to
my post? I don't get it.

Jon

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

Michael C has a point

Oh, that was you. =P

Jon

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

"Michael C" <nospam@nospam.comwrote in message
news:e9hTslH0GHA.5072@TK2MSFTNGP03.phx.gbl...Not really.

While the typical access to integers and variants might be called somewhat
native: VB6 can't access COM via IUnknown and virtual method tables, but
must go through IDispatch.

That is not very native.

Going for a select on any ADO source, getting a non-trivial result, and then
in a loop do some word-automation is sure to take its toll. I convert a
small loop of this to Delphi and got like 5 times the speed.

But I've spanked Visual Basic enough for now, and may settle on VB being
fast and that COM sucks. This is what microsoft also think, OrElse they
would not have spent money on .NET.

I've read all your posts in this thread so far, and I think you defend VB
well with good arguments.
But I would like to see you defend IDispatch without resorting to the
Chewbacca-defense =).

Happy Coding
- Michael S

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

"Jon Davis" <jon@REMOVE.ME.PLEASE.jondavis.netwrote in message
news:eYkofvQ0GHA.4116@TK2MSFTNGP02.phx.gbl...I was.
And was having fun at you and gave a pun on what you wrote.

I'm sorry if you got hurt.

You see, instead of actually contribute and forward my own ideas, I tend to
bully, jump on others and ask silly questions, for my own amusement. Stan
and Kyle would call me Cartman, but on Usenet it is simply called trolling.

Anyways, I only troll when there is room for some kind of joke. If not, I
help if I can and learn what I don't know.

I truly believe that you can have fun while talking about something as
square as code and system development. Especially if VB is involved =)

Happy Coding
- Michael S

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

Michael C wrote:The original question was: For writing a complex, professional-quality
Windows desktop GUI application, how much harder is it to use the
Windows C API than C#/.NET.? We're not talking about VS or any other
IDE (not an option for me). This is limited to writing code in an
editor (like vi).

Thanks to everyone who responded. My interpretation so far:

1 response that C API is a BAD IDEA compared with C#
3 responses that C API is OK BUT HARDER
1 response that C API is OK
2 responses that C API is JUST FINE

BAD IDEA - C API really hard, do not do it: 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."

OK BUT HARDER - 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.

OK BUT HARDER - 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. 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."

OK BUT HARDER - C API OK, but harder: Daniel James says "it's not
harder to use the C APIs, but it's certainly much more work than using
one of the higher-level options."

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

JUST FINE - C API is fine: Leslie Milburn says "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. 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."

JUST FINE - C API is fine: Charlie Gibbs says "I ported a 200,000
line curses project from MS-DOS to Windows. 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. I say
go for it. Get a copy of Petzold, start reading, and do lots of
experiments. IMHO it's worth it."

Any other opinions? I'm looking for responses from those who have
written a non-trivial GUI in C API, preferably also have used C#/.NET,
using an ordinary editor, like vi.

Thanks,
Daniel Goldman

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

"Michael S" <no@no.nowrote in message
news:OrXylST0GHA.772@TK2MSFTNGP05.phx.gbl...COM marshalling has nothing to do with code nativity; native code is in the
context of eliminating P-Code translation and/or a script interpreter. C# /
..NET is JIT'd and coinciding with a generic and language-neutral garbage
collector it does take a performance hit, whereas VB6 does not deal with any
of that, the instructions are processor-native.

Jon

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

"Jon Davis" <jon@REMOVE.ME.PLEASE.jondavis.netwrote in message
news:%23d$gAXV0GHA.4976@TK2MSFTNGP02.phx.gbl...While I think I am right on below; I won't bet money on it, so please prove
me wrong.

Try build a COM-object in C++ or Delphi and run it in VB6 without
implementing IDispatch.

Try build a COM-object that does implement IDispatch and then a method that
returns a IDispatch, where one method doesn't have a dispid. Will VB6 ignore
the count and treat all the rest of the methods correctly, or give call to
dispid of -1 with the wrong methods being called?

Why are stdcall-, cdecl- and even better: register- calling-convention being
used? Are there anything wrong with boxing values into a array of variants
before each call?

And talking about each call. What is there for the 'native compiler' to
optimize? Variants? Especially when they can reference Object, Nothing,
Null, Empty or Error.

I throw a NativeMyAssException

Happy Coding
- Michael S

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

"Michael S" <no@no.nowrote in message
news:ObFxroV0GHA.4312@TK2MSFTNGP02.phx.gbl...As I said, COM is not relevant to the topic of whether code is native. The
COM implementation is implemented even if it is not optimized, but the code
itself is native to the microprocessor (is not script and is not P-Code).

A proper comparison for the OP is to perform common routines within a
standalone EXE and compare the performance between C#, C, and VB6. The VB6
solution may be somewhat slower than C but it will likely severely
outperform C#, esp. at startup which was a concern in the OP. Hence, a
reasonable compromise of both ease and performance.

Jon

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

Michael S wrote:
Your argument is akin to saying that a whale isn't a mammal because
it doesn't have legs. On land, not having legs is not so great, but
it doesn't have anything to do with being a warm-blooded, milk-
producing vertebrate.

Native = platform-specific. Some languages, like Java, run using
interpreted code. This is non-native. Other languages, such as
C/C++, compile to machine code and run directly on the processor
without any kind of intermediate interpreter. This is native.

It is quite possible for code to be native and still do things
inefficiently. In VB's case, it uses IDispatch since it's weakly
typed. Is that the most efficient way to use COM? No, not really.
But, that doesn't make it non-native any more than a lack of sight
makes a bat a non-mammal.

I hope that makes sense.

David