wxWidgets even worth it?

[Raijinsetsu]

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

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

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]

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.).[...]

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

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.

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

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.

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.

[mdelfede]

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

btw, with MINGW there's only ONE dll, and it's specific to mingw, so I think there's really no problem at all putting mingw in the path. Of course, if you have an executable with the same name of one in mingw tree, you'll have maybe the wrong one when you run it... but then, I think you have really a poor installation on you system.

Speaking about windoze, it's well known that it becomes slower and less stable with time, because of installation of new software, etc... but you'll not solve it taking mingw off the path.
The only way to keep window more or les performant would be e frash install, let's say, each year. I'm thinking to do it like this in my office, as all PCs that I've there are becoming unusable.
I'll make a complete fresh setup with all software I need, and then make a copy of system disk on DVD to spare installation time when i'll run again into problems (which is unavoidable, believe me...)

That's the first reason I'd like to migrate completely on Linux... at least, there you know (or CAN know) there to put your hands to solve problems without having to do a fresh installation.

Regards

Max