Win32? MFC? .NET? What to use for embedded dev?

  • Thread starter Thread starter Guest
  • Start date Start date
G

Guest

Howdy,

I need to develop an embedded Windows application. I'm an experienced C and
C++ programmer with predominately an embedded and unix background, but in
terms of modern Windows software development, I've got a lot to learn, so
I'm looking for some tips on how/where to get started. I'll be using C++
with Visual Studio 2005. The app will require several different threads
collecting/analyzing data and performing I/O. It doesn't require a gui; a
console/text output window is fine.

Some questions:

- Is there any performance benefit to using XPembedded versus regular XP?
(Sorry, I asked a variant of this before but that part wasn't really
answered).

- What is the best starting point might be for me in terms of technologies
(Win32, MFC, .NET)? My first guess is to start with a Win32 Console Project.
But I just saw some stuff about MS "deprecating" Win32 in favor of .NET
framework. Do I want/need to use something like MFC or .NET for what I'm
doing? Any benefits? What do developers typically use?

Beyond that what are some good books/online resources to learn that stuff
and to serve as a reference? (Ie: If .NET is the way to go, what are some
good books to learn it from?)

Thanks!
 
1. Performance is relative. XPe is XP Pro broken down into 11,000+
components. You pick and choose what you want in the image. The fewer
services and features the performance might be faster. Once again it depends
on what you are doing.

2. It didn't take me long to get familair with .NET programming. Start with
a console app and try an MFC applicaitons. There are lots of getting started
books on C# and VB.NET. MS Press books have som pretty good C# books out
there: Inside C# v2, Visual C# .NET Step-By-Step, Progrmming Visual C# .NET,
C# Programers Cook book to name a few.

Regards,

Sean Liming
www.sjjmicro.com / www.seanliming.com
XP Embedded Book Author - XP Embedded Advanced, XP Embedded Supplemental
Toolkit
 
1. That's what I had thought (that paring down features might possibly help).
I guess I was wondering if people found this to be the case in general or
even if there was some anecdotal stuff like "disabling the windows shell gave
us a 5% performance increase".

2. So people do use MFC and .NET for their embedded apps? Is using Win32 a
bad idea? Also, I forgot to mention the app needs to be C++. Can you
recommend some good current Windows C++ programming books (for Win32, MFC
and/or .NET)

Thanks!
 
Applications are really accross the board. Mostly the are written in the
language of personal preference: C++, .NET, MFC, ... and oh yeah Java. You
can choose what ever you want.

Regards,

Sean Liming
www.sjjmicro.com / www.seanliming.com
XP Embedded Book Author - XP Embedded Advanced, XP Embedded Supplemental
Toolkit
 
I greatly respect Sean but I'll offer a different perspective. I had a
background similar to yours -- primarily Unix and "true" embedded systems
before I came to XP Embedded. For your application (which is similar to
mine) I see no real advantage to buying into any of the Windows programming
paradigms, i.e. .net, MFC, win32, etc. I prefer to do everything in what is
basically a POSIX compliant paradigm using stdio, standard (Berkeley-like)
sockets, etc. This leaves open the potential for much simpler porting to a
different OS should that prove advantageous. From what you described I
think the only thing that can't look quite standard is thread creation and
control since there are no pthread-like calls available but you could easily
create wrappers around the win32 thread functions. Also, I don't use any
Visual Studio project type and instead I use my favorite editor (vi) and
makefiles. When it's necessary to use the VS debugger this approach makes
things only a bit harder but for me it's worth it not to have project files
and the other encumbrances of VS.

I'm not claiming to be an expert in making these judgments so if anyone can
tell me why I've missed something valuable in the Windows paradigms I would
be a grateful listener.

HM
 
Henry said:
I'm not claiming to be an expert in making these judgments so if
anyone can tell me why I've missed something valuable in the Windows
paradigms I would be a grateful listener.
Click to expand...

The only argument I can see is time to market. That's usually the main
reason for going with XPe anyway.
 
I would like to hear why using a Windows paradigm such as MFC or win32 in
XPe might mean getting to the market faster than using POSIX, Berkeley
sockets, etc. in XPe. For example is there something better about
ReadFile() than fread() or something better about CSocket() than socket()?
Remember this was described as a console based (no GUI) system. I am asking
this sincerely because I just don't see the advantages.

HM
 
Henry said:
I would like to hear why using a Windows paradigm such as MFC or
win32 in XPe might mean getting to the market faster than using
POSIX, Berkeley sockets, etc. in XPe. For example is there something
better about ReadFile() than fread() or something better about
CSocket() than socket()? Remember this was described as a console
based (no GUI) system. I am asking this sincerely because I just
don't see the advantages.
Click to expand...

I agree, if there is no significant UI.

If there is no UI I'm not sure there is even much advantage to using
XPe for most applications.

I'm talking about using RAD tools and code reuse from Win32 projects.
 
Back
Top