Saturday, December 10, 2011

Dev-C++ 5.0.0.9 released

A newer version is available!

Another bug fixing round. This version fully supports MinGW64, but I'm not adding it yet, because it's not completely stabile.




Changes - Version 5.0.0.9 - 10 December 2011
  • Fixed a minor settings detection bug in the profiler.
  • The code completion dialog now hides its tooltips when the user chooses so by unticking "Enable editor hints", preventing an access error.
  • Reorganized parts of the interface: now makes better use of free space.
  • One can now select and copy the information in the file properties window.
  • Added a link to GCC's compiler documentation below the compiler options.
  • Added a few more options to -march, -std and -O. Note: this might change settings in pre-5.0.0.9 projects, please reapply them!
  • The code tooltip is quite a bit faster now.
  • Fixed a bug in the brace completion code, reported by garywho.
  • (RC2+) The function tooltip now does not show up when no prototype could be found (making it a lot faster).
  • The Environment Options UI font selector now properly shows the available fonts in an MS Word like manner.
  • Updated the compilation progress window layout.
  • Added profiles for both x86 and x64 compilers.
  • Above profiles now properly update the makefile and other settings.
  • Generic gcc and g++ errors like unrecongised command line options are now properly displayed in the list box.
  • Slightly lowered the (first time) launch speeds.


Important notices
  • The options format has changed. If you want to reuse an old pre-4.9.9.3 config file (NOT recommended), or, more importantly, when you're overriding Compiler Options in your project, you need to re-set these project settings once and save the project. You'll then have an updated 4.9.9.3+ project file.
  • This version has GCC built-in instead of being an aditional package. It also contains D3D9/10/11, GDI, Win32 and OpenGL headers and libraries in that flavor.
  • This version is now fully portable. If you also don't want Dev to leave anything behind in the registry, please select "Portable" or "Minimal" in the setup options.
  • For ultimate portable programming, please launch devcppPortable.exe located in the main folder of the portable zip download. This will make dev save its configuration files in the same folder as the executable.


Download
The setup can be downloaded here. The Portable zip version can be downloaded here. The source code can be found here.



Progress implementing the 64-bit compiler
  • It's working.
  • Dev-C++ now automatically sets paths when it finds an 'MinGW64' folder.
  • The XP style manifest files now also work with 64-bit executables.
  • The 64-bit compiler now also create 32-bit executables.
  • GDI+, DWM API and D3DX are working too now.


Beta update
The 5.1.0.0 Beta 1 update can be found here. Its source code can be found here. This version fully supports 64bit compilers. I've decided not to include the full compiler with this beta version yet, but don't worry: getting it to work easy:
  • Download and install the latest full release of Dev-C++. Setup and portable versions will work.
  • Download and install this overwrite update and extract it in the Dev-C++'s main folder.
  • Download and install TDM-GCC 4.6.1 x64 to 'MinGW64'. This folder should be placed next to devcpp.exe.
  • You've got two choices now:
  • 1) Remove your configuration files from .\config (portable) or %APPDATA%\Dev-Cpp. This will force Dev-C++ to show the First Time Launch window again. Dev-C++ will look for the MinGW64 folder, and if it exists, create a working compiler configuration for you. If the folder does not exist, it will create a standard MinGW32 profile.
  • 2) Launch Dev-C++ and create a new Compiler Set in Tools >> Compiler Options. Then manually set paths for this compiler.



Problems / Upcoming changes / TODO
  • TODO: Implement C++11 suggestions by Xazax.
  • FIXED: Fix the ParentID bug in the tooltip and goto menu items.
  • TODO: Implement wxWidgets
  • DONE: Implement MinGW64
  • TODO: Finish work done on adding icons to tool menu items.

25 comments:

  1. Thanks 4 the updates! Keep up good work!

    ReplyDelete
  2. Thank you!
    You're doing a great job!

    ReplyDelete
  3. I've found a bug that wasn't there in the previous version: when I try install a devpak by selecting devpaks.org server it throws an exception. If I manually download the devpak and install it there's no problem.

    Here's the bug report:

    Application version: 5.0.0.7

    Machine info
    ---------
    Platform : Windows NT
    OS version : version 6.1 (build 7601)
    Additional info: Service Pack 1


    The following error occured in version 5.0.0.9:
    Access violation at address 0015DF82 in module 'devcpp.exe'. Read of address 00000208 (at address 0x0015DF82)

    State information follows:
    Stack trace:
    ------------
    00288416 (00187416): ShowExceptionInfo (ExceptionsAnalyzer - 564)
    0028860B (0018760B): TExceptionsAnalyzer.GlobalExceptionHandler (ExceptionsAnalyzer - 572)
    0023F67A (0013E67A): TWebUpdateForm.FormShow (WebUpdate - 876)
    0023F109 (0013E109): TWebUpdateForm.cmbMirrorsChange (WebUpdate - 724)
    0028A9D9 (001899D9): (devcpp - 216)
    0028A9F7 (001899F7): (devcpp - 216)
    0028A270 (00189270): (devcpp - 131)
    0028A270 (00189270): (devcpp - 131)

    ReplyDelete
  4. @miguel:

    First off, thank you for your support! ;)

    I can reproduce that bug by the way. I indeed was messing with the Webupdate window in this version: I deferred its loading from application launch to the actual opening of the window. Seems like I screwed up somewhere...

    ReplyDelete
  5. Yup, fixed it:

    http://gamerneeds.org/bestanden/proof.png

    There used to be two webupdate windows: one global one that didn't get initialized anymore at the start and another one that it created/destroyed when clicking the menu item. These two we're conflicting. I removed the global one (which is practically just a pointer) and everything is working again!

    Thank you for reporting!

    ReplyDelete
  6. @miguel

    Still working on this...

    http://gamerneeds.org/bestanden/64bit.png

    ... but I'll upload a beta version with the fix which you can test.

    ReplyDelete
  7. Wow! You were fast fixing it

    It's not like these devpaks are as useful as they were as most of them are a bit outdated but when you are in a hurry they are very appreciated.

    I believe the community will support them again as you're updating Dev-C++ :)


    However, I think it's much more important what you're doing with the Mingw64 support because most CPUs nowadays have 64bit architecture but there aren't many IDEs that can work with 64bit projects for Windows apart from Visual...

    Thank you for your effort!
    I'll keep reporting if I found more bugs

    ReplyDelete
  8. The 64-bit compiler currently cannot create 32-bit executables.
    What???
    Flag -m32 !!!!!!

    ReplyDelete
  9. @Sfinexer: the problem with the slimmed down MinGW64 build I was using was that it didn't come with 32-bit libs, so it started to complain when I passed m32. Fortunately TDM-GCC obeys now:

    http://gamerneeds.org/bestanden/32bit.png

    ReplyDelete
  10. The folder is unnecessary, I use a year Dev-C ++ enough ONLY to specify a folder path bin in the compiler and all!!!

    ReplyDelete
  11. Why not change the folder path compiler and libraries without restarting the program?

    ReplyDelete
  12. @Sfinexer:

    Dev-C++ sets some other minor things like disabling static libstdc++ linking for TDM-GCC, but indeed, setting the bin path is almost all you need to do.

    But ehm, these paths (like the lib path) are quite useful. For example, if you want to use m32 with the x64 compiler you *need* to add the lib32 folder to the path list.

    Well, about changing paths: if you know what you're doing you'll choose option 2 anyway.

    ReplyDelete
  13. I change my ways, but the Dev-C + + does not accept the changes before restarting the.

    ReplyDelete
  14. Something to consider:

    When I want to code for DirectX 9.0, if you include a few pick-and-choose D3D files in your 'internal library' of headers that you install, it throws off those of us using the actual MS DirectX SDK.

    I keep getting a duplicate definition error because your files are being included when I don't want or need them, instead of the correct files in a different directory. The only solution I'm seeing is to go through and remove all of the D3D files you have included from your header library.

    I really hope I don't use SDL in the future or that will probably be another few hours of hunting for dupe files.

    ReplyDelete
  15. You might want to try this:

    Tools >> Compiler Options >> Directories >> C *and* C++ Includes >> Remove all items.

    This will get rid of all automatic includes.

    Oh, and by the way, the D3D headers of MinGW32 are basically the June 2010 SDK files. TDM-GCC uses slightly modified ones though.

    ReplyDelete
  16. The problem isn't that your copy of the file is the wrong file. I also don't want to remove ALL the headers you have included, just the DX ones.

    My problem is that I already have the DirectX SDK on my system, which I want to use for my DX9C projects because it includes a more complete DirectX implementation. I also wanted to use the windows/OGL/SDI/etc that you included, but can't do that if I exclude the entire 'include' directory.

    To allow users to selectively disable/enable one of the included API's headers, it would be best to put each API in its own folder. For example, you'd have C:\Dev-CPP\include\D3D, C:\Dev-CPP\include\OGL, C:\Dev-CPP\include\GDI, C:\Dev-CPP\include\Win32, etc.

    Then, if I don't want to use the D3D files you included, and I want to keep using the rest, I just remove that directory within Dev-CPP's options instead.

    Regardless, I can work around it fairly easily, but from a Beta/Feedback standpoint, that would be more user friendly.

    ReplyDelete
  17. Can you explain this part:

    "I also wanted to use the windows/OGL/SDI/etc that you included, but can't do that if I exclude the entire 'include' directory."

    The include folder feature isn't required at all. If you omit it, you'll only have to include files manually.

    And about moving D3D stuff to a separate folder: I could, but I'm a bit reluctant, because pretty much all MinGW builds put D3D in the root folder. I'd rather keep stuff 'standard' compliant, you see.

    ReplyDelete
  18. Perhaps I am over thinking it, but aren't the directories you add under include in the compiler options essentially places it looks for the #included headers?

    If I leave c:\Dev-CPP\include in that list, it finds the included d3d9.h header there, as well as the d3d9.h header in my DXSDK folder, and I get an error. If I remove it, it no longer finds the windows.h header in the include folder.

    Perhaps I am wrong about how Dev searches for headers, but if you added c:\Dev-CPP\include\D3D as a directory, and it contained the d3d9.h file, wouldn't it still be considered the 'root' directory and allow for #include d3d9.h?

    Sorry if this is confusing or difficult, this is a migration for me from MS Vis Studio. The way they handle it is similar, as far as search directories, but each directory you add is its own root directory for headers.

    ReplyDelete
  19. Perhaps I am over thinking it, but aren't the directories you add under include in the compiler options essentially places it looks for the #included headers?

    Yup, exactly. But the compiler toolchain will check in ..\include automatically (not very reliable though).


    Perhaps I am wrong about how Dev searches for headers, but if you added c:\Dev-CPP\include\D3D as a directory, and it contained the d3d9.h file, wouldn't it still be considered the 'root' directory and allow for #include d3d9.h?

    No, you're right. I'm indeed thinking about that folder root thing.

    It indeed looks like you either a) remove the D3D files or b) use the ones supplied by Dev-C++.

    One last question: what is the reason behind sticking to your SDX headers instead of the ones supplied in Dev-C++? You could even put your SDK ones in a special D3D folder.

    I'm sorry I won't be able to reply in the next 10 hours or so. I seriously need some sleep.

    ReplyDelete
  20. I have a few reasons for keeping my SDK versions instead of the included ones.

    First, the included files are fine if I'm just doing D3D, but I also want DirectInput and DirectSound - which I didn't see available in the included files. It's nice to not have half of my DX headers in one place and half in another, just for portability and simplicity.

    Second, there is no way to include *only* the DI and DS headers from the SDK, without removing the D3D files from the SDK (which is bad, mmkay). For example, if I include the folder that contains DI it also has the D3D headers and gives me a dupe error.

    Foreseeable ways to make it work:
    1. Delete provided D3D headers, use SDK.
    2. Delete SDK copy, use provided headers.
    3. Get crazy with the include paths. (Not a fan)

    I ended up just deleting the (i think 5) included headers that were giving me dupe errors.

    Get yourself some sleep, and enjoy the remaining holidays!

    ReplyDelete
  21. Thanks and congrats. In early 2000s Dev C++ seemed to be a very promising C++ IDE. Hundreds were migrating from Visual C++ (me too). The news of Dev C++ not being developed(literally dead) further was a disappointment . May God bless you.

    ReplyDelete