how much harder is Windows C API than C#/.NET
dan
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
Atmapuri
> 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.
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:
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
dan
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
Jeff Gaines
<1157324380.6...@74g2000cwt.googlegroups.com> dan wrote:
>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.
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
Michael S
news:1157320709....@74g2000cwt.googlegroups.com...
> 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.
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'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,
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.
>
> 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,
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.
>
> 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
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?
> ** 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
'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 =)
> ** 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
Too complex for me to just write a line about it. Others will ask you to
post code for analysis.
> ** 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.
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.
> ** 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.
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>
> ** 6) More difficult to maintain (in this particular case). The app has
*********** End background / war story
</snip>
> 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.
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.
> Daniel Goldman
Sincerely
- Michael S
Jon Davis
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
Andy Sinclair
>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.
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
dan
*** 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
Atmapuri
> 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?
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...
> 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?
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
Jeff Gaines
<1157357898....@74g2000cwt.googlegroups.com> dan wrote:
>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?
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
Daniel James
wrote:
> 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?
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.
Chris Becke
> 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.
Jerry Coffin
dago...@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.]
[ ... ]
> Problems I found with C#/.NET that make me consider using C API:
[ ... 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.
Michael S
> *** 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.
Calling C from VB6 is a nightmare. Avaid at all cost.
> 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?
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.
> 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.
It's no small thing you try to do.
I actually envy you for having a complex task at hand.
> 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.
poor poor you =)
> 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.
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.
> 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?
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.
> Thanks,
> Daniel Goldman
Good Luck
- Michael S
Jerry Coffin
jco...@taeus.com says...
[ ... ]
> 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
Michael S
news:MPG.1f662a872...@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
Michael C
news:eRotQB$zGHA...@TK2MSFTNGP02.phx.gbl...
> 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]
>> 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.
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/>
Michael C
news:etlMfGH0...@TK2MSFTNGP04.phx.gbl...
> 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
"Michael C" <nos...@nospam.com> wrote in message
news:eBFRlwG0...@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
Michael C
news:urRtLfH0...@TK2MSFTNGP06.phx.gbl...
> 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
> 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();
}
Leslie Milburn
> 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?
>
> Daniel Goldman
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.
Leslie Milburn
> 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.
and they would ^ not ^ be able to create, let alone read one.
Charlie Gibbs
(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.
--
/~\ cgi...@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!
Cor Ligthert [MVP]
> 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]
In my idea does it needs VB6 forever a special runtime. (As almost all
program languages beside the managed languages needs)
Cor
"Michael C" <nos...@nospam.com> schreef in bericht
news:e9hTslH0...@TK2MSFTNGP03.phx.gbl...
Cor Ligthert [MVP]
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-spa...@gmx.at> schreef in bericht
news:etlMfGH0...@TK2MSFTNGP04.phx.gbl...
Michael C
news:eIICYjK0...@TK2MSFTNGP04.phx.gbl...
> 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
Jerry Coffin
CD...@NOSPAM.bigpond.com says...
[ ... ]
> I have been programming windows since Win286, my original background being a
> Pyramid Unix System.
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.
[ ... ]
> 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.
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."
> 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.
The beginning of time stretches back to a LONG ways before the beginning
of Windows programming.
> 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.
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.
> 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.
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.
Leslie Milburn
> 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.
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.
Jerry Coffin
CD...@NOSPAM.bigpond.com says...
[ ... ]
> 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.
Well, that's certainly possible.
> 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.
All of that seems to be statements, not advice...
> And yes, real programmers can write anything in C.
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::string> lines;
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. :-)
Jeff Gaines
Gibbs wrote:
>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.
--
Jeff Gaines
Jon Davis
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" <nos...@nospam.com> wrote in message
news:eBFRlwG0...@TK2MSFTNGP03.phx.gbl...
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
Jon Davis
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
Jon Davis
> In a OO environment it would throw a whole bunch of exceptions =)
>
> OldSchoolNotSupportedException
> NativeCodeMyAssException
> FastForASnailException
>
> Just no name a few =)
>
> Nice Name
> - Michael S
"The post has an on error resume next and so it shows"; are you referring to
my post? I don't get it.
Jon
Jon Davis
Oh, that was you. =P
Jon
Michael S
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
Michael S
> "The post has an on error resume next and so it shows"; are you referring
> to my post? I don't get it.
>
> Jon
>
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 =)
dan
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
Jon Davis
> "Michael C" <nos...@nospam.com> wrote in message
> news:e9hTslH0...@TK2MSFTNGP03.phx.gbl...
>> "Michael S" <n...@no.no> wrote in message
>> news:urRtLfH0...@TK2MSFTNGP06.phx.gbl...
>>> NativeCodeMyAssException
>>> FastForASnailException
>>
>> Despite all it's faults VB6 does compile to native code and is very fast.
>>
>> Michael
>
> 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.
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
Michael S
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
Jon Davis
> 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.
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
David Jones
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
Michael S
>
> "Michael S" <n...@no.no> wrote in message
> news:ObFxroV0...@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.
>
> As I said, COM is not relevant to the topic of whether code is native.
Not relevant? What do people do with VB6? String-theory?
> A proper comparison for the OP is to perform common routines..
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
- Michael S
Jon Davis
go look up the word "native" in the context of software programming and use
your findings as qualifications of your banterings.
Jon
Michael S
news:_vqLg.7052$SZ3.6569@dukeread04...
> Native = platform-specific.
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
![Jon Skeet [C# MVP]'s profile photo](http://lh3.googleusercontent.com/a-/ALV-UjUE-UkOE6oV07-Al6msToqDuW9IN9k9G_wNeBLWDr7OkQdq7K1C5zHX3w=s40-c)
Jon Skeet [C# MVP]
<snip>
> Native = platform-specific. Some languages, like Java, run using
> interpreted code.
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.
--
Jon Skeet - <sk...@pobox.com>
http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet
If replying to the group, please do not mail me too
Michael C
news:1157501813....@h48g2000cwc.googlegroups.com...
> 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.
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
Chris Becke
> 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).
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.
Michael S
news:MPG.1f6875d38...@msnews.microsoft.com...
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
Daniel James
wrote:
> 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.
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 S
news:VA.00000ee...@nospam.aaisp.org...
>
> Let me expand just a little on what I said before ...
>
You really did.
While I am trolling you are posting.
Excellent post.
- Michael S
David Jones
> "David Jones" <nc...@tadmas.com> wrote in message
> news:_vqLg.7052$SZ3.6569@dukeread04...
>
>
>>Native = platform-specific.
>
>
> Really? Is that the N in LINQ?
You mean Language INtegrated Query? What does that have to do with
native code?
> Is that what the n in ngen.exe means?
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'?
Since as long as I've heard the term, probably since the introduction
of interpreted languages.
David
David Jones
> David Jones <nc...@tadmas.com> wrote:
>
> <snip>
>
>>Native = platform-specific. Some languages, like Java, run using
>>interpreted code.
>
>
> 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.
So? The code is stored in an interpreted form. The fact that it
compiles at runtime at the beginning vs compiles at runtime while
executing doesn't make it not interpreted. At some level, all code
has to be converted to native code so that it can execute.
Are you suggesting that Java bytecode is native code? That .NET
is native code?
David
Michael S
> Michael S wrote:
>
>> "David Jones" <nc...@tadmas.com> wrote in message
>> news:_vqLg.7052$SZ3.6569@dukeread04...
>>
>>
>>>Native = platform-specific.
>>
>>
>> Really? Is that the N in LINQ?
>
> You mean Language INtegrated Query? What does that have to do with
> native code?
>
Try Language Integrated Native Queries.
Now tell me how initializers and projections has nothing to do with native
code...
>> Is that what the n in ngen.exe means?
>
> 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.
I also agree. Native is by definition specific. Not only to platform but
often to cpu.
The whole point with Java VM and CLR is via a JITer to take bytecode or CIL
and compile it.
A better example is FastMM, a memory-manager for Delphi, that have support
for several processors and memory. You have different op-codes depending on
if you are on AMD or Intel and if you much or less memory.
This is obvious. What are you trying to prove?
> David
Confused
- Michael S
Leslie Milburn
> 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).
Hi Dan,
Lets face it - everyone is biased in one way or another as we all use our
favourite tools and methodologies.
Re-reading your original post it appears that your current skill set is
already C so I think it would be a mistake at this stage to potentially get
bogged down with learning another language. Also you have eliminated using
an IDE and so you have already answered your own question.
Anyway, straining my memory to remember the curses/terminfo stuff I really
do not think that you are not going to have that much difficulty learning
the Win32 API so don't be put off - you have already tackled far worse in
that curses is quite primitive (or was when I used it 20 years ago). I am
betting that you *will* be surprised at how simple Win32 actually is.
Leslie.
dan
I appreciate your thoughtful comments (everyone else's too). I know C#
quite well. Perhaps unfortunately, I have already ported the Vitalnet
UI to C#/.NET, as Microsoft advised. I love C#, as a programming
language. There were just some significant problems with .NET and the
mixing C/C# I encountered, spelled out in the original post.
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, it should be easy to incorporate the
existing C code. 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.
I'm not really hung up on vi. I just can't use a form designer to do
this application. The program generates multiple executables. Each
executable is customized for a particular data analysis scenario, such
as Texas births. The appearance of the user interface is different for
each scenario, so I'm pretty sure a IDE-type form designer is pretty
useless. Each executable has different number of tabs, different
content on each tab. I think I have to write code that generates the
forms in real time, depending on the data structures (all those lines
of header files) that make up the data analysis scenario. The code
reads a bunch or arrays that specify everything, and makes the forms
depending on the parameters. It's data-driven programming. 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! The
arrays are like the objects the program operates on. The Vitalnet
program is like a form designer itself. A long time ago, I used IDE
form designers (visual foxpro), and I enjoyed it a lot. In defense of
coding the old-fashioned way, I use unix utilities (sh, sed, grep) to
simplify and automate the code maintenance. And also, I can directly
see everything, since there is nothing between me and the code. Anyway,
you're right that if there was an automated tool to generate and manage
the code, I should probably use it. But I don't think it's an option
here.
I really appreciate your book recommendation.
Daniel Goldman
Cor Ligthert [MVP]
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.
Therefore it is my idea native mode to the OS.
However just after some thinking about this.
Cor
"Jon Skeet [C# MVP]" <sk...@pobox.com> schreef in bericht
news:MPG.1f6875d38...@msnews.microsoft.com...
Jon Skeet [C# MVP]
> > 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.
>
> So? The code is stored in an interpreted form.
Code is stored in an intermediate form. "Stored in an interpreted
form" makes no sense as a concept.
> The fact that it
> compiles at runtime at the beginning vs compiles at runtime while
> executing doesn't make it not interpreted.
Um, yes it does. If, by the time the code is actually being run, it has
been compiled to native code, that means it's *not* being interpreted.
Consider a loop that executes 100 times. With an interpreter, the byte
code will be examined every time you go through the loop, and the
effect of the byte code will be executed appropriately. With a JIT, the
loop is converted into native code *once*, and then the byte code is
effectively discarded (aside from things like HotSpot re-jitting etc).
> At some level, all code
> has to be converted to native code so that it can execute.
No. There's a big difference between interpreting byte code (i.e.
acting on it directly), and converting that byte code into a self-
contained set of native instructions.
If you don't see there's a difference, try using an old JVM that still
allows you to run it in a genuine interpreted mode. The performance
difference is vast.
> Are you suggesting that Java bytecode is native code? That .NET
> is native code?
No. I'm suggesting that neither of them is actually interpreted. An
environment using a JIT is neither native nor interpreted - why do you
want to pigeon-hole it into one or the other?
Jon Skeet [C# MVP]
> Try Language Integrated Native Queries.
No, Language INtegrated Query. See
http://msdn.microsoft.com/data/ref/linq/default.aspx?pull=/library/en-
us/dndotnet/html/linqprojectovw.asp
> Now tell me how initializers and projections has nothing to do with native
> code...
It doesn't. Even if the "N" stood for "native" that wouldn't need to be
"native code" - it could be "native to the language", i.e. you write
elements of the query in the same language as the rest of the app. Not
that "N" does stand for "native" in LINQ.
Jon Skeet [C# MVP]
> 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.
The JVM isn't bound to one programming language either. There are
*lots* of languages targetting Java bytecode. I've got a list somewhere
if you're interested...
> Therefore it is my idea native mode to the OS.
>
> However just after some thinking about this.
I don't really know what you mean by "native mode to the OS", to be
honest.
Jon Davis
>>>>Native = platform-specific.
>>>
>>>
>>> Really? Is that the N in LINQ?
>>
>> You mean Language INtegrated Query? What does that have to do with
>> native code?
>>
>
> Try Language Integrated Native Queries.
It's Language INtegrated Query. Shut up and do your homework.
Anyway, VB 5 introduced native compilations.
http://en.wikipedia.org/wiki/Visual_Basic
http://msdn.microsoft.com/library/en-us/vbcon98/html/vbconnativecodecompilerswitches.asp?frame=true
Native here means that the output is i386 code that can be pushed straight
to the microprocessor, and that makes direct calls, alongside its support
libraries (which only add functions), to the Win32 API behind the scenes.
The code is not pushed through a P-Code translator, there is no script
interpreter, the garbage collector is not shifting things around at runtime,
there is no JIT process to slow startup time, and the end result is
virtually identical to a straightforward C application.
Now, does that make VB6 something that is grandiose in worthwhile coding?
Not at all. As I said, I would hate VB6 if it was not still occasionally
handy. Others here obviously despise it, some with reasons better than
others. But to be hung up over valid semantics in a suggestion of the facts
just to engage in the witless debate over matters not directly related to
the original question (i.e. COM, 'native', LINQ, etc) is a waste of mine and
everyone else's time.
Jon
Cor Ligthert [MVP]
In fact you are giving yourself the answer.
> The JVM isn't bound to one programming language either. There are
> *lots* of languages targetting Java bytecode. I've got a list somewhere
> if you're interested...
>
The in Net build Jit/Ils is not connected to a program language. For me is
the Net an overlay on the OS whatever that is (Linux/Win32/WinFX). The
managed code programming languages assemblies are all runing in the runtime
for that. There is not a special language per programlanguage.
Therefore it is for me native mode to the OS/Net version.
All managed programs run on the same runtime as is included in the Net for
that OS. Which means that it is running (in native mode) without any
external support on that OS. (Not native to the processor that is the OS
doing).
Cor
"Jon Skeet [C# MVP]" <sk...@pobox.com> schreef in bericht
news:MPG.1f692ebec...@msnews.microsoft.com...
Jon Davis
"Jon Skeet [C# MVP]" <sk...@pobox.com> wrote in message
news:MPG.1f6875d38...@msnews.microsoft.com...
>
> <snip>
>
>> Native = platform-specific. Some languages, like Java, run using
>> interpreted code.
>
> 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.
I have to disagree with you, Jon. .NET assemblies are JIT'd when assemblies
are loaded, and it occurs every time an application is started unless the
assemblies are ngen'd. Even with NGen'ing, you still have to load up the
Common Language Runtime engine every time you run an app and as much as I
love C# that startup time is a painful experience every time. It always
reminds me of the feeling of pulling the line to start up my lawnmower...
chug .... chug .... chug .. chug .. chug - chug - chug chug chugchugchug
ggggrrrrrrrrrrRRRR...
Jon
Jon Davis
> I WOULD like to target any platform, using qt or
> wxWidgets, not just windows.
I was going to suggest wxWidgets if you're going to hand-code your GUI but
it looks like you're familiar with it. You kept quoting me (Jon Davis) as
saying that C will mean manually built GUI stuff with high risk and
vulnerability for bugs, but then if you use other APIs than just Win32 (you
only said "C API" which was vague and could only be interpreted as Win32)
then you should have a much better output.
> 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.
.. and Java GUI code runs like mollasses?
> I'm not really hung up on vi. I just can't use a form designer to do
> this application. The program generates multiple executables. Each
> executable is customized for a particular data analysis scenario, such
> as Texas births. The appearance of the user interface is different for
> each scenario, so I'm pretty sure a IDE-type form designer is pretty
> useless.
Unless you stuck with .NET/C#, right? Otherwise, there are two critical
flaws of your thinking here.
First of all, using and IDE does not necessarily mean that you must use
drag-and-drop WYSIWYG no-code-except-automation GUI layout design. Visual
Studio (for instance) is not a word processor with pretty picture layouts.
You can use an IDE and stick to coding your solutions and never see a layout
designer. The purpose of an IDE is not to drag-and-drop controls (that is
early Visual Basic thinking). The purpose is to consolidate your projects,
tools, macros, data sources, and the like, and to provide a text editor that
has extremely rich functionality as with Intellisense and automated
refactoring. There is *nothing* you can do in vi that cannot be done in good
IDEs like Visual Studio 2005. On the other hand, some other IDEs like VB6
are not so helpful.
Secondly, depending on the language and IDE you can still build controls
that are painted from isolated processes, and not throw out the bathwater
with your baby (pun reversal intended). If you haven't already tried--but I
assume you have--the GUI designer in C# 2005 is very clean in that you are
enabled to isolate configuration/property based coding from real code while
neither hinders the other. So there isn't much that stops you from
hand-coding your inter-process GUI rendering and management while still
enjoying form layouts. But you don't get any of that with C, unless there
are some great C-focused IDEs out there that I didn't know about.
Jon
Jon Davis
"Ian Semmel" <isemme...@NOKUNKrocketcomp.com.au> wrote in message
news:OnFGIeF0...@TK2MSFTNGP04.phx.gbl...
> Well, you might not like C++ and MFC, but I think that it would be the
> easiest path.
I tend to agree; and if not MFC then something like wxWidgets or some other
component library for C++.
Jon
Jon Skeet [C# MVP]
> > 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.
>
> I have to disagree with you, Jon. .NET assemblies are JIT'd when assemblies
> are loaded, and it occurs every time an application is started unless the
> assemblies are ngen'd. Even with NGen'ing, you still have to load up the
> Common Language Runtime engine every time you run an app and as much as I
> love C# that startup time is a painful experience every time. It always
> reminds me of the feeling of pulling the line to start up my lawnmower...
>
> chug .... chug .... chug .. chug .. chug - chug - chug chug chugchugchug
> ggggrrrrrrrrrrRRRR...
Sorry, by "once and only once" I meant "per run" not "forever and
ever". The difference is that HotSpot re-jits code *during a run*. For
instance, a virtual method can be inlined until a class is loaded which
actually overrides the method. At that point HotSpot re-jits anything
using that method to remove the optimisation (as it's no longer valid).
.NET doesn't do anything like that.
Jon Skeet [C# MVP]
> In fact you are giving yourself the answer.
>
> > The JVM isn't bound to one programming language either. There are
> > *lots* of languages targetting Java bytecode. I've got a list somewhere
> > if you're interested...
> >
> The in Net build Jit/Ils is not connected to a program language. For me is
> the Net an overlay on the OS whatever that is (Linux/Win32/WinFX). The
> managed code programming languages assemblies are all runing in the runtime
> for that. There is not a special language per programlanguage.
Indeed - just like Java bytecode isn't only targetted by Java. (Don't
confuse Java bytecode with Java itself.)
> Therefore it is for me native mode to the OS/Net version.
>
> All managed programs run on the same runtime as is included in the Net for
> that OS. Which means that it is running (in native mode) without any
> external support on that OS. (Not native to the processor that is the OS
> doing).
What do you mean by "without any external support"? Note that one OS
cna have multiple runtimes... you can run Mono on Windows, for
instance.
Michael C
>> Michael C has a point
>
> Oh, that was you. =P
:-)
Michael
Michael C
> 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,
The main problem was the time required to run the project in the IDE (approx
60 secs to start and 60 to stop on a p1.8, dropped to 20 sec each on a
p3.4), sourcesafe bugs and the way it is impossible to seperate out mdi
child forms into seperate projects. We also get lots of problems with the
lack of 'strictness' in the language. As an example we had the order of
references change and an ADODB.Field all of a sudden became an
ActiveReports.Field throughout the project but VB didn't warn that either
Field was ambiguous or that it couldn't be cast. We had one today where a
programmer defined a variable as RecordSet which caused every single
reference to ADODB.Recordset (note the lowecase s) to change to
ADODB.RecordSet which apparently caused problems with yesterday's release
(I'm yet to look into this fully as I was a away when it happened).
Michael
Arne Vajhøj
> Sorry for being an immature and a egocentric troll (as jon call me): But
> since when did 'native' mean 'compile for cpu'?
Always.
:-)
Native code is code that is compiled to the CPU it is
execute on.
Arne
David Jones
> David Jones <nc...@tadmas.com> wrote:
>
>>>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.
>>
>>So? The code is stored in an interpreted form.
>
> Code is stored in an intermediate form. "Stored in an interpreted
> form" makes no sense as a concept.
Fair enough. I had a poor choice of words.
>>The fact that it
>>compiles at runtime at the beginning vs compiles at runtime while
>>executing doesn't make it not interpreted.
>
> Um, yes it does. If, by the time the code is actually being run, it has
> been compiled to native code, that means it's *not* being interpreted.
> Consider a loop that executes 100 times. With an interpreter, the byte
> code will be examined every time you go through the loop, and the
> effect of the byte code will be executed appropriately. With a JIT, the
> loop is converted into native code *once*, and then the byte code is
> effectively discarded (aside from things like HotSpot re-jitting etc).
It has been compiled *TO* native code, meaning it wasn't native to
begin with. QED
Regardless of my poor choice of wording (interpreted vs intermediate),
the bottom line is that using IDispatch doesn't make code non-native,
which was all I was trying to say. That, and the fact that run-time
compilation of intermediate code does not make something native,
which is what I thought you were suggesting at first, but now I
realize you were correcting my poor comparison of native vs interpreted
when it should have been native vs intermediate (non-native).
>>At some level, all code
>>has to be converted to native code so that it can execute.
>
>
> No. There's a big difference between interpreting byte code (i.e.
> acting on it directly), and converting that byte code into a self-
> contained set of native instructions.
Fair enough.
> If you don't see there's a difference, try using an old JVM that still
> allows you to run it in a genuine interpreted mode. The performance
> difference is vast.
Performance difference, sure. I never said that there wasn't a
performance difference, or that JIT is slow.
>>Are you suggesting that Java bytecode is native code? That .NET
>>is native code?
>
> No. I'm suggesting that neither of them is actually interpreted. An
> environment using a JIT is neither native nor interpreted - why do you
> want to pigeon-hole it into one or the other?
Actually, I don't. My only point was that it's not native. With
regards to native-ness, interpreted vs intermediate is the same
thing. In the real world, when you look at how they work, of course
they are different.
I think we are agreeing here, but my poor choice of wording makes it
look like we're not. :)
David
Michael C
news:uJTPcYg0...@TK2MSFTNGP02.phx.gbl...
> We had one today where a programmer defined a variable as RecordSet which
> caused every single reference to ADODB.Recordset (note the lowecase s) to
> change to ADODB.RecordSet which apparently caused problems with
> yesterday's release (I'm yet to look into this fully as I was a away when
> it happened).
Scratch that, I've had a look into it and the problem was not caused by the
upper case S.
Michael
Daniel James
wrote:
> 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.
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.
Daniel James
> 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
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.
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.
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!
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.
Mike Margerum
> 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
>
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.
Mike Margerum
> 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.
>
I wouldn't choose VB6 for technical reasons. It's awful.
Mike Margerum
> 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 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.
Cor Ligthert [MVP]
I stop the discussion as I have read we are busy in a troll thread. I agree
with that, maybe another time.
Cor
"Jon Skeet [C# MVP]" <sk...@pobox.com> schreef in bericht
news:MPG.1f6940673...@msnews.microsoft.com...
Ben Voigt
> technologies are via IUknown com interfaces which vb6 has no support for
> at all.
IUnknown and IDispatch COM interfaces are VB6's homeland
Michael C
news:%23GZjjMr...@TK2MSFTNGP06.phx.gbl...
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
>
>
jus...@zeusedit.com
> comments.
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).
Jussi Jumppanen
Author: Zeus for Windows
Note: Zeus is shareware (45 day trial).
Jon Davis
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
Jon Davis
>
> "Michael C" <nos...@nospam.com> wrote in message
> news:%23fizzht...@TK2MSFTNGP06.phx.gbl...
>> "Ben Voigt" <r...@nospam.nospam> wrote in message
>> news:%23GZjjMr...@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 :-)
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
Charlie Gibbs
jus...@zeusedit.com (jussij) writes:
>> assuming the programmer is coding into an editor? Or any other
>> comments.
>
> 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).
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.
--
/~\ cgi...@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!
Michael C
news:%23nVPQvx...@TK2MSFTNGP06.phx.gbl...
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.
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.
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.
Michael C
> 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.
Michael
Jon Skeet [C# MVP]
> > you get power of an IDE with the feel of an editor (ie fast
> > file load, fast keyboard response etc).
>
> 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.
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
Jerry Coffin
cgi...@kltpzyxm.invalid says...
[ ... ]
> Does anyone still make a plain old symbolic debugger?
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.
--
Later,
Jerry.
The universe is a figment of its own imagination.
Michael S
> It's Language INtegrated Query. Shut up and do your homework.
>
Shutting up and stand corrected in shame
- Michael S
Jon Davis
> "Jon Davis" <j...@REMOVE.ME.PLEASE.jondavis.net> wrote in message
> news:%23nVPQvx...@TK2MSFTNGP06.phx.gbl...
>> A component does not need to be "specifically written with vb6 in mind",
>
> 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.
>
> 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.
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.
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
Jon Davis
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.
Jon
Michael C
> 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
> 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