Pelles C forum
Pelles C => Announcements => Topic started by: Pelle on January 27, 2008, 08:48:48 PM
-
Pelles C version 5.0, Beta #1, is now available for download:
http://www.smorgasbordet.com/pellesc/download.htm (http://www.smorgasbordet.com/pellesc/download.htm)
Pelle
-
Great as usual, Pelle.
I'll test it the next days.
The german mirror is also updated.
-
Hi Pelle,
IDE do not start, get a message "can not load resource DLL"
May be something is missing?
Put Claude Belgium
-
Hmm... this area is unchanged from the previous version, and the same files included in the setup, with the exception that there is no French translation. Not sure what language setting you use in your Windows version, but either the program finds the old French translation and the strings in the IDE should look corrupted, or the program should default to the (new) English version. I can't explain this right now.
Any difference if you use the new /L (language) option to POIDE, something like this (for English):
poide /L 0x0409
-
I don't think it's a 5.00 bug, but if I use the 'increment build no' AddIn I have to say after rebuilding the programm that I want to reload the external changed .rc file.
Is there a possibility to change this?
-
Hmm... this area is unchanged from the previous version, and the same files included in the setup, with the exception that there is no French translation. Not sure what language setting you use in your Windows version, but either the program finds the old French translation and the strings in the IDE should look corrupted, or the program should default to the (new) English version. I can't explain this right now.
Any difference if you use the new /L (language) option to POIDE, something like this (for English):
poide /L 0x0409
Hi Pelle,
Thank you for great work. Really looking forward for new features in 5.0.
You suggestion doesn't work on my WinXPSP2 either. In fact poide picks up 0x0409 properly from regional settings. OS fails to load the language resource dlls bundled with the installation package (probably due to stripped relocations).
Here's the output from DependencyWalker profiler:
LoadLibraryW("p:\dev\pellesc5\bin\Intl\rsrc0009.dll") called from "POIDE.EXE" at address 0x00462EB1.
LDR: LdrRelocateImageWithBias() failed 0xc0000018
LDR: OldBase : 10000000
LDR: NewBase : 03B80000
LDR: Diff : 0x7c90dec20022ed60
LDR: NextOffset : 00000000
LDR: *NextOffset : 0x0
LDR: SizeOfBlock : 0x3b80000
LoadLibraryW("p:\dev\pellesc5\bin\Intl\rsrc0009.dll") returned NULL. Error: Attempt to access invalid address (487).
-
Hi Pelle,
Did start this way: poide /L 0x0409 , but get the same message "unable to load resource DLL(RSRCnnnn.DLL)"
Your suggestion doesn't work on my WinXP pro SP2 .
Reloaded the old version version, and this did work again ( but looses all my old initiates :-) )
Put Claude Belgium
-
Hi Pelle,
Thank you for v5.00, I especially like the x64 support (among with ARM).
I am using the system on Windows Server 2003 R2 x64 Enterprise, where I am trying to compile some simple and some not-so-simple C command line programs (some utilities I wrote for my servers), in order to produce pure x64 binaries.
On some projects, they compile fine but POLINK keeps asking for a uuid.lib when creating an x64 single-threaded executable. The 32-bit PellesC lib directory has this file but the 64-bit not.
Sorry for asking - might be a stupid question - but is this file missing or there is something else wrong with my code?
Many thanks in advance.
-
@Christian: I will look at it. The reload feature is enhanced in this version, but the add-in is unchanged. Maybe the add-in can be modified, but IIRC the resource script is actually modified so I'm not sure right now...
@stepw: It works on my old XP machine (I don't remember the service pack version right now), so it's a little strange, but having an (almost) empty base relocation section may make a difference. I have added this to all resource dll's and put them in intl.zip (for the Intl subdirectory). Any difference...?
http://www.smorgasbordet.com/pellesc/junk/intl.zip (http://www.smorgasbordet.com/pellesc/junk/intl.zip)
@Frontier: Yes, I have missed to include uuid.lib for X64 in the distribution. I have attached it in uuidlib64.zip - does it work now?
http://www.smorgasbordet.com/pellesc/junk/uuidlib64.zip (http://www.smorgasbordet.com/pellesc/junk/uuidlib64.zip)
-
Hi Pelle,
Did replace the rsrc0009.dll and it works perfect now...
Thanks a lot,
Put Claude Belgium
-
Hi Pelle,
POLINK no longer asks for uuid.lib (after placing the file you provided in Win64 directory) but now asks for file odbccp32.lib.
May I ask if you are building PellesC agains Windows Vista SDK without support for earlier platforms?
It's kinda odd since I am using also Vista SDK under Windows Server 2003 without problems.
Update: I copied the file odbccp32.lib from the Vista SDK x64 libraries folder into PellesC Win64 folder and my program compiled OK.
I do not know however the consequences of doing this, but I hope that the Vista SDK library is compatible with the format POLINK supports.
Anyway, you need to include these two files in a future install of PellesC for x64; however, you've done an excellent job providing an alternate x64 compiler for Windows.
Thank you :)
-
@Claudy: very good, thanks for the info.
@Frontier: I have a copy of the Vista SDK as reference, but never use it to build anything. I use my own (include) files, and even though some of them contains #pragma comment(lib, ...) for the libraries you are mentioning, I never seem to include those files - directly or indirectly. Example: odbccp32.lib will only be referenced if odbcinst.h is included directly, and the special symbol WIN32_DEFAULT_LIBS is also defined. It is a bug that odbccp32.lib is not included, but as it seems (right now) you have to put some effort into exposing this bug.
Yes, the Vista SDK files should be compatible with Pelles C.
-
@Christian: I have looked at the 'increment build number' sample. Yes, it doesn't work great if you keep the resource script open during a build. Adding code to update the loaded version (when it is in fact loaded) will create a much larger sample - not so good. Closing the affected resource window before the build seems unfriendly. The reload question is supposed to avoid problems overwriting a newer file (on disk) with an older file (in memory), so having an option to turn this feature off is probably dangerous. Since the 'increment build number' add-in is just a sample after all, maybe leave it 'as is' for now...? Do you have any other ideas...?
-
Hello
I have tried it and it is again very nice and good. I like it.
Things which make me not so happy are:
1.) In Application Data I have not the to let there the "sysdefs.tag"-file. :(
I have movedit in the bin-directory from Pelles C and it works there also. :)
So it is ok for me, but i wished to have the choice where to create it. ;)
2.) I missed the msvcrt.lib :(
-
@AlexN:
1) Not sure I understand your problem with Application Data; seems to be a recommended place by Microsoft. At least there should be no data files under "Program files". Having the user select the location will most likely cause many more problems than it will solve.
2) Including msvcrt.lib would give the illusion that I actually support linking to this file, which I of course don't. Link to a Microsoft runtime if you like, but you are completely on your own - I can't help if it fails...
-
Looks good, haven't seen any problems yet, thanks Pelle.
John
-
@JohnF: Thanks, good to know.
-
@AlexN:
1) Not sure I understand your problem with Application Data; seems to be a recommended place by Microsoft. At least there should be no data files under "Program files". Having the user select the location will most likely cause many more problems than it will solve.
My problem with this place is, that at a shutdown of my computer, the profile datas are stored on a server (so you can login on another computer in your domain and you have there your own profile). And the stored datas include the files in "Application Data". The place an the server is limited to 24MB. So 50-100MB are to much for this limit.
But as long Pelles C works with moved sysdefs.tag, it is not a realy a problem for me and I don't know whether other have a similar problem.
-
Hi Pelle:
Thank you for the many additions that you have made to the compiler and tools and as well for the production of a 64 bit version. Your great efforts are appreciated.
Robert Wishlaw
-
Thank you Pelle!
Pelles C 5.0 Beta works perfectly with BCX.
BCX is > 30,000 lines of code, so that should give you some confidence in 5.0.
I can't wait until I have a 64 bit PC to play with ;-)
-
@Robert, @MrBcx: thank you both - appreciated!
Yes, 64 bits is pretty cool - even small things like a single calling convention and no decorated names makes it a little easier to work with...
-
Wonderful! Excellent update, thanks Pelle!
Wikipedia article updated.
-
This is great update!
Pelles C tools keep getting better and better!
Until now, no problem with the beta version! I'll keep testing it more.
Thanks
EDIT: I think I found a bug when trying to compile this ADDIN: http://forum.pellesc.de/index.php?topic=471.15
EDIT2: Hi Pelle! I fixed the bug by putting a comment at the line 987: //typedef ADDIN_FIND_IN_FILES_A ADDIN_FIND_IN_FILES; in the include\addin.h file.
-
@Ben_pcc: thanks!
@Freddy: thanks - yes, that line should be removed from addin.h (it only affects ANSI builds, and I only tested new UNICODE builds).