Comments on The Julipedia: Blog: Win32: Mappings for Unicode support

Thanks to both for the clarification. I have fixe...

2006-06-14T21:11:00.000+02:00

Thanks to both for the clarification. I have fixed the article accordingly.

>Win32 API = MFC, but maybe I am wrong and I >shou...

2006-06-14T19:44:00.000+02:00

>Win32 API = MFC, but maybe I am wrong and I >should change the term.

MFC is wrapper around Win32 API, also it contains some widgets and so on.

If tell on "unix language",
posix ~= win32 api
qt ~= mfc,

so when you say something like
I want use "fork", so I have to use QT,
or I'll use "exec", so I have to use gtkmm,
this sounds like nonsence for me.

Thankfully, MFC is not the name of the standard Wi...

2006-06-14T16:52:00.000+02:00

Thankfully, MFC is not the name of the standard Windows API. That's Win32, and it's in C only. MFC is the horrendous C++ wrapper library that has been causing library dependancy problems ever since they allowed ISVs access to the source.

If you really are using any part of MFC in your Windows code, I'd implore you to look for the Win32 alternative. (which MFC is calling anyway) :)

If I understand you correctly, you want to know wh...

2006-06-14T15:14:00.000+02:00

If I understand you correctly, you want to know why I need MFC in Boost.Process, is it?

One of the goals of Boost.Process is to be portable, supporting POSIX systems and Windows at a minimum.

In order to implement the required functionality in Windows, I must use the native API, not some POSIX compatibility layer around it.

Please note that I've always assummed that Win32 API = MFC, but maybe I am wrong and I should change the term.

>and this involves native >Windows programming wit...

2006-06-14T15:07:00.000+02:00

>and this involves native >Windows programming with the >MFC.

What attitude has MFC to your work? May be you tangle win32 API and MFC? If not, your implementation will depend on not free library?