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

[Jerry Coffin]

[ ... ]

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.

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.

 

[Ian Semmel]

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

 

[Michael S]

[ ... ]

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.

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.

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

 

[Michael C]

Are you just trying to build a class library? If so, is performance more
of an issue than ease? It sounds like you already made your decision; C#
is easy but it is not fast enough.

If you're building an application with a GUI or with GUI components, you
should consider VB6. It's "old school" but compiles to native code and is
quite fast. You won't be able to optimize it quite as fast as C but you
can interoperate with the Win32 API and the compromise of ease and
performance is there. The down side is that it is an older tool. Then
again, so is the C language.

You have got to friggin kidding. Only a complete idiot would start a new
project in vb6.

Michael

 

[Herfried K. Wagner [MVP]]

You have got to friggin kidding. Only a complete idiot would start a new
project in vb6.

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.

 

[Michael C]

Hm... I would not start new projects in VB6 because of the lack of support
for VB6 development currently and in near future. However, I'd choose VB6
for technical reasons and its ease of use if this was the only criterion.
Note the "The down side is that it is an older tool" in the post you
replied to.

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

Michael

 

[Michael S]

You have got to friggin kidding. Only a complete idiot would start a new
project in vb6.

Michael

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

OldSchoolNotSupportedException
NativeCodeMyAssException
FastForASnailException

Just no name a few =)

Nice Name
- Michael S

 

[Michael C]

NativeCodeMyAssException
FastForASnailException

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

Michael

 

[Jerry Coffin]

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

Thank you.

But now I'll jump at it.

Visual Basic Sucks So hard It Bends Light.

I sure am glad I didn't recommend VB anywhere...

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

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

 

[Michael C]

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

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

Michael

 

[Michael C]

C API OK but takes fiddling: Michael C says the API works fine most of
the time, but other times has to do a fair amount of tweaking, usually
with passing string buffers.

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

Michael

[StructLayout(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();
}

 

[Cor Ligthert [MVP]]

Michael,

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

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

Cor

 

[Cor Ligthert [MVP]]

Michael,

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

Cor

 

[Cor Ligthert [MVP]]

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

 

[Charlie Gibbs]

Writing a GUI app in C API has a steep learning curve, but is not too
bad once you get the hang of it. Your application will run much
faster and be more compact if it's written without .NET.

From the screenshots it appears your application has a fairly basic
user interface (i.e. Dialog boxes containing list and editboxes), with
the complexity in the processing.

Dialog boxes are fairly easy to do in C, and it will be easy to
inteface to your current code.

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

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

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

 

[Michael C]

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.

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

 

[Michael C]

Michael,

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

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

 

[Jeff Gaines]

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.

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.

 

[Jon Davis]

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

 

[Jon Davis]

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

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