Author Topic: Windows Nt support  (Read 14792 times)

bluearms

  • Guest
Windows Nt support
« on: January 13, 2007, 05:06:06 pm »
Official Code::Blocks 1.0rc2 installer works ok in windows nt. But when closing installed application, I received invalid memory access error.
Recent svn build uses GetMonitorInfo API to position gui, but that api is supported after windows 2000 or windows 98. I found that in the sdk/globals.cpp
Because of that api, svn version can not start in windows nt.
I hopes that api is avoided in the future svn version. or use GetProcAddress(GetModuleHandle("user32.dll"), "GetMonitorInfoA") to check that api is available.
I think some svn version is more stable even in the windows xp.
« Last Edit: January 13, 2007, 08:10:59 pm by bluearms »

Offline stahta01

  • Lives here!
  • ****
  • Posts: 7591
    • My Best Post
Re: Windows Nt support
« Reply #1 on: January 13, 2007, 10:59:31 pm »
Under NT 4.0 what would be the valid values for the monitor RECT structure
right
left
bottom
top

Tim S
C Programmer working to learn more about C++ and Git.
On Windows 7 64 bit and Windows 10 64 bit.
--
When in doubt, read the CB WiKi FAQ. http://wiki.codeblocks.org

Offline stahta01

  • Lives here!
  • ****
  • Posts: 7591
    • My Best Post
Re: Windows Nt support
« Reply #2 on: January 13, 2007, 11:48:06 pm »
A quick patch that might fix this issue. A real patch should set the values right, left, bottom & top using some NT4/win95 system call.
Note: There is two blanks lines at bottom of patch, these are there on purpose.

Code
Index: src/sdk/globals.cpp
===================================================================
--- src/sdk/globals.cpp (revision 3481)
+++ src/sdk/globals.cpp (working copy)
@@ -624,8 +624,10 @@

 void PlaceWindow(wxWindow *w, cbPlaceDialogMode mode, bool enforce)
 {
+#if (_WIN32_WINNT >= 0x0410)
     HMONITOR hMonitor;
     MONITORINFO mi;
+#endif
     RECT        r;

     int the_mode;
@@ -649,15 +651,16 @@
     else
         the_mode = (int) mode;


+#if (_WIN32_WINNT >= 0x0410)
     hMonitor = MonitorFromWindow((HWND) referenceWindow->GetHandle(), MONITOR_DEFAULTTONEAREST);

     mi.cbSize = sizeof(mi);
     GetMonitorInfo(hMonitor, &mi);
     r = mi.rcWork;

     int monitorWidth  = r.right - r.left;
-    int monitorHeight = r.bottom - r. top;
+    int monitorHeight = r.bottom - r.top;

     switch(the_mode)
     {
@@ -729,6 +730,10 @@
     }

     w->SetSize(windowRect.x,  windowRect.y, windowRect.width, windowRect.height, wxSIZE_ALLOW_MINUS_ONE);
+#else
+    w->SetSize(wxDefaultCoord,  wxDefaultCoord, wxDefaultCoord, wxDefaultCoord, wxSIZE_AUTO);
+#endif
+
 }


« Last Edit: January 13, 2007, 11:49:41 pm by stahta01 »
C Programmer working to learn more about C++ and Git.
On Windows 7 64 bit and Windows 10 64 bit.
--
When in doubt, read the CB WiKi FAQ. http://wiki.codeblocks.org

Offline Belgabor

  • Multiple posting newcomer
  • *
  • Posts: 91
Re: Windows Nt support
« Reply #3 on: January 14, 2007, 04:36:58 am »
Sorry for chiming into an issue that doesn't really concern me :p
That patch allows you to compile a NT4 version, but wouldn't it be better to follow bluearms' suggestion and do a runtime check so a compiled version works on both?

Offline stahta01

  • Lives here!
  • ****
  • Posts: 7591
    • My Best Post
Re: Windows Nt support
« Reply #4 on: January 14, 2007, 06:29:08 am »
Sorry for chiming into an issue that doesn't really concern me :p
That patch allows you to compile a NT4 version, but wouldn't it be better to follow bluearms' suggestion and do a runtime check so a compiled version works on both?

That answer to that is it depends. We need a way to set the values right, left, bottom & top to valid setting.
If this is possible using an NT40/Win95 call that still exists under XP and win2003 we may be able to just use it.  Else we should see what version of windows we are running and use good defaults. I don't think looking at the DLL for an entry point is the normal way to code this, but it should work.
My patch was just a quick one to solve the issue for a single user NOT one good enough to submit to C::B team.

Code
if ( wxGetWinVersion() >= wxWinVersion_98 )
Tim S

Edit: See if wxClientDisplayRect returns useful info for fixing this issue.
« Last Edit: January 14, 2007, 08:38:42 am by stahta01 »
C Programmer working to learn more about C++ and Git.
On Windows 7 64 bit and Windows 10 64 bit.
--
When in doubt, read the CB WiKi FAQ. http://wiki.codeblocks.org

bluearms

  • Guest
Re: Windows Nt support
« Reply #5 on: January 14, 2007, 07:10:16 am »
I am not c++ programmer, I just use c. So this may be not correct. But this c algorithm should work.
Basically windows 95 and nt does not support multiple monitors. Anyway, why C::B requires multiple
monitors support? There are many warys of getting single monitor geometry, if you ignore multiple
monitors.

+static HMONITOR APIENTRY (*MonitorFromWindowProc) (HWND, DWORD) = NULL;
+static BOOL APIENTRY (*GetMonitorInfoProc) (HMONITOR, LPMONITORINFO) = NULL;

void PlaceWindow(wxWindow *w, cbPlaceDialogMode mode, bool enforce)
{
+ int MultiMonOk = 1;
...
...
-   hMonitor = MonitorFromWindow((HWND) referenceWindow->GetHandle(), MONITOR_DEFAULTTONEAREST);
+  if (MonitorFromWindowProc) {
+    /* MonitorFromWindowProc already set */
+    hMonitor = (*MonitorFromWindowProc)((HWND) referenceWindow->GetHandle(),
MONITOR_DEFAULTTONEAREST);
+  } else {
+    /* check API availability */
+    MonitorFromWindowProc =
+    (HMONITOR APIENTRY (*) (HWND, DWORD))
+    GetProcAddress(GetModuleHandle("user32.dll"), "MonitorFromWindow");
+    if (MonitorFromWindowProc)
+      hMonitor = (*MonitorFromWindowProc)((HWND) referenceWindow->GetHandle(), MONITOR_DEFAULTTONEAREST);
+    else {
+       /* API not available, maybe Win95 or NT 3/4.  */
+       MultiMonOk = 0;
+    }
+  }
+  if (MultiMonOk) {
    mi.cbSize = sizeof(mi);
-  GetMonitorInfo(hMonitor, &mi);
+    if (GetMonitorInfoProc) {
+      (*GetMonitorInfoProc)(hMonitor, &mi);
+    } else {
+      GetMonitorInfoProc =
+      (BOOL APIENTRY (*) (HMONITOR, LPMONITORINFO))
+#ifdef UNICODE
+      GetProcAddress(GetModuleHandle("user32.dll"), "GetMonitorInfoW");
+#else
+      GetProcAddress(GetModuleHandle("user32.dll"), "GetMonitorInfoA");
+#endif
+      if (GetMonitorInfoProc) (*GetMonitorInfoProc)(hMonitor, &mi);
+      else {
+        /* not possible, unknown error */
+        goto genericRect;
+      }
+    }
    r = mi.rcWork;
+  } else {
+genericRect:
+    HWND hDesktop;
+    int rc;
+    hDesktop = GetDesktopWindow();
+    /*  if (hDesktop == NULL) criticalErrorExit(); */
+    rc = GetWindowRect(hDesktop, &r);
+    /* if (rc==0) error(); */
+  }

...

}

I think you should convert this to proper C++ version.
Insteadd of GetDesktopWindow(), you can use GetSystemMetrics with SM_CXSCREEN and SM_CYSCREEN (maybe). I have installed platform SDK and documentation includes all windows specific APIs.
I think this kind of runtime checking of API is used in many windows porting of unix programs like perl etc.
In test, windows rectangle's right bottom part returns 1 point right down the region. If resolution is 1024x768, then
returned point is {(0, 0), (1024, 768)}. Not {(0, 0), (1023, 767) }

« Last Edit: January 14, 2007, 07:42:53 am by bluearms »

Offline TDragon

  • Lives here!
  • ****
  • Posts: 943
    • TDM-GCC
Re: Windows Nt support
« Reply #6 on: January 14, 2007, 07:43:44 am »
Anyway, why C::B requires multiple
monitors support?
Because people with multiple monitors, such as myself, use Code::Blocks; and because C::B will not work correctly for people with multiple monitors unless they are explicitly taken into account.
https://jmeubank.github.io/tdm-gcc/ - TDM-GCC compiler suite for Windows (GCC 9.2.0 2020-03-08, 32/64-bit, no extra DLLs)

Offline stahta01

  • Lives here!
  • ****
  • Posts: 7591
    • My Best Post
Re: Windows Nt support
« Reply #7 on: January 14, 2007, 11:35:42 am »
I am working on a good patch for this issue, but I need people to test it.
Anyone want to test it?

Window 95 user
Window NT 4.0 user
Multi-monitor user

Tim S
C Programmer working to learn more about C++ and Git.
On Windows 7 64 bit and Windows 10 64 bit.
--
When in doubt, read the CB WiKi FAQ. http://wiki.codeblocks.org

bluearms

  • Guest
Re: Windows Nt support
« Reply #8 on: January 14, 2007, 12:03:49 pm »
I am working on a good patch for this issue, but I need people to test it.
Anyone want to test it?

Window 95 user
Window NT 4.0 user
Multi-monitor user

Tim S

I have windows 95 and NT in the virtual pc to test software compatibility and to install some evalation purpose programs (If you install and uninstall many programs in main pc, your hard disk and registry will be get messy  :D). In that system, I usually use msys, visual studio 6, borland c++ 6, delphi 6 (to maintain small compiler system. Even with that my virtual image is getting large). If you upload compiled binary, I can use that. Anyway I need IDE in that systems  :).

Offline stahta01

  • Lives here!
  • ****
  • Posts: 7591
    • My Best Post
Re: Windows Nt support
« Reply #9 on: January 14, 2007, 12:07:36 pm »
I have windows 95 and NT in the virtual pc to test software compatibility and to install some evalation purpose programs (If you install and uninstall many programs in main pc, your hard disk and registry will be get messy  :D). In that system, I usually use msys, visual studio 6, borland c++ 6, delphi 6 (to maintain small compiler system. Even with that my virtual image is getting large). If you upload compiled binary, I can use that. Anyway I need IDE in that systems  :).


OK, after I finish testing the patch I will upload the patch to Berlios.
Then, I will make an ANSI build for Win95/NT4.0.
I will upload that to a free file share site.
Tim S
C Programmer working to learn more about C++ and Git.
On Windows 7 64 bit and Windows 10 64 bit.
--
When in doubt, read the CB WiKi FAQ. http://wiki.codeblocks.org

bluearms

  • Guest
Re: Windows Nt support
« Reply #10 on: January 14, 2007, 12:17:22 pm »
Code
if ( wxGetWinVersion() >= wxWinVersion_98 )
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.

Offline stahta01

  • Lives here!
  • ****
  • Posts: 7591
    • My Best Post
Re: Windows Nt support
« Reply #11 on: January 14, 2007, 09:22:23 pm »
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>


Tim S
« Last Edit: January 14, 2007, 09:58:59 pm by stahta01 »
C Programmer working to learn more about C++ and Git.
On Windows 7 64 bit and Windows 10 64 bit.
--
When in doubt, read the CB WiKi FAQ. http://wiki.codeblocks.org

Offline thomas

  • Administrator
  • Lives here!
  • *****
  • Posts: 3979
Re: Windows Nt support
« Reply #12 on: January 15, 2007, 08:55:34 am »
I don't think looking at the DLL for an entry point is the normal way to code this, but it should work.
That's in fact the only acceptable way of doing it. :)
"We should forget about small efficiencies, say about 97% of the time: Premature quotation is the root of public humiliation."

Offline stahta01

  • Lives here!
  • ****
  • Posts: 7591
    • My Best Post
Re: Windows Nt support
« Reply #13 on: January 15, 2007, 09:06:41 am »
I don't think looking at the DLL for an entry point is the normal way to code this, but it should work.
That's in fact the only acceptable way of doing it. :)

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
C Programmer working to learn more about C++ and Git.
On Windows 7 64 bit and Windows 10 64 bit.
--
When in doubt, read the CB WiKi FAQ. http://wiki.codeblocks.org

bluearms

  • Guest
Re: Windows Nt support
« Reply #14 on: January 15, 2007, 10:28:09 am »
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)
« Last Edit: January 15, 2007, 10:44:42 am by bluearms »