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

  • Thread starter Thread starter dan
  • Start date Start date
Cor Ligthert said:
There is with Net one big difference in my opinion with other program
language. The runtime (you see without an r) is bound to the Operatings
System, not to one program language.
Click to expand...

That's nonsense. Yes, the CLR can be targeted by multiple languages, but it
isn't OS specific (see mono). Yes, the JVM isn't OS specific, but there are
languages other than Java than can be compiled to Java bytecode (not as
many as with .NET because sun deliberately crippled it by leaving out some
of the operations that you'd need for pointer manipulations ... but I have
seen Ada compiled to bytecode, for example).

For that matter, Pascal wasn't the only language that could be compiled to
P-Code for the UCSD P-System, and that ran on many platforms (though that
didn't JIT).

I don't see any real difference here at all. Neither .NET nor the JVM is at
all special or extraordinary.

Neither of them is native: CLI code and bytecode are both "interpreted"
code because they have to be either interpreted or JITted in order to run.
Though what comes out of the JITter is native, but that's more-or-less the
definition of what a JITter does. That code output by the JITter is native
in the sense of being specific to the CPU on which it runs, but not
necessarily in the sense of being specific to the OS on which it runs,
because the JITter will link it with a runtime that can (and ideally
probably will) abstract away any specificity.

Cheers,
Daniel.
 
In article news: said:
I'll think about 3) more. I studied C++ a while back. Unfortunately, I
did not like C++. Basically I thought it was bloated and complex. But I
could use a subset. You're right, ...
Click to expand...

There is complexity in C++ -- and some of it is unfortunate (and some of
that is only there because of a need/desire to maintain as much
compatibility as possible with C) -- but you don't need to see that. You
don't need to use the bloated/complex parts of C++.

It can be a very clean and powerful language, and if you like C# I would
expect you to like the clean and powerful side of C++ even more.

Here's another book recommendation - if you want to see C++ taught without
the cruft take a look at /Accelerated C++/ by Andy Koenig and Barbara Moo,
or at /You Can Program in C++/ by Francis Glassborow. I think you'll find
the experience eye-opening.
I WOULD like to target any platform, using qt or
wxWidgets, not just windows. I originally tried Java for that reason,
and really liked Java. But it was missing some capabilities related to
structures and passing arguments I needed to reuse the C code. And I
did not think it a good idea to ditch the C code and convert everything
to Java.
Click to expand...

Java could call your C code using the Java Native Interface (JNI) ... but
that's not as straightforward as calling your C code from C++. There is a
good deal of One-True-Wayism at Sun about Java, and they don't make it as
easy as it could be to integrate with legacy code (they want you to
(re)write everything in Java, because Java is portable, right?).

Java *is* very portable -- there are JVMs on just about everything -- so
Java can be a good choice of language if portability is your main concern
(it's more portable than .NET), but it's nit ideally suited for integration
with legacy code and I wouldn't suggest it in your case.
I'm not really hung up on vi. I just can't use a form designer to do
this application. ... I'm pretty sure a IDE-type form designer is pretty
useless.
Click to expand...

There's more to an IDE than form design.

In any case, an IDE's form designer doesn't just generate one form, it can
generate as many as you need. Even if the combinations of controls that you
need to present are SO variable that it really does make sense to create
the controls dynamically from some metadata stored with your database that
doesn't rule out the use of a form designer to lay out the basic, invariant
controls (even if it's only an OK button) ... which can still make your job
easier.

You don't *have* to use a form designer, even if you do use an IDE. I just
wouldn't want you to discount a potentially useful set of tools (which is
what an IDE is) just because you're "pretty sure" that one of them will be
"pretty useless".
Yes, it's a lot of work, and much more difficult than just plopping an
element onto a design screen. But once the code is written, I can
quickly write a new application by just making some new arrays in the
header files!
Click to expand...

It does sound like you have a good case for filling your property-sheets
dynamically. That still doesn't mean you can't use a form designer to
construct the, or that you can't use an IDE. It's your choice, though.

Adding controls dynamically, as you describe, is much easier in MFC or Qt
or wxWidgets (or just about any framework you care to name) than it is
using the bare Win32 API. The framework will take care of a lot of
boilerplate code for you.

Cheers,
Daniel.
 
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
Click to expand...


With all of the C code you need, I think you should really consider C++.
If you keep things simple, C++ works really well.

1. C++ builder. It's based on delphi but you write C++ so you get the
VCL goodness but can resuse all of your C code. everything in one exe

2. WTL/Visual studio 2005. Windows template library. MFC like template
library that doesn't have any runtime and produces very lean apps.
Makes it very easy to create views, dialogs, subclass controls, etc.
This stuff is really ugly in straight C win32.

3. C++/CLI use managed C++ to write your .net app and you can
interface directly with your unmanage C Code.
 
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.
Click to expand...

I wouldn't choose VB6 for technical reasons. It's awful.
 
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.
Click to expand...
Delphi is a nice option but if he is going to learn a new language, it
might as well be C++/C++ Builder where he gets the Delphi/VCL RAD
development but can still use all of his C code as is.
 
Jon,

I stop the discussion as I have read we are busy in a troll thread. I agree
with that, maybe another time.

Cor
 
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.
Click to expand...
IUnknown and IDispatch COM interfaces are VB6's homeland
 
Ben Voigt said:
IUnknown and IDispatch COM interfaces are VB6's homeland
Click to expand...

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.

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

A component does not need to be "specifically written with vb6 in mind", it
just needs to FULLY implement IUnknown. The required interactions of
IUnknown (QueryInterface, AddRef, and Release) are hidden to the developer,
but VB6 performs these interactions with the component through the VBVM.
This simplifies development with COM for many developers, but is most
certainly a full implementation of COM, if fragile in not allowing one to
leave a full COM implementation half-baked as is commonplace with
practically every Delphi component I have ever touched.

As for implementing IUnknown in VB6 components themselves, VB6 components
are first class COM objects. All COM objects must implement IUnknown, by the
definition of COM.

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

Jon
 
assuming the programmer is coding into an editor? Or any other
comments.
Click to expand...

If you coded using something like Zeus for Windows:

http://www.zeusedit.com/features.html

you get power of an IDE with the feel of an editor (ie fast
file load, fast keyboard response etc).[/QUOTE]

Does anyone still make a plain old symbolic debugger? In other
words, use your editor of choice, compile and link with special
options to include the symbol table, and run the program under
a separate monitor that displays code and variables, single
steps, sets breakpoints, etc. I had a wonderful facility that
came with my MS-DOS Lattice C compiler, and I wish I had it
for my newer compilers.
 
Jon Davis said:
A component does not need to be "specifically written with vb6 in mind",
Click to expand...

VB6 supports only a subset of the possible data types, so unless the
developer took this into account it's likely the component won't work.
it just needs to FULLY implement IUnknown.
Click to expand...

It needs to do more than implement IUnkown. Many many many interfaces that
implement just IUknown are inaccessible to VB6. This applies to a *huge*
number of interfaces that make certain windows functionality available. Eg
DirectShow, Windows Image Aquisition, IMAPI (for CD burning), all sorts of
shell functions etc.
The required interactions of IUnknown (QueryInterface, AddRef, and
Release) are hidden to the developer, but VB6 performs these interactions
with the component through the VBVM. This simplifies development with COM
for many developers, but is most certainly a full implementation of COM,
if fragile in not allowing one to leave a full COM implementation
half-baked as is commonplace with practically every Delphi component I
have ever touched.
Click to expand...

VB6 is similarly limited in the com components it can author, although this
is usually not a problem unless you need to implement a callback.
 
Jon Davis said:
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.
Click to expand...

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

Michael
 
Charlie Gibbs said:
Does anyone still make a plain old symbolic debugger? In other
words, use your editor of choice, compile and link with special
options to include the symbol table, and run the program under
a separate monitor that displays code and variables, single
steps, sets breakpoints, etc. I had a wonderful facility that
came with my MS-DOS Lattice C compiler, and I wish I had it
for my newer compilers.
Click to expand...

Well, for .NET you can use cordbg. I suspect some of the tools on the
following page might be helpful if you're running under Windows:

http://www.microsoft.com/whdc/devtools/debugging/default.mspx
 
[ ... ]
Does anyone still make a plain old symbolic debugger?
Click to expand...

Neither as old nor as plain as Lattice's debugger, but Microsoft
inlcudes Windbg as part of the Windows SDK. If you really want something
like a command line-oriented debugger, the kernel debugger may be more
to your liking.
 
Michael C said:
VB6 supports only a subset of the possible data types, so unless the
developer took this into account it's likely the component won't work.


It needs to do more than implement IUnkown. Many many many interfaces that
implement just IUknown are inaccessible to VB6. This applies to a *huge*
number of interfaces that make certain windows functionality available. Eg
DirectShow, Windows Image Aquisition, IMAPI (for CD burning), all sorts of
shell functions etc.
Click to expand...

Of course. VB6 is indeed picky; fully implementing IUnknown is not the
[sole] cause of these interfaces not working. To be fair VB6 only officially
supports ActiveX, which has more stringent requirements than COM alone,
although many, many COM objects that are not ActiveX components or controls
are also usable in VB6.

That said, you listed three APIs that do not relate to the target market for
VB6, including the OP. As for "shell functions", if you mean Win32 calls VB6
can do it without issue. I have worked with VB4-6 for nearly a decade, I
have never seen a "*huge* number of interfaces" inaccessible to VB4-6.
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.
VB6 is similarly limited in the com components it can author, although
this is usually not a problem unless you need to implement a callback.
Click to expand...

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.
You can also use this method to create event sinks with COM objects that
implement IConnectionPoint. I think we discussed homework...?

Jon
 
Michael C said:
That's the ironic thing, VB is *the* com language but doesn't do it very
well at all.
Click to expand...

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

That is definately a matter of opinion.
It only asks the other players to do it well, too.
Click to expand...

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!!
Click to expand...

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

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

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

Michael
 
Back
Top