"Elf" questions
"Elf" questions
What kind of binary file format is better to use?
I want one with recurses like the PE format, doesn't ELF has support for Icon, Bitmaps and stuff like that?
I want one with recurses like the PE format, doesn't ELF has support for Icon, Bitmaps and stuff like that?
- Steve the Pirate
- Member
- Posts: 152
- Joined: Fri Dec 15, 2006 7:01 am
- Location: Brisbane, Australia
- Contact:
Do you mean resources?
I'm not sure if you can by default, but I did find this in a quick google search: http://ktown.kde.org/~frerich/elfrc.html
I'm not sure if you can by default, but I did find this in a quick google search: http://ktown.kde.org/~frerich/elfrc.html
- Dandee Yuyo
- Member
- Posts: 47
- Joined: Fri Nov 09, 2007 6:46 pm
- Location: Argentina
ELF does not support windows-style "resources" because they are inherently GUI orientated, and ELF is an executable format - it has nothing to do with GUIs!
AFAIK most linux environments provide a list of custom icons that are 'assigned' to a particular file. Why do you need resources? I wouldn't let things like icons sway your decision on which file format to use because in all honesty, most osdevers never even get a GUI up and running.
If you're designing a windows-like system, with .dlls etc, use PE because it supports dlls.
If you're making a unix-like system with shared objects/libraries (.so) then use ELF because it supports shared objects.
I can't think of any situation where using a flat binary is advantageous.
You can always just make a format up yourself!
AFAIK most linux environments provide a list of custom icons that are 'assigned' to a particular file. Why do you need resources? I wouldn't let things like icons sway your decision on which file format to use because in all honesty, most osdevers never even get a GUI up and running.
If you're designing a windows-like system, with .dlls etc, use PE because it supports dlls.
If you're making a unix-like system with shared objects/libraries (.so) then use ELF because it supports shared objects.
I can't think of any situation where using a flat binary is advantageous.
You can always just make a format up yourself!
oh, yeah... I was meaning resources =]Do you mean resources?
I'm not sure if you can by default, but I did find this in a quick google search: http://ktown.kde.org/~frerich/elfrc.html
So... I guess that I'll have to make a modification of the ELF format....
That's not so good =//
Thank you everybody
and sorry for my poor english
That has got to be one of the least informed opinions I've read in any recent year. They're executable formats and they define chunks of memory to be loaded, addresses in that memory and lengths of blocks in that memory. That's all they do - DLLs are equal to SOs. The only difference is that the dynamic linked library for PE is called a DLL and a dynamic linked library for ELF is called an SO file.JamesM wrote:If you're designing a windows-like system, with .dlls etc, use PE because it supports dlls.
If you're making a unix-like system with shared objects/libraries (.so) then use ELF because it supports shared objects.
- Dandee Yuyo
- Member
- Posts: 47
- Joined: Fri Nov 09, 2007 6:46 pm
- Location: Argentina
Well, I have no experience with the ELF file format, however I read the spec.
One thing grabbed my attention: There's a mention of OpenGL copyright, but not mention of it in the rest of the document.
Anyway, it supports dynamic-linking. So you can declare your own '.res' (you name it) SHT_PROGBITS section with a neat table for resources.
Due to my experience with Windoze, Mac OSes, the game industry (where resources or "assets" are used all the time) and even with the BREW mobile platform, I have a clear idea of what I expect from "resources":
* Some predefined resource types, UTF-8 string tables, at least.
* The ability to define "custom" resource types
* The ability to enumerate them and know what they type is.
* Multilingual support
That's why I'm saying that this "rcelf" tool is not compiling resources, just embedding plain arrays.
a+;
One thing grabbed my attention: There's a mention of OpenGL copyright, but not mention of it in the rest of the document.
Anyway, it supports dynamic-linking. So you can declare your own '.res' (you name it) SHT_PROGBITS section with a neat table for resources.
Due to my experience with Windoze, Mac OSes, the game industry (where resources or "assets" are used all the time) and even with the BREW mobile platform, I have a clear idea of what I expect from "resources":
* Some predefined resource types, UTF-8 string tables, at least.
* The ability to define "custom" resource types
* The ability to enumerate them and know what they type is.
* Multilingual support
That's why I'm saying that this "rcelf" tool is not compiling resources, just embedding plain arrays.
a+;
NaN - Not a Nerd
Working on: Physical Memory Management with a 5-lod mipmap XD
Working on: Physical Memory Management with a 5-lod mipmap XD
Why thank you! I have to admit, I don't know much about PE. I was lifting what I wrote directly from another thread (I forget which one) where people more informed than me were discussing it. IIRC (and possibly I don't) there were some windows-isms which were supported in PE but done differently in ELF.Candy wrote:That has got to be one of the least informed opinions I've read in any recent year. They're executable formats and they define chunks of memory to be loaded, addresses in that memory and lengths of blocks in that memory. That's all they do - DLLs are equal to SOs. The only difference is that the dynamic linked library for PE is called a DLL and a dynamic linked library for ELF is called an SO file.JamesM wrote:If you're designing a windows-like system, with .dlls etc, use PE because it supports dlls.
If you're making a unix-like system with shared objects/libraries (.so) then use ELF because it supports shared objects.
- AndrewAPrice
- Member
- Posts: 2309
- Joined: Mon Jun 05, 2006 11:00 pm
- Location: USA (and Australia)
I think, a program should not embed it's resources into it's executable file. (An exception is an installer which is convenient since you only have to distribute one file.)
I wouldn't embed icons into an executable file. I would place them in a seperate file and let my GUI manager let me assign icons to desktop and menu shortcuts which are stored in different files. I would much rather the icon in my file manager to be representative of the type of file (e.g. all programs have an icon of a cog (KDE) or a window (console programs in Windows)).
I wouldn't embed icons into an executable file. I would place them in a seperate file and let my GUI manager let me assign icons to desktop and menu shortcuts which are stored in different files. I would much rather the icon in my file manager to be representative of the type of file (e.g. all programs have an icon of a cog (KDE) or a window (console programs in Windows)).
My OS is Perception.