Developer forums (C::B DEVELOPMENT STRICTLY!) > Development
Windows Nt support
bluearms:
--- Code: ---if ( wxGetWinVersion() >= wxWinVersion_98 )
--- End code ---
Tim S
If you just OS check and use API in the source, it can not be solution. Compiled binary requires all DLL reference must be resolved in the runtime (or maybe load time). So in windows 95 and windows nt, unsupported API reference must not exist in the binary. So only option is just use supported API or use dynamic load of DLL and must check API at runtime. OS checking is not necessary, because suspious API can be checked directly at runtime.
stahta01:
I have uploaded the patch for this to Berlios
[ Patch #1823 ] Fix sdk/globals.cpp for WinNT 4.0 Bug
https://developer.berlios.de/patch/index.php?func=detailpatch&patch_id=1823&group_id=5358
Note: Is the problem at Berlios gotten worse it took many trys for me to upload the patch?
The ANSI Binary has been uploaded for win95 and WinNT 4.0 users to test at http://www.savefile.com/projects/1039215
pick the file called codeblocks_ansi.7z
Note: Patches that exists in my ANSI build include
[ Patch #1823 ] Fix sdk/globals.cpp for WinNT 4.0 Bug
https://developer.berlios.de/patch/?func=detailpatch&patch_id=1783&group_id=5358
[ Patch #1783 ] GetConfigFolder patch to make it work in a Portable win32
Note: I also disabled the crashhandler with this patch because PVECTORED_EXCEPTION_HANDLER did NOT exist when I told minGW GCC that I was a WINVER 0400.
--- Code: ---Index: src/src/crashhandler.h
===================================================================
--- src/src/crashhandler.h (revision 3483)
+++ src/src/crashhandler.h (working copy)
@@ -1,7 +1,7 @@
#ifndef CRASH_HANDLER
#define CRASH_HANDLER
-#if (__WXMSW__)
+#if defined(__WXMSW__) && defined(PVECTORED_EXCEPTION_HANDLER)
#include <winnt.h>
Index: src/src/crashhandler.cpp
===================================================================
--- src/src/crashhandler.cpp (revision 3483)
+++ src/src/crashhandler.cpp (working copy)
@@ -1,4 +1,4 @@
-#if (__WXMSW__)
+#if defined(__WXMSW__) && defined(PVECTORED_EXCEPTION_HANDLER)
#include "sdk.h"
#ifndef CB_PRECOMP
#include <wx/filefn.h>
--- End code ---
Tim S
thomas:
--- Quote from: stahta01 on January 14, 2007, 06:29:08 am ---I don't think looking at the DLL for an entry point is the normal way to code this, but it should work.
--- End quote ---
That's in fact the only acceptable way of doing it. :)
stahta01:
--- Quote from: thomas on January 15, 2007, 08:55:34 am ---
--- Quote from: stahta01 on January 14, 2007, 06:29:08 am ---I don't think looking at the DLL for an entry point is the normal way to code this, but it should work.
--- End quote ---
That's in fact the only acceptable way of doing it. :)
--- End quote ---
I agreed it should work, but I assumed it was too low a level of coding for use in a application. I think it is the type of solution that should be coded in the GUI Library not at the application level of code.
Tim S
bluearms:
I downloaded patched binary and installed in the windows 95 OCR2.5 and NT 4.0 SP6. Both start and quit without error. I have not done serious works yet. Just set compilers and default options. The required patch about window posinitioning is not a critical patch, so it seems ok. If I found error, I will report.
In unix programming shred library dynamic loading is common way of designing plugins etc. So I think dynamic loading of problematic kernel library's API can not be a problem. In fact the required kernel dlls are already load in the memory, they just return the address of requested api in the memory if they exist. If not? simply return NULL.
So I think problematic apis as a pluggable apis or use some wrapper procedures.
Of course kernel dlls are more security concerned than plugin dlls. But they are protected if required by system of course.
And If you turn off multi monitor support, code::blocks will appear in the most upper left single monitor in multi monitor system. Except that, no critical problem. But turning off the multi monitor support is not a good option if it is already supported in most systems.
Anyway I expect one binary can support all windows versions. (That is we can download the wanted binary from main distribution)
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version