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

[Jon Davis]

"Michael C" <no****@nospam.comwrote in message
news:uu**************@TK2MSFTNGP03.phx.gbl...

"Jon Davis" <jo*@REMOVE.ME.PLEASE.jondavis.netwrote in message
news:uV**************@TK2MSFTNGP03.phx.gbl...

>Keep also in mind, Microsoft invented COM, and Microsoft invented Visual
Basic 4.0 Control Creation Edition to *implement* their COM invention in
a manner that both consistent and easy to use.

That's the ironic thing, VB is *the* com language but doesn't do it very
well at all.

It does it perfectly. It only asks the other players to do it well, too.
Unlike Internet Explorer, for instance, it is unforgiving if you expect it
to work with sloppy frameworks.

Don't blame VB6 for DirectShow not being supported in VB6. Blame DirectShow.
Same for IMAPI and Windows Image Acquisition. It's not that they don't
target VB6, it's that they only support a small subset of COM. Literally,
they are NOT automation compliant!! But these are not typically libraries
that target VB6 developers anyway, otherwise the VB6 crowd would have made a
lot more noise.

However, you *can* build solutions for DirectShow, et al, in VB6. You will
just need to build simple stubs for the API in C/C++ to expose the API in an
automation compliant manner.

http://www.gdcl.co.uk/vb.htm
Jon

[Michael C]

"Jon Davis" <jo*@REMOVE.ME.PLEASE.jondavis.netwrote in message
news:%2****************@TK2MSFTNGP06.phx.gbl...

It does it perfectly.

That is definately a matter of opinion.

It only asks the other players to do it well, too.

That's a big ask, no that is a *HUGE* ask. Making a component vb6 friendly
would easily take as long as developing the component to start with.

Don't blame VB6 for DirectShow not being supported in VB6. Blame
DirectShow. Same for IMAPI and Windows Image Acquisition. It's not that
they don't target VB6, it's that they only support a small subset of COM.
Literally, they are NOT automation compliant!!

In your last post you said all a component needs to do is support IUknown.
Directshow supports IUknown.

But these are not typically libraries that target VB6 developers anyway,
otherwise the VB6 crowd would have made a lot more noise.

They usually buy a third party solution.

However, you *can* build solutions for DirectShow, et al, in VB6. You will
just need to build simple stubs for the API in C/C++ to expose the API in
an automation compliant manner.

That's not building the solution in vb6, that's building it in C++.

Michael

[Michael C]

"Jon Davis" <jo*@REMOVE.ME.PLEASE.jondavis.netwrote in message
news:%2****************@TK2MSFTNGP06.phx.gbl...

That said, you listed three APIs that do not relate to the target market
for VB6,

That is *highly* debatable. Questions about directshow, cd burning and wia
are quite common in the newsgroups. Third party solutions or free code for
any of these are also very common.

including the OP. As for "shell functions", if you mean Win32 calls VB6
can do it without issue.

No i don't mean the win32 api, I'm talking about all the shell com objects.
Take IShellFolder as an example.

I have worked with VB4-6 for nearly a decade, I have never seen a "*huge*
number of interfaces" inaccessible to VB4-6.

Just because you haven't seen them doesn't mean they don't exist. There are
literally thousands of com interfaces implemented by various windows
functionality that vb6 cannot use (DirectShow on it's own has 500 or so and
it's only 1 part of DirectX). I never realised how many there were until I
started implementing them in C#.

Rather, I am aware of a *huge* number of interfaces that are required to
be implemented in order to have properly implemented ActiveX control, as
opposed to just an IUnknown-exposed COM object, and as such I have seen
several interfaces that were inaccessible to VB4-6 but were later on
cleaned up to Microsoft ActiveX conformance standards. Much of the DirectX
API was among them.

Generally when MS do this it is a fairly cut down version. The WIA component
was pretty good but only worked on winxp sp1. The directshow component was
woeful.

I'm not sure what you're talking about. You can use polymorphic interfaces
in VB6 and advise / unadvise the interface to a callback function via COM.

Take the ISampleGrabberCB interface as an example. It works fairly simply by
calling a method in your class every time a frame is received and passes a
pointer to the bitmap data. You can't implement this callback in vb6 because
it can't implement a pure IUknown interface.

You can also use this method to create event sinks with COM objects that
implement IConnectionPoint. I think we discussed homework...?

The other thing that is *really* sucky about vb6s implementation of com is
the 'weight' of each object. You can't create too many objects because each
object takes too much memory and takes too long to create and destroy.
10,000 objects is not really usuable. That might sound like a lot but it's
only a 100x100 grid.

Michael

[Jon Davis]

"Michael C" <no****@nospam.comwrote in message
news:O9**************@TK2MSFTNGP03.phx.gbl...

"Jon Davis" <jo*@REMOVE.ME.PLEASE.jondavis.netwrote in message
news:%2****************@TK2MSFTNGP06.phx.gbl...

>It does it perfectly.

That is definately a matter of opinion.

>It only asks the other players to do it well, too.

That's a big ask, no that is a *HUGE* ask.

Right. Kind of like the whole notion of refusing to parse sloppy
non-conformant XML is a *HUGE* ask...

I think you're spoiled by sloppiness. C, C++, Delphi, et al, are good at
enabling sloppy people to stay sloppy by implementing the bare minimums.

>However, you *can* build solutions for DirectShow, et al, in VB6. You
will just need to build simple stubs for the API in C/C++ to expose the
API in an automation compliant manner.

That's not building the solution in vb6, that's building it in C++.

No, it's C++ to fix the mistakes Microsoft made in DirectShow so that they
can go back to RAD development in Visual Basic.

Jon

[Jon Davis]

Michael, I think you're taking some really niche programming principles and
associating their inapplicability to the wrong programming model. The OP'er
had a simple GUI app with a dashboard and some menus and some processes. The
GUI portion does not likely need DirectShow. It does not likely need
ISampleGrabberCB. And a 100x100 grid is 1,000, which is a cakewalk for VB6.
Actually, VB6 can scale to several hundred thousand objects. But it doesn't
sound like the OP needs it.

This is a stupid debate, we're comparing apples and oranges here. COM was
*NOT* at issue here, but VB6 does support COM (to a very large extent) and
where VB6 falls short Win32 function pointers and, yes, COM-exposed
C/C++/Delphi components can fill in the gaps. But VB6 has a lot of merits.
Yes, it does trade some power for its ease of use, but that doesn't make it
a toy. It's a RAD tool, still used by many businesses and enterprises.

I think you need to grow up and quit trying to show off your ego.

Jon

[Ben Voigt]

"Michael C" <no****@nospam.comwrote in message
news:%2****************@TK2MSFTNGP06.phx.gbl...

"Ben Voigt" <rb*@nospam.nospamwrote in message
news:%2****************@TK2MSFTNGP06.phx.gbl...

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

IUnknown and IDispatch COM interfaces are VB6's homeland

You'd think so :-) Unless a component is specifically written with vb6 in
mind there's a very good chance it won't work. Does vb6 work with plain
IUknown interfaces at all? You certainly can't use all the DirectShow
interfaces for example in vb6.

Having not done DirectShow, I still think that VB6 worked with IUnknown just
fine. I did write a bunch of COM objects in C++ for consumption in VB6.
Even IDispatch wasn't that difficult, there was a default implementation for
every function if you loaded the typelib. But IDispatch was a convenience,
not a requirement.

Problem was, the VB6 built-in class framework had a horrible inheritance
model, so programmers got used to late binding for just about everything.
Example: Form and PictureBox didn't have any common ancestor I don't think,
so the Parent property of every control had to return "Object" (=
IDispatch). IUnknown can't do late binding. Not in any language.
IDispatch is required for that. And, most programmers didn't go to the
trouble of declaring every variable with the exact type, because you could
just pass the type id as a string to CreateObject and go.... at least with
automation compatible objects (dispinterface or dual). With IUnknown
objects, you needed to import the type library, because that's the only
information the compiler had.

Also had a tendency to limit you to a particular version of the library in a
way that COM shouldn't have... but that was VB calling coclasses types and
hiding the interfaces. But you could still use the interfaces even though
they didn't show up in the Object Browser (OLEView is great). It's not
obvious how to write early-bound VB code for polymorphic COM objects... but
it is possible.

[Michael C]

"Jon Davis" <jo*@REMOVE.ME.PLEASE.jondavis.netwrote in message
news:O0*************@TK2MSFTNGP05.phx.gbl...

Right. Kind of like the whole notion of refusing to parse sloppy
non-conformant XML is a *HUGE* ask...

Nothing like it.

I think you're spoiled by sloppiness. C, C++, Delphi, et al, are good at
enabling sloppy people to stay sloppy by implementing the bare minimums.

I don't think you really understand just how much work is involved in making
these components vb6 freindly.

No, it's C++ to fix the mistakes Microsoft made in DirectShow so that they
can go back to RAD development in Visual Basic.

No, it's developing in C++. This does NOT mean vb6 can access directshow,
C++ is doing it.

>
Jon

[Michael C]

"Jon Davis" <jo*@REMOVE.ME.PLEASE.jondavis.netwrote in message
news:%2****************@TK2MSFTNGP04.phx.gbl...

Michael, I think you're taking some really niche programming principles
and associating their inapplicability to the wrong programming model.

Niche programming!?!?! You've gotta be kidding, just doing something like
drag/drop requires access to implementing all sorts of interfaces if done
properly (if you want the source to be created when you drop for example).
Accessing that thumbs.db file again requires all sorts of interfaces.

The OP'er had a simple GUI app with a dashboard and some menus and some
processes.

I'm talking more generally.

The GUI portion does not likely need DirectShow.

Likely it doesn't.

And a 100x100 grid is 1,000, which is a cakewalk for VB6.

Really? I was presuming I was talking to someone who knew how to add :-)

Actually, VB6 can scale to several hundred thousand objects. But it
doesn't sound like the OP needs it.

It can but it will be very slow. 100,000 objects is 10meg+ before the
objects store anything (each object takes approx 100 bytes). Creating and
destroying those objects will be slow.

This is a stupid debate, we're comparing apples and oranges here. COM was
*NOT* at issue here, but VB6 does support COM (to a very large extent) and
where VB6 falls short Win32 function pointers and, yes, COM-exposed
C/C++/Delphi components can fill in the gaps.

Sure it can but that is NOT accessing these components in vb6. It doesn't
somehow mean vb6 isn't limited.

But VB6 has a lot of merits.

It sure does.

Yes, it does trade some power for its ease of use, but that doesn't make
it a toy. It's a RAD tool, still used by many businesses and enterprises.

All I said was vb6 was very limited in it's support for com. I think you
just don't realise how big a limitation this is because you haven't
progressed beyond simple database apps. Netmeeting has 21 interfaces, all
inaccessible to vb6, the shell has 120, direct show approx 500, all
inaccessible to vb6. VB6 only supports a very limited set of COM interfaces
that need to be specifically designed for it.

I think you need to grow up and quit trying to show off your ego.

It's funny *you* should say that. The fact is I am right on this issue and
no amount of pedalling on your part is going to change that. VB6 does
support a very limited set of com components. Just because you are unaware
of these components does not mean they do not exist. I'm not sure how else
to explain it to you.

Michael

[Jon Davis]

Drag-and-drop is natively supported in VB6. I haven't met anyone who cares
about thumbs.db.

>The OP'er had a simple GUI app with a dashboard and some menus and some
processes.

I'm talking more generally.

No, you're spewing lame specific examples of where VB6 fell short.
*Generally* VB6 has a very broad reach for big projects such as the OP.
*Specifically*, there are indeed a few cases where VB6 will not suffice on
its own.

>Yes, it does trade some power for its ease of use, but that doesn't make
it a toy. It's a RAD tool, still used by many businesses and enterprises.

All I said was vb6 was very limited in it's support for com.

No, it isn't "all you said". You've whined on and on about DirectShow
support and now thumbs.db. You've paralyzed the productivity of the OP's
quest for answers by making outlandish claims about how utterly shameful one
suggestion ("consider VB6 as an alternative to your project") was.

For the record, I think most people would be foolish to implement a project
these days in VB6, but not for technical nor political reasons but only
because it is no longer supported by its vendor.

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.

For everyone's sake, I will plonk to bring this to an end.

Jon

[Michael C]

"Jon Davis" <jo*@REMOVE.ME.PLEASE.jondavis.netwrote in message
news:%2***************@TK2MSFTNGP06.phx.gbl...

No, you're spewing lame specific examples of where VB6 fell short.

Not really sure what you wanted me to do, you claimed there was little in
the way of com objects that vb6 does support. What am I supossed to do?

*Generally* VB6 has a very broad reach for big projects such as the OP.
*Specifically*, there are indeed a few cases where VB6 will not suffice on
its own.

This is what you keep saying simply because *you* don't know how large this
area is. As far as com goes these cases are *huge*. Most of the
functionality in windows implemented in the last however many years (since
2000?) is mostly com and all inaccessible to THE supposed com language. I
was having a look at GDI plus today and was suprised it was all plain apis,
but wait! I have to pass an IStream in to to load a bitmap.

>All I said was vb6 was very limited in it's support for com.

No, it isn't "all you said". You've whined on and on about DirectShow
support and now thumbs.db.

Both examples of com objects that vb6 doesn't support.

You've paralyzed the productivity of the OP's quest for answers by making
outlandish claims about how utterly shameful one suggestion ("consider VB6
as an alternative to your project") was.

You're the one who couldn't leave it at that. The suggestion was pretty
stupid and should be pointed out. Many people take the advice they read in
these groups.

For the record, I think most people would be foolish to implement a
project these days in VB6, but not for technical nor political reasons but
only because it is no longer supported by its vendor.

There's big technical reasons why VB shouldn't be used for new projects.
Mainly it's support for large projects and even small teams.

For everyone's sake, I will plonk to bring this to an end.

That's as close as you get in a newsgroup to someone admitting they were
wrong :-)

Michael

[gerry]

"Michael C" <no****@nospam.comwrote in message
news:eW**************@TK2MSFTNGP03.phx.gbl...

"Jon Davis" <jo*@REMOVE.ME.PLEASE.jondavis.netwrote in message
news:%2****************@TK2MSFTNGP04.phx.gbl...

Michael, I think you're taking some really niche programming principles
and associating their inapplicability to the wrong programming model.

....

And a 100x100 grid is 1,000, which is a cakewalk for VB6.

Really? I was presuming I was talking to someone who knew how to add :-)

not sure about addition but his multiplications is definitely supect.

100,000 objects is 10meg+ before the objects store anything (each object

takes approx 100 bytes).

and it seems yours isn't much better.

getting back to basics :

100x100 = 10,000
10,000x100 = 1,000,000 = 1Mb

sorry , i couldn't resist ;-)

[Michael C]

"gerry" <ge**@nospam.nospamwrote in message
news:OQ**************@TK2MSFTNGP03.phx.gbl...

not sure about addition but his multiplications is definitely supect.

>100,000 objects is 10meg+ before the objects store anything (each object

takes approx 100 bytes).

and it seems yours isn't much better.

getting back to basics :

100x100 = 10,000
10,000x100 = 1,000,000 = 1Mb

sorry , i couldn't resist ;-)

Actually it you who is wrong :-) Check again.

Michael

[David Jones]

Michael C wrote:

"gerry" <ge**@nospam.nospamwrote in message
news:OQ**************@TK2MSFTNGP03.phx.gbl...

>>not sure about addition but his multiplications is definitely supect.

>>>100,000 objects is 10meg+ before the objects store anything (each object

takes approx 100 bytes).

and it seems yours isn't much better.

getting back to basics :

100x100 = 10,000
10,000x100 = 1,000,000 = 1Mb

sorry , i couldn't resist ;-)

Actually it you who is wrong :-) Check again.

For those who can't see how he is wrong (which was me for a while
there!), it was in the fact that Michael C never said that 100x100
is 100,000. The two numbers were not only in separate paragraphs,
but were talking about separate subjects. The 100,000 was a response
to "Actually, VB6 can scale to several hundred thousand objects",
in which case the fact that 100x100 != 100,000 is kinda irrelevant.

It helps to read before you snip. :)

David

[Rastko Soskic]

I apologize for not reading all of the replies,
but I need to ask if anyone mentioned BCB (Borland C++ Builder)
I think BCB is excellent intermediary between RAD capabilities of .NET
and fast, native Win API app. Furthermore, you shouldn't have so much
trouble (but you'll certainly do have trouble :-) ) using existing C
libraries.

Once more, I apologize if anyone mentioned BCB already, but I couldn't
read so many replies :-)