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

  • Thread starter Thread starter dan
  • Start date Start date
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
 
Michael S said:
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
Click to expand...

"The post has an on error resume next and so it shows"; are you referring to
my post? I don't get it.

Jon
 
Michael C said:
Despite all it's faults VB6 does compile to native code and is very fast.

Michael
Click to expand...

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
 
Jon Davis said:
"The post has an on error resume next and so it shows"; are you referring
to my post? I don't get it.

Jon
Click to expand...

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
 
Michael said:
IMO that is VB6s biggest fault, that it doesn't support large projects very
well.

Michael
Click to expand...

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
 
Michael S said:
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.
Click to expand...

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
 
Jon Davis said:
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
Click to expand...

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
 
Michael S said:
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.
Click to expand...

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
 
Michael said:
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
Click to expand...

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
 
Jon Davis said:
As I said, COM is not relevant to the topic of whether code is native.
Click to expand...

Not relevant? What do people do with VB6? String-theory?
A proper comparison for the OP is to perform common routines..
Click to expand...

Yes, and the world of VB is reading data from a database and make for some
GUI. How do you do that with not buying third part components? Remember
flexGrid? F00k, VB can't even do what it is supposed to do.

On a side-note, .NET framework can't zip. If you want to use the most common
compression-format known to man (and women (from now on I want you to call
me Loretta)), you have to go J# and venture deep into the java.lang
namespace. Guess no world is perfect. *s*
Jon
Click to expand...
- Michael S
 
Between iterations of immature and egotistical trolling, I suggest that you
go look up the word "native" in the context of software programming and use
your findings as qualifications of your banterings.

Jon
 
Native = platform-specific.
Click to expand...

Really? Is that the N in LINQ?
Is that what the n in ngen.exe means?

Sorry for being an immature and a egocentric troll (as jon call me): But
since when did 'native' mean 'compile for cpu'?

Happy Pondering
- Michael S
 
Native = platform-specific. Some languages, like Java, run using
interpreted code.
Click to expand...

Very little time is spent running Java in interpreted mode. Like C#,
Java is almost always JIT-compiled - but Sun's JVM/JIT (the boundary is
unclear to me in places) sometimes interprets code rather than JITting
it for startup speed reasons, and the JIT can re-optimise based on new
information - .NET code is always JITted once and only once.
 
dan said:
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).
Click to expand...

See, thisis the crux of your question. Basically, its stupid. You cannot
compare C# vs C and additionally specify that you are writing a GUI in vi.

Dont use VI. Use an IDE. If you are using Vi then writing a gUI app is going
to be hard no matter what you do.
 
dan said:
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.
Click to expand...

I suspect looking for people's opinions here is not the way to go. Different
apps require different languages or different combinations of languages. I'm
fairly confidant that doing my previous project in C++ would have been a
really bad idea and caused it to fail (due to the amount of work required vs
the number of programmers). On the other hand writing WinZip in C# would
probably cause it to fail because no-one would download 30 meg. I think you
need to consider 1) How many users there will be 2) What is the budget 3)
How complicated the program is 4) What it needs to do 5) How it's
distributed. The more users there are and the bigger the budget then the
more I'd tend towards C++.

Michael
 
Jon Skeet said:
Very little time is spent running Java in interpreted mode. Like C#,
Java is almost always JIT-compiled - but Sun's JVM/JIT (the boundary is
unclear to me in places) sometimes interprets code rather than JITting
it for startup speed reasons, and the JIT can re-optimise based on new
information - .NET code is always JITted once and only once.
Click to expand...

Thanks for coming to the rescue.

I did a search on wikipedia and there are plenty on the subject. Not much on
computing however.
http://en.wikipedia.org/wiki/Native

And while going for native mode there is even less. Quite a swallow watery
description.
http://en.wikipedia.org/wiki/Native_mode

But I think that when we talk about native, we don't mean variants.
And I think the OP would hardly call Java and .NET native.

One thing is for sure, there is not one gaming-company who writes a
3d-engine in VB, while there are no major business applications written in
asm. The only thing I'm sure of is that Visual Basic Sucks So Hard It Bends
Light!

All this while a J2EE can suck all your money from a project if you make one
mistake. =)

Agreed?
- Michael S
 
Dan said:
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.
Click to expand...

Let me expand just a little on what I said before ...

You, as I understand it, have a big C console (curses) program that you want
to convert to have a Windows GUI. You know C well, but not Windows and not
C++ (or C#). You are only interested in Windows, not (say) linux or Mac.
Yes?

You have any number of options, but here are some further comments on some
of the options that have already been mentioned:

1. Stick to C. Use the Win32 API.
This will work, but it is a LOT of work partly because you will have
to learn to use the API, and because the API is low-level. I would
not choose to do it this way.

If you want to learn more about just how MUCH work is involved I
suggest you take a look at /Programming Window/ by Charles Petzold
-- I believe Petzold uses C++ in the latest edition, so try to find
an earlier one.

2. Use C++ and MFC
This will work, but will require you to learn C++ and MFC. The learning
curve for MFC is MUCH less than for the Win32 API (and the API is
still directly accessible to your code if you ever need to go beyond
the operations that MFC supports). Learning C++ is an additional
learning curve but one that I would say was well worthwhile.
Unfortunately MFC is not a particularly good example of OO design
in C++ (it had to work with Microsoft's old 16-bit C++ compiler, which
fell a long way short of the language standard we have today), but the
good news is that that means it only uses a subset of the language
(and that cuts down the learning curve).
A big advantage of this route is that the non-UI parts of your existing
C code can simply be compiled as they are and linked to the C++ GUI.

3. Use C++ but not MFC
MFC is not the only application framework that can greatly accelerate
the process of developing GUI code for Windows. A couple of others
that you should be aware of are Qt (http://www.trolltech.com) and
wxWidgets (http://www.wxWidgets.org). These are also both C++
frameworks but have the advantage that they do not only target Windows,
so you can get linux, Mac, etc. versions of your application for little
extra work. Qt is commercial Open Source and is quite expensive for non
GPL projects, but wxWidgets is free Open Source

4. Use .NET
.NET does not support C. It does support C++, and the syntax of C++
is almost the same as that of C (there are a few subtle differences
which may not affect you at all). Your back-end C code can probably
be recompiled as C++ to generate CLI runtime code for the .NET
environment. If you can do that then you can write a GUI in whatever
.NET language takes your fancy. I would strongly suggest that C++/CLI
is better and more powerful than any other ... but as you already know
C# and profess to dislike C++ you can use that.

I, myself, would chose route (3).

(1) is too much work - about 5 times more that any of the others.
(2) ties you unnecessarily to Windows.
(4) suffers from being overly complex in that it introduces a dependency
on a runtime environment without good reason, and that it requires two
separate (if similar) programming languages to be used, which
will increase the overall cost of future support.

BTW: Have you read /Working Effectively with Legacy Code/ by Michael
Feathers. It has a few interesting things to say about this sort of project.

Now, a word about tools. You seem very hung up on the use of vi. Vi is a
nice little text editor, but it is only a noce little text editor. The sort
of modern GUI library (be it MFC, WinForms or whatever) is designed to be
used with various tools -- form designers, resource editors, etc. -- that
may exist only in integrated environments intended for use with those tools.
If you eschew the use of those tools you are automatically making the whole
job of GUI design/implementation several time more work than it needs to be.
Not as much work as just using the Win32 API, but getting that way. By all
means use vi as an editor, but *DO* use the IDEs' tools as well.

I have written applications using vi, way back when there was no
alternative, and I don't look back on those days with any fondness.

Cheers,
Daniel.
 
Michael said:
Really? Is that the N in LINQ?
Click to expand...

You mean Language INtegrated Query? What does that have to do with
native code?

Is that what the n in ngen.exe means?
Click to expand...

The Native Image Generator?

http://msdn2.microsoft.com/en-us/library/6t9t5wcf.aspx

"Ngen.exe creates native images, which are files containing compiled
processor-specific machine code, and installs them into the native
image cache on the local computer. The runtime can use native images
from the cache instead using the just-in-time (JIT) compiler to
compile the original assembly."

So, here, Microsoft agrees with us that native = platform-specific.

Sorry for being an immature and a egocentric troll (as jon call me): But
since when did 'native' mean 'compile for cpu'?
Click to expand...

Since as long as I've heard the term, probably since the introduction
of interpreted languages.

David
 
Back
Top