User forums > General (but related to Code::Blocks)

wxWidgets even worth it?

<< < (4/5) > >>

Raijinsetsu:

--- Quote from: mdelfede on July 12, 2006, 12:42:32 am ---
Supposing that you have correctly installed mingw in c:\mingw, the most reliable (and permanent) way to put it in your path is done with these steps :
1) Open 'My Computer" in start menu (or whatever it's called in your language...)
2) Right click in 'My Computer' window, select "Properties" from menu
3) Select "Advanced" tab, then select the button right on top of Ok button (sorry, I've got Italian windows XP and don't remember the english label....)
4) In 'System Variables" (if I remember the english name...), select path and edit it, adding this at the end :

--- Code: ---            ;c:\mingw\bin;c:\mingw\mingw32\bin

--- End code ---
try it, if it's ok, you should be able to run mingw32-make from all places.

--- End quote ---

You shouldn't really change the path to include those bin directories because CygWin and MinGW have DLLs that clobber some programs that use GTK in windows(Gaim, Gimp, etc.). Also, I noticed, at least on my system, that the stability of windows dropped a ton. Supposedly this was from my shell program using DLLs in CygWin's bin directories instead of in the programs working directory. This is really the problem of those other programs, but until those other programs start fixing themselves, I don't suggest changing the path variable in this manner.

Michael:

--- Quote from: Raijinsetsu on July 15, 2006, 12:00:49 am ---You shouldn't really change the path to include those bin directories because CygWin and MinGW have DLLs that clobber some programs that use GTK in windows(Gaim, Gimp, etc.).[...]

--- End quote ---

Hello,

But if you have just MinGW, then there are no problems :). Anway, each time I install MinGW (with the installer), the PATH env. variable is automatically updated (or the mingw bin path is added).

Best wishes,
Michael

Raijinsetsu:
There are still problems, trust me, I've run into them. System stability dropped significantly. ANY program that uses a DLL in it's home directory that happens to have the same name as one in the cygwin\bin or cygwin\usr\bin directories will be clobbered. This applies for mingw also. Windows searches %PATH% for DLLs, then it searches the current working directory. Read what I wrote in another thread: http://forums.codeblocks.org/index.php?topic=3550.0

le meow

Pecan:
DLL search order depends on your windows settings


--- Quote --- DLL search path

DLL procedures are usually declared without giving a path to the DLL file. The normal Windows search order for a DLL is the following.

   1. Directory from which app loaded (executable directory)
   2. Current directory (can be overridden with an API call to SetDllDirectory)
   3. System directory
   4. 16-bit system directory
   5. Windows directory
   6. Directories listed in the PATH environment variable

What is more, WinXP and later have a setting where the current directory is searched only after the System and Windows directories.

--- End quote ---

Windows 2003 server SP1 changed the default search order to "paths first" to fight some trojans.


--- Quote ---Dynamic-Link Library Search Order

Starting with Windows XP, the dynamic-link library (DLL) search order used by the system depends on the setting of the HKLM\System\CurrentControlSet\Control\Session Manager\SafeDllSearchMode value.

    Windows Vista, Windows Server 2003, and Windows XP SP2:  The default value is 1.

    Windows XP and Windows 2000 SP4:  The default value is 0.

If SafeDllSearchMode is 1, the search order is as follows:

   1. The directory from which the application loaded.
   2. The system directory. Use the GetSystemDirectory function to get the path of this directory.
   3. The 16-bit system directory. There is no function that obtains the path of this directory, but it is searched.
   4. The Windows directory. Use the GetWindowsDirectory function to get the path of this directory.
   5. The current directory.
   6. The directories that are listed in the PATH environment variable. Note that this does not include the per-application path specified by the App Paths registry key.

If SafeDllSearchMode is 0, the search order is as follows:

   1. The directory from which the application loaded.
   2. The current directory.
   3. The system directory. Use the GetSystemDirectory function to get the path of this directory.
   4. The 16-bit system directory. There is no function that obtains the path of this directory, but it is searched.
   5. The Windows directory. Use the GetWindowsDirectory function to get the path of this directory.
   6. The directories that are listed in the PATH environment variable. Note that this does not include the per-application path specified by the App Paths registry key.

--- End quote ---

There are also some legacy conditions for loading. Article is at:

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dllproc/base/dynamic-link_library_search_order.asp

Raijinsetsu:
The "Registry"... just one of the many "benefits" of Winblows. And I think their search algorithm might be broken, because libraries in cygwin\bin were being used before application libraries, which, according to the article, is impossible.
Thanks for the post.

Navigation

[0] Message Index

[#] Next page

[*] Previous page

Go to full version