added some wxMSW stuff

git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/trunk@9 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775

docs/msw/issues.txt

@@ -0,0 +1,67 @@
+Current issues and bugs
+-----------------------
+
+Debugging code
+--------------
+
+wxDebugContext and global memory operators doesn't work correctly,
+for different (unresolved) reasons on different compilers.
+
+1) In VC++ 5.0, if you use wxDebugAlloc for new and wxDebugFree
+for delete, you get a crash to do with deallocating the debug
+buffer in wxDebugContext. So although the global operators are
+defined, they are #ifdefed to just call malloc and free to avoid
+the problem. This means that non-object memory checking doesn't work.
+The problem does seem to be something to do with a pointer
+mysteriously changing its address, very similar to 2).
+
+2) In BC++ 4.5, there isn't a crash, but instead the ofstream
+pointer passed to SetStream from SetFile (which is called in
+memcheck.cpp) gets mysteriously changed as it's passed to SetStream.
+This means that when counting the number of outstanding memory
+blocks, we can't compare the allocated block with m_debugStream
+to say 'ignore this block because we can't free it before the
+very end of the application'. Therefore it always looks like
+there's a memory leak of one object, in memory.cpp, unless you
+don't call wxDebugContext::SetFile.
+
+The fact that pointers appear to change in both cases must
+indicate a common problem and solution. If we could use the
+standard global memory operators for ofstream and
+wxDebugStreamBuf it might help, but I don't know how to do that -
+I've redefined 'new' throughout as WXDEBUG_NEW (which is itself
+defined as the 3-argument operator).
+
+Config/registry classes
+-----------------------
+
+Problems with Karsten's/Vadim's existing AppConfig classes:
+
+- use char* a lot instead of wxString
+- rather hard to understand
+- will need fairly substantial rewrite
+- no native .ini functions (?) for guaranteed Windows
+  compatibility
+- new wxWin docs required
+
+Good things:
+
+- exists!
+- FileConfig independent of OS
+- specifying a base class that will meet nearly all needs for
+  derived classes
+- enumerator
+
+Other features we should probably have:
+
+- ability to specify vendor name/app name in constructor
+- under Windows, ability to read/write all areas of registry
+  as an option
+
+Options:
+
+- rewrite AppConfig
+- start from own CRegistry class
+- take elements from both
+- do the Windows stuff, let someone else write/adapt the
+  non-Windows classes