//This page was written by expressing his opinions//
Table of Contents
In this discussion, I'm certain that we should rewrite the entire code of C++ Shell Extension for 0.9 release.
//Answer by :// A complete rewrite sounds a bit much. I fail to see why this would be needed. The basic design of the current C++ extension sure is not that horrible that it would need a complete rewrite?
- VC++ 9.0 as default build environment
- for using VC++ specific functions
- reduce output file size
- TCHAR string system
- enable 'UNICODE' & '_UNICODE' symbols
- for good performance
- for supporting both ANSI & Unicode applications
- Secure string functions have leading '_s'
- prevent buffer overrun issues
- VC++ 9.0 (Visual Studio 2008 or Visual C++ Express 2008)
Why don't you use VC++? C++ Shell Extension doesn't need to be platform independent. No reason to use g++ for this. And it will bring profit to file size.
//Answer by :// You can already use the MS C++ compiler today (as of 2009-06-19). See ShellExtension for the details how to do that. The created dll is indeed much smaller.
In "Part 1-2: Working with Characters and Strings" (this book), they recommend to use Unicode (wide string, UTF-16) in the application.
Actual implementation is not good in performance facet. Because it always need to convert from ANSI string to Unicode string. For this, we have to enable 'UNICODE' and '_UNICODE' symbols in compile time.
//Answer by :// I don't really think we have a performance problem here. Did you measure?
To prevent buffer overrun issues, we use non-standard functions of C/C++ library, contained in VC++ library.\\ strcpy_s, wcscpy_s, _mbscpy_s: http://msdn.microsoft.com/en-us/library/td1esda9.aspx
//Answer by :// Using these functions would lock out use of MinGW forever. The open source community has generally met these proprietary extensions with defat. There is no real need to use these functions, as the same effect can be achieved by using standard functions and types
//General comment by //: I think it would have been easier to discuss this on the mailing list instead of a wiki page.