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

[David Jones]

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]

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

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]

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.

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

Jon,

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

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]

OMG this is such a stupid subthread. Why are you guys encouraging a troll?

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

Jon,

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 Davis]

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]

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

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

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

 

[=?ISO-8859-1?Q?Arne_Vajh=F8j?=]

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]

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.

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

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.

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]

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