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

[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!

 

[Sean Liming \(eMVP\)]

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

 

[Guest]

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!

 

[Sean Liming \(eMVP\)]

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

 

[Henry Markov]

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

 

[Mike Warren]

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.

The only argument I can see is time to market. That's usually the main
reason for going with XPe anyway.

 

[Sean Liming \(eMVP\)]

Cool! That is a new approach to me. The more feedback the better.

Regards,

Sean Liming
www.sjjmicro.com / www.seanliming.com
XP Embedded Book Author - XP Embedded Advanced, XP Embedded Supplemental
Toolkit

 

[Henry Markov]

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

 

[Mike Warren]

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.

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.

 

[Sean Liming \(eMVP\)]

FYI - Some people have used Cygwin as part of XPe.

Once again, it is all about the final application.

Regards,

Sean Liming
www.sjjmicro.com / www.seanliming.com
XP Embedded Book Author - XP Embedded Advanced, XP Embedded Supplemental
Toolkit