www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - resources

reply "Andrew Fedoniouk" <news terrainformatica.com> writes:
Resources are chunks of binary or textual data resides in the body of 
executable file. Code of executable
can get a read only access to them - similar to access to staticly 
initialized constants/variables.

I think that D should have a unified (cross-platform) way to deal with 
resources.
As an one possible idea could be to use special version of 'import' keyword 
with notation similar to cast()

//example

ubyte[] TopCornerPng = import(myproject.res.images.filename.png);
char[] MainStyleCss = import(myproject.res.layout.style.css);
char[] MainLayout = import(myproject.res.layout.style.htm);

// another one

Object[char[]] res;
gRes["logo"] = import(myproject.res.images.logo.png);
gRes["icon"] = import(myproject.res.images.icon.ico);
gRes["small-icon"] = import(myproject.res.images.smallicon.ico);
gRes["about-text"] = cast(char[]) import(myproject.res.about.txt);

Any comments or other ideas?
Mar 05 2005
next sibling parent reply zwang <nehzgnaw gmail.com> writes:
I like the idea, but I think it's better to implement a std.res.loadResource
function rather than to change the D grammar.


Andrew Fedoniouk wrote:

 Resources are chunks of binary or textual data resides in the body of 
 executable file. Code of executable
 can get a read only access to them - similar to access to staticly 
 initialized constants/variables.
 
 I think that D should have a unified (cross-platform) way to deal with 
 resources.
 As an one possible idea could be to use special version of 'import' keyword 
 with notation similar to cast()
 
 //example
 
 ubyte[] TopCornerPng = import(myproject.res.images.filename.png);
 char[] MainStyleCss = import(myproject.res.layout.style.css);
 char[] MainLayout = import(myproject.res.layout.style.htm);
 
 // another one
 
 Object[char[]] res;
 gRes["logo"] = import(myproject.res.images.logo.png);
 gRes["icon"] = import(myproject.res.images.icon.ico);
 gRes["small-icon"] = import(myproject.res.images.smallicon.ico);
 gRes["about-text"] = cast(char[]) import(myproject.res.about.txt);
 
 Any comments or other ideas?
Mar 05 2005
parent "Andrew Fedoniouk" <news terrainformatica.com> writes:
I like the idea, but I think it's better to implement a 
std.res.loadResource
 function rather than to change the D grammar.


Just one question: from where will [std.res.]loadResource ?
On Win32 and on Linux?

It is possible to do now following:

ubyte[1020] myRes = [
  0xFD, 0xFA, 0xBC, .....
];

but it is not so convenient  - same chunks of information stored in two 
places

There are probably more options similar to D code embedded inside HTML.
Hmm... Seems like too wild idea...
Mar 05 2005
prev sibling next sibling parent reply =?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= <afb algonet.se> writes:
Andrew Fedoniouk wrote:


 Resources are chunks of binary or textual data resides in the body of 
 executable file. Code of executable
 can get a read only access to them - similar to access to staticly 
 initialized constants/variables.


As a side note, resources on Mac OS X are stored in a sub-directory...

Program.app/
     Contents/
         MacOS/
             Program (<-- this is the executable)
         Resources/
             Program.rsrc (<-- these are resources)
             English.lproj/
                  Localized.rsrc	
             sv.lproj/
                  Localized.rsrc	

Having a loadResource function would still work fine here too, though.

--anders
Mar 05 2005
next sibling parent reply "Andrew Fedoniouk" <news terrainformatica.com> writes:
 Resources are chunks of binary or textual data resides in the body of 
 executable file. Code of executable
 can get a read only access to them - similar to access to staticly 
 initialized constants/variables.


 As a side note, resources on Mac OS X are stored in a sub-directory...

 Program.app/
     Contents/
         MacOS/
             Program (<-- this is the executable)
         Resources/
             Program.rsrc (<-- these are resources)
             English.lproj/
                  Localized.rsrc sv.lproj/
                  Localized.rsrc
 Having a loadResource function would still work fine here too, though.

 --anders


Anders, I think you've missed my point:
chunks of binary or textual data resides in *the body executable file*

Having "resources" as separate files introduces some problems.
When you have simple GUI app and resources inside you don't need
any unstallation - just copy-n-run.

GUI apps use not only strings but also icons and html and other
"graphical" data. It make sense to bind them into exe as they are
parts of such exe as code, data and "resource" sections.
Mar 06 2005
next sibling parent reply =?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= <afb algonet.se> writes:
Andrew Fedoniouk wrote:


 Anders, I think you've missed my point:
 chunks of binary or textual data resides in *the body executable file*
 
 Having "resources" as separate files introduces some problems.
 When you have simple GUI app and resources inside you don't need
 any unstallation - just copy-n-run.


Mac OS X handles bundles (which are just "special" directories)
in the same manner that it does files. So you just drag .apps...


 GUI apps use not only strings but also icons and html and other
 "graphical" data. It make sense to bind them into exe as they are
 parts of such exe as code, data and "resource" sections.


The ".rsrc" listed was just a blanket term for heaps of such files.
See http://developer.apple.com/documentation/ for loads of docs...


 And one more, Anders:
 
 Let's say application A uses two libraries GUI-component-B and
 GUI-component-C


These two would be "Frameworks", under Mac OS X. These entities
can contain both libraries, headers and also resource files...


 These two have its own resources (e.g. images) so maintaining
 the following:
 

 Program.app/
     Contents/




 
 is a problem. I mean distribution and dependencies management.


Disk space is cheap, so Mac OS X just makes each application
have one copy of the (indentical) frameworks. Avoids DLL hell.

--anders
Mar 06 2005
parent reply "Andrew Fedoniouk" <news terrainformatica.com> writes:
 Disk space is cheap, so Mac OS X just makes each application
 have one copy of the (indentical) frameworks. Avoids DLL hell.


Probably yes, but for some aesthetical reasons I don't like to have
something simple as Calculator.exe as a bunch of files instead of one.

I would like to have it mono exectable just to be able to copy it on
e.g. USB drive and carry it with me.

And yet I am not speaking about DLLs.
Somthing like MyCoolButton.d which use some graphics
could be compiled *together* with such graphics avoiding of creation
of resx and folders - MyCoolButton package/module could be made
self sufficient.

I am not speaking of elimination of .res . They needed for e.g. defining
application icon on Win32. My posts rather about component modularity than
about anything else.

Self contained executables are lessly coupled with underlying OS and 
particular
machine. Which is extremely good.

Andrew Fedoniouk.
Mar 06 2005
parent reply =?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= <afb algonet.se> writes:
Andrew Fedoniouk wrote:


Disk space is cheap, so Mac OS X just makes each application
have one copy of the (indentical) frameworks. Avoids DLL hell.


 
 Probably yes, but for some aesthetical reasons I don't like to have
 something simple as Calculator.exe as a bunch of files instead of one.


Yes, that sounds great for a Windows application. And it would work
the same as "Calculator.app" would work on Mac OS X (shows as 1 icon)


 I would like to have it mono exectable just to be able to copy it on
 e.g. USB drive and carry it with me.


When you drag the application to the drive, it copies the entire dir.
When downloading the app from the net, it's a Zip or Disk image file.


 Self contained executables are lessly coupled with underlying OS and 
 particular machine. Which is extremely good.


It was just a side note, really, that Mac OS X uses "bundles" instead
of files to package applications and frameworks. They're very similar.


For a cross-platform way of packaging several files into one archive,
I heartily recommend using .zip files. Compression and checksums, too.

I'm guessing you could pack such a zipfile into the EXE on Windows ?
(with Java, it's all in the same .jar and with Mac it goes in Resources)

--anders
Mar 06 2005
parent reply "Matthew" <admin stlsoft.dot.dot.dot.dot.org> writes:
I like the one-file thing. Maybe D apps on systems that require a bundle 
could auto-un-bundle on first run??

"Anders F Björklund" <afb algonet.se> wrote in message 
news:d0fpuv$nhv$1 digitaldaemon.com...

 Andrew Fedoniouk wrote:


Disk space is cheap, so Mac OS X just makes each application
have one copy of the (indentical) frameworks. Avoids DLL hell.


 Probably yes, but for some aesthetical reasons I don't like to have
 something simple as Calculator.exe as a bunch of files instead of 
 one.


 Yes, that sounds great for a Windows application. And it would work
 the same as "Calculator.app" would work on Mac OS X (shows as 1 icon)


 I would like to have it mono exectable just to be able to copy it on
 e.g. USB drive and carry it with me.


 When you drag the application to the drive, it copies the entire dir.
 When downloading the app from the net, it's a Zip or Disk image file.


 Self contained executables are lessly coupled with underlying OS and 
 particular machine. Which is extremely good.


 It was just a side note, really, that Mac OS X uses "bundles" instead
 of files to package applications and frameworks. They're very similar.


 For a cross-platform way of packaging several files into one archive,
 I heartily recommend using .zip files. Compression and checksums, too.

 I'm guessing you could pack such a zipfile into the EXE on Windows ?
 (with Java, it's all in the same .jar and with Mac it goes in 
 Resources)

 --anders
Mar 06 2005
next sibling parent =?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= <afb algonet.se> writes:
Matthew wrote:


When downloading the app from the net, it's a Zip or Disk image file.





 I like the one-file thing. Maybe D apps on systems that require a bundle 
 could auto-un-bundle on first run??


That's what the system does, when you open a .ZIP or .DMG file...

--anders
Mar 06 2005
prev sibling parent "Andrew Fedoniouk" <news terrainformatica.com> writes:
"Matthew" wrote:

I like the one-file thing. Maybe D apps on systems that require a bundle 
could auto-un-bundle on first run??


I don't think that we need to "auto-un-bundle". What for?
Resources are there, just use them.
Did I miss something "en principle" in this peculiar OSX.app bundling?

Andrew.
Mar 06 2005
prev sibling parent reply Derek Parnell <derek psych.ward> writes:
On Sun, 6 Mar 2005 09:11:43 -0800, Andrew Fedoniouk wrote:


 Resources are chunks of binary or textual data resides in the body of 
 executable file. Code of executable
 can get a read only access to them - similar to access to staticly 
 initialized constants/variables.


 As a side note, resources on Mac OS X are stored in a sub-directory...

 Program.app/
     Contents/
         MacOS/
             Program (<-- this is the executable)
         Resources/
             Program.rsrc (<-- these are resources)
             English.lproj/
                  Localized.rsrc sv.lproj/
                  Localized.rsrc
 Having a loadResource function would still work fine here too, though.

 --anders


 
 Anders, I think you've missed my point:
 chunks of binary or textual data resides in *the body executable file*
 
 Having "resources" as separate files introduces some problems.
 When you have simple GUI app and resources inside you don't need
 any unstallation - just copy-n-run.
 
 GUI apps use not only strings but also icons and html and other
 "graphical" data. It make sense to bind them into exe as they are
 parts of such exe as code, data and "resource" sections.


Not so long ago, I wrote a simple GUI app for a client. Soon after
receiving it, they asked for different images to be used. But by then,
another client was also using the app. So, the best solution was for me to
separate the icons, images, etc... (the UI skin) from the application.

-- 
Derek Parnell
Melbourne, Australia
7/03/2005 7:23:03 AM
Mar 06 2005
parent reply "Andrew Fedoniouk" <news terrainformatica.com> writes:
 Not so long ago, I wrote a simple GUI app for a client. Soon after
 receiving it, they asked for different images to be used. But by then,
 another client was also using the app. So, the best solution was for me to
 separate the icons, images, etc... (the UI skin) from the application.


Hi, Derek,
This approach does not prevent you from using different skins as a system
of external files. It is up to you what to *choose*...

IMO, real skin engine demands not only static resources but also some
code to be changed. So it is better to be able to pack themes into DLLs.
And here comes import(...) again.

Huh?

Andrew Fedoniouk.
Mar 06 2005
parent reply Derek Parnell <derek psych.ward> writes:
On Sun, 6 Mar 2005 13:48:32 -0800, Andrew Fedoniouk wrote:


 Not so long ago, I wrote a simple GUI app for a client. Soon after
 receiving it, they asked for different images to be used. But by then,
 another client was also using the app. So, the best solution was for me to
 separate the icons, images, etc... (the UI skin) from the application.


 
 Hi, Derek,
 This approach does not prevent you from using different skins as a system
 of external files.


I know...that is what I did. The resources are now stored in files that are
not the executable files. The resources are applied to the application at
run time, and not at compile time.


 It is up to you what to *choose*...


Maybe I'm misunderstanding you, but actually it is up to the customer to
choose the look and feel.


 IMO, real skin engine demands not only static resources but also some
 code to be changed.


That was not my experience. I documented the structure and nature of the
skin files, and the client has created their own skins. The client was
major US based hardware manufacturer and they are reselling the application
under different 'brandings'. 


 So it is better to be able to pack themes into DLLs.
 And here comes import(...) again.


But I suppose if they could have packed them into a DLL via compiling a
specialized D program. That would have worked too.

-- 
Derek
Melbourne, Australia
7/03/2005 9:14:59 AM
Mar 06 2005
parent "Andrew Fedoniouk" <news terrainformatica.com> writes:
 It is up to you what to *choose*...


 Maybe I'm misunderstanding you, but actually it is up to the customer to
 choose the look and feel.


I mean developer can choose proper way of how to embed resources.
Some components has to have fixed resourses other rely on skins.
But again what will happen if someone will delete one piece of your
system of resourses (skin/theme)?

Nothing new here but general principle is to wrap theme/skin into one
zip file or, which is better, in solid DLL. Just in case.
When you are getting 20000 customers then probability that someone
will remove .png or .bmp is high. Like in Windows
"Search all PNGs on C:\ -> Delete". Easy.

Yes there are use cases when customers need to modify their themes
but this is a rare case. IMO of course.

Andrew.
Mar 06 2005
prev sibling parent "Andrew Fedoniouk" <news terrainformatica.com> writes:
And one more, Anders:

Let's say application A uses two libraries GUI-component-B and
GUI-component-C

These two have its own resources (e.g. images) so maintaining
the following:


 Program.app/
     Contents/
         MacOS/
             Program (<-- this is the executable)
         Resources/
             Program.rsrc (<-- these are resources)
             English.lproj/
                  Localized.rsrc sv.lproj/
                  Localized.rsrc


is a problem. I mean distribution and dependencies management.
Mar 06 2005
prev sibling next sibling parent reply "G.Vidal" <gyvidal wanadoo.fr> writes:
Hello !

I come back again with my plugin idea. (yes I really like it, please go to
the thread for more informations)

Let create a "ressource" plugin that takes any binary file and convert it
into an array of char: char[size] stuff = 0x784, 0x765, 0x.... etc


Then We write:

pragma(plugin,ressource) {
	image = ../images/im.png
        text  = ../text/text.txt
}

Or something similar.
Now we can use the variables image and text.
Easy and convinient.

G.VIDAL







Le Sat, 05 Mar 2005 18:42:04 -0800, Andrew Fedoniouk a écrit :


 Resources are chunks of binary or textual data resides in the body of 
 executable file. Code of executable
 can get a read only access to them - similar to access to staticly 
 initialized constants/variables.
 
 I think that D should have a unified (cross-platform) way to deal with 
 resources.
 As an one possible idea could be to use special version of 'import' keyword 
 with notation similar to cast()
 
 //example
 
 ubyte[] TopCornerPng = import(myproject.res.images.filename.png);
 char[] MainStyleCss = import(myproject.res.layout.style.css);
 char[] MainLayout = import(myproject.res.layout.style.htm);
 
 // another one
 
 Object[char[]] res;
 gRes["logo"] = import(myproject.res.images.logo.png);
 gRes["icon"] = import(myproject.res.images.icon.ico);
 gRes["small-icon"] = import(myproject.res.images.smallicon.ico);
 gRes["about-text"] = cast(char[]) import(myproject.res.about.txt);
 
 Any comments or other ideas?
Mar 06 2005
parent reply "Andrew Fedoniouk" <news terrainformatica.com> writes:
Yep, this pretty much the same idea.
But mine is simpler from 1) implementation point of view and
2) allows to define comples structures like:

struct ToolbarImgDef
{
   int         iconWidth;
   int         iconHeight;
   ubyte[]  png;
 }

static ToolbarImgDef mainTbDef = { 16, 15, import(mytoolbar.png)  }
Toolbar mainTb = new Toolbar(mainTbDef);

Idea of plugins is good in fact. But for most cases it would be
enough to implement something extremely simple as import(mytoolbar.png)

Andrew.






"G.Vidal" <gyvidal wanadoo.fr> wrote in message 
news:pan.2005.03.06.09.38.53.693865 wanadoo.fr...

 Hello !

 I come back again with my plugin idea. (yes I really like it, please go to
 the thread for more informations)

 Let create a "ressource" plugin that takes any binary file and convert it
 into an array of char: char[size] stuff = 0x784, 0x765, 0x.... etc


 Then We write:

 pragma(plugin,ressource) {
 image = ../images/im.png
        text  = ../text/text.txt
 }

 Or something similar.
 Now we can use the variables image and text.
 Easy and convinient.

 G.VIDAL







 Le Sat, 05 Mar 2005 18:42:04 -0800, Andrew Fedoniouk a écrit :


 Resources are chunks of binary or textual data resides in the body of
 executable file. Code of executable
 can get a read only access to them - similar to access to staticly
 initialized constants/variables.

 I think that D should have a unified (cross-platform) way to deal with
 resources.
 As an one possible idea could be to use special version of 'import' 
 keyword
 with notation similar to cast()

 //example

 ubyte[] TopCornerPng = import(myproject.res.images.filename.png);
 char[] MainStyleCss = import(myproject.res.layout.style.css);
 char[] MainLayout = import(myproject.res.layout.style.htm);

 // another one

 Object[char[]] res;
 gRes["logo"] = import(myproject.res.images.logo.png);
 gRes["icon"] = import(myproject.res.images.icon.ico);
 gRes["small-icon"] = import(myproject.res.images.smallicon.ico);
 gRes["about-text"] = cast(char[]) import(myproject.res.about.txt);

 Any comments or other ideas?
Mar 06 2005
parent "G.Vidal" <gyvidal wanadoo.fr> writes:
Pwet Pwet Pwet....

pragma(plugin,ressource) { im = mytoolbar.png }
static ToolbarImgDef mainTbDef = { 16, 15, im }

Not so bad too ! and we don't need to add another import keyword in the D
grammar set.
Mar 06 2005
prev sibling parent reply Ben Hinkle <Ben_member pathlink.com> writes:
In article <d0dqov$1v7f$1 digitaldaemon.com>, Andrew Fedoniouk says...

Resources are chunks of binary or textual data resides in the body of 
executable file. Code of executable
can get a read only access to them - similar to access to staticly 
initialized constants/variables.

I think that D should have a unified (cross-platform) way to deal with 
resources.
As an one possible idea could be to use special version of 'import' keyword 
with notation similar to cast()

//example

ubyte[] TopCornerPng = import(myproject.res.images.filename.png);
char[] MainStyleCss = import(myproject.res.layout.style.css);
char[] MainLayout = import(myproject.res.layout.style.htm);

// another one

Object[char[]] res;
gRes["logo"] = import(myproject.res.images.logo.png);
gRes["icon"] = import(myproject.res.images.icon.ico);
gRes["small-icon"] = import(myproject.res.images.smallicon.ico);
gRes["about-text"] = cast(char[]) import(myproject.res.about.txt);

Any comments or other ideas?


Resources are usually pretty platform-specific so MinWin only handles string
(for i18n) and image resources. Resources are looked up by string key. Strings
are loaded using a method of the Application object. Since images in MinWin are
device-dependent images are loaded using a method on the GContext object
(HDC/GC/GdkGC).

Are there problem with such a system that your proposal would fix? I don't see
why having functions load data is a problem. Multiple functions also let you
avoid cast(char[]).

-Ben
Mar 06 2005
parent reply "Andrew Fedoniouk" <news terrainformatica.com> writes:
 Resources are usually pretty platform-specific so MinWin only handles 
 string
 (for i18n) and image resources. Resources are looked up by string key. 
 Strings
 are loaded using a method of the Application object. Since images in 
 MinWin are
 device-dependent images are loaded using a method on the GContext object
 (HDC/GC/GdkGC).

 Are there problem with such a system that your proposal would fix? I don't 
 see
 why having functions load data is a problem. Multiple functions also let 
 you
 avoid cast(char[]).


"Resources are usually pretty platform-specific..."

Yes, sometimes.

But let's take a closer look:

Strings are the same.
Text and its various forms - html, css, etc. also the same.
Images could be also unified - e.g. ppm data (24bpp and 32bpp) could be 
mapped into win32::DIB section one-to-one.
For gif, png and jpg I am going to create "standard".lib module for D which 
will include gif/png/jpg loading/saving.

My J-SMILE demo uses following structure of EXE:
It is a bundle of concatenated items - EXE file by itself :

j-smile-vm.exe,
"classname1" classname2.class
"classname2" classname2.class
"imagefile1" imagefile1.png
"htmlfile1" htmlfile1.htm
Loading of resources is a part of builtin ClassLoader. Very convenient.

If we will have import(filename) in D it will extend concept even further: 
resource
definitions can be organized in structures and arrays and addresed very 
effectively.
Mar 06 2005
parent reply "Asaf Karagila" <kas1 netvision.net.il> writes:
I don't post here regularly, nor i am an expert in programming, or in D.
you guys keep talking about how resources differs between windows, linux, 
fbsd, osx, etc..
but did it occur to you that the binary headers are differents between those 
as well ?
windows uses PE,
linux and fbsd use ELF,
i don't really know what OSX uses..
but there is a difference. so instead of using something like MS's .rc 
format,
which is pretty damn simple, or even inventing a new format and compiler for 
that,
and inside the different binary headers codes, just add the resources 
handling for each OS
as needed.

it's that simple...

- Asaf.
Mar 07 2005
next sibling parent reply =?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= <afb algonet.se> writes:
Asaf Karagila wrote:


 you guys keep talking about how resources differs between windows, linux, 
 fbsd, osx, etc..
 but did it occur to you that the binary headers are differents between those 
 as well ?
 windows uses PE,
 linux and fbsd use ELF,
 i don't really know what OSX uses..


Mac OS X uses "Mach-O", usually (there's also a PEF / CFM legacy format
from Mac OS 9 that works too, but is less and less used for new stuff)

Resources are different on Mac, too. They are either kept in a separate
"fork" of the file, or kept in a separate file from the executable...


They are hardly ever kept in the same file as the program code itself.

This is actually a good thing, since it makes them editable by people
other than programmers - using old ResEdit or new Interface Builder...

--anders
Mar 07 2005
parent reply "Andrew Fedoniouk" <news terrainformatica.com> writes:
Anders, again, I am not speaking about OS resources.

I am speaking about simple static initializers.
I would like to be able to say:

static byte[] FFTable = import(....my.binary.module.name....);
instead of writing it as constants in-line.

As a rule such external "resources" (files) has special
applications to deal with them.
So import(....my.binary.module.name....); is just
a user friendly method to initialize statics using external
files.

No one language has now such feature (binary inclusion).
If D would have this it will denefit D and us and attracts more of
us to it.

Andrew.




"Anders F Björklund" <afb algonet.se> wrote in message 
news:d0i8af$2ig$1 digitaldaemon.com...

 Asaf Karagila wrote:


 you guys keep talking about how resources differs between windows, linux, 
 fbsd, osx, etc..
 but did it occur to you that the binary headers are differents between 
 those as well ?
 windows uses PE,
 linux and fbsd use ELF,
 i don't really know what OSX uses..


 Mac OS X uses "Mach-O", usually (there's also a PEF / CFM legacy format
 from Mac OS 9 that works too, but is less and less used for new stuff)

 Resources are different on Mac, too. They are either kept in a separate
 "fork" of the file, or kept in a separate file from the executable...


 They are hardly ever kept in the same file as the program code itself.

 This is actually a good thing, since it makes them editable by people
 other than programmers - using old ResEdit or new Interface Builder...

 --anders
Mar 07 2005
next sibling parent reply MicroWizard <MicroWizard_member pathlink.com> writes:
Does this issue really need so much posts?

I wrote a resource binder and loader utility/class set in C++
when I wrote a simple game years ago. It was roughly 200/100 lines.
D is much more efficient, as I experienced.

If anyone really need it, then he/she will surely write it.
Not an issue handled by the language, IMHO.

(If you make the resource data by an external program, you
also should bare the existence of an external binding utility.)

Tamas Nagy

In article <d0ied6$a5a$1 digitaldaemon.com>, Andrew Fedoniouk says...

Anders, again, I am not speaking about OS resources.

I am speaking about simple static initializers.
I would like to be able to say:

static byte[] FFTable = import(....my.binary.module.name....);
instead of writing it as constants in-line.

As a rule such external "resources" (files) has special
applications to deal with them.
So import(....my.binary.module.name....); is just
a user friendly method to initialize statics using external
files.

No one language has now such feature (binary inclusion).
If D would have this it will denefit D and us and attracts more of
us to it.

Andrew.




"Anders F Björklund" <afb algonet.se> wrote in message 
news:d0i8af$2ig$1 digitaldaemon.com...

 Asaf Karagila wrote:


 you guys keep talking about how resources differs between windows, linux, 
 fbsd, osx, etc..
 but did it occur to you that the binary headers are differents between 
 those as well ?
 windows uses PE,
 linux and fbsd use ELF,
 i don't really know what OSX uses..


 Mac OS X uses "Mach-O", usually (there's also a PEF / CFM legacy format
 from Mac OS 9 that works too, but is less and less used for new stuff)

 Resources are different on Mac, too. They are either kept in a separate
 "fork" of the file, or kept in a separate file from the executable...


 They are hardly ever kept in the same file as the program code itself.

 This is actually a good thing, since it makes them editable by people
 other than programmers - using old ResEdit or new Interface Builder...

 --anders
Mar 07 2005
parent reply "Andrew Fedoniouk" <news terrainformatica.com> writes:
 I wrote a resource binder and loader utility/class set in C++


:) I wrote enough stuff in C++, shall I stick with it further and don't 
touch D?

dmd as a compiler suite does not have .rc compiler.
Proposed simple solution eliminates it at major extent.

It is possible to produce .res file "manualy" to include simple version info 
and one icon (for Win32).
Other resurces could be handled by import() and btw in better way than 
.rc/.res

Andrew Fedoniouk.
http://terrainformatica.com



"MicroWizard" <MicroWizard_member pathlink.com> wrote in message 
news:d0io78$ks4$1 digitaldaemon.com...

 Does this issue really need so much posts?

 I wrote a resource binder and loader utility/class set in C++
 when I wrote a simple game years ago. It was roughly 200/100 lines.
 D is much more efficient, as I experienced.

 If anyone really need it, then he/she will surely write it.
 Not an issue handled by the language, IMHO.

 (If you make the resource data by an external program, you
 also should bare the existence of an external binding utility.)

 Tamas Nagy

 In article <d0ied6$a5a$1 digitaldaemon.com>, Andrew Fedoniouk says...

Anders, again, I am not speaking about OS resources.

I am speaking about simple static initializers.
I would like to be able to say:

static byte[] FFTable = import(....my.binary.module.name....);
instead of writing it as constants in-line.

As a rule such external "resources" (files) has special
applications to deal with them.
So import(....my.binary.module.name....); is just
a user friendly method to initialize statics using external
files.

No one language has now such feature (binary inclusion).
If D would have this it will denefit D and us and attracts more of
us to it.

Andrew.




"Anders F Björklund" <afb algonet.se> wrote in message
news:d0i8af$2ig$1 digitaldaemon.com...

 Asaf Karagila wrote:


 you guys keep talking about how resources differs between windows, 
 linux,
 fbsd, osx, etc..
 but did it occur to you that the binary headers are differents between
 those as well ?
 windows uses PE,
 linux and fbsd use ELF,
 i don't really know what OSX uses..


 Mac OS X uses "Mach-O", usually (there's also a PEF / CFM legacy format
 from Mac OS 9 that works too, but is less and less used for new stuff)

 Resources are different on Mac, too. They are either kept in a separate
 "fork" of the file, or kept in a separate file from the executable...


 They are hardly ever kept in the same file as the program code itself.

 This is actually a good thing, since it makes them editable by people
 other than programmers - using old ResEdit or new Interface Builder...

 --anders
Mar 07 2005
parent "Asaf Karagila" <kas1 netvision.net.il> writes:
i know that most of rcdata can be included as text strings and data,
except icons and pictures, but those can be solved as well..
the best example is DialogBoxIndirectParam that takes a pointer
to a struct of dialog template, just like it is written in the .rc file.

but it's still not a replacement for a real resource support.
if you want (non-console) windows coders to use it, you need to use an rc 
compiler.

- Asaf.

"Andrew Fedoniouk" <news terrainformatica.com> wrote in message 
news:d0iq46$mks$1 digitaldaemon.com...

 I wrote a resource binder and loader utility/class set in C++


 :) I wrote enough stuff in C++, shall I stick with it further and don't 
 touch D?

 dmd as a compiler suite does not have .rc compiler.
 Proposed simple solution eliminates it at major extent.

 It is possible to produce .res file "manualy" to include simple version 
 info and one icon (for Win32).
 Other resurces could be handled by import() and btw in better way than 
 .rc/.res

 Andrew Fedoniouk.
 http://terrainformatica.com



 "MicroWizard" <MicroWizard_member pathlink.com> wrote in message 
 news:d0io78$ks4$1 digitaldaemon.com...

 Does this issue really need so much posts?

 I wrote a resource binder and loader utility/class set in C++
 when I wrote a simple game years ago. It was roughly 200/100 lines.
 D is much more efficient, as I experienced.

 If anyone really need it, then he/she will surely write it.
 Not an issue handled by the language, IMHO.

 (If you make the resource data by an external program, you
 also should bare the existence of an external binding utility.)

 Tamas Nagy

 In article <d0ied6$a5a$1 digitaldaemon.com>, Andrew Fedoniouk says...

Anders, again, I am not speaking about OS resources.

I am speaking about simple static initializers.
I would like to be able to say:

static byte[] FFTable = import(....my.binary.module.name....);
instead of writing it as constants in-line.

As a rule such external "resources" (files) has special
applications to deal with them.
So import(....my.binary.module.name....); is just
a user friendly method to initialize statics using external
files.

No one language has now such feature (binary inclusion).
If D would have this it will denefit D and us and attracts more of
us to it.

Andrew.




"Anders F Björklund" <afb algonet.se> wrote in message
news:d0i8af$2ig$1 digitaldaemon.com...

 Asaf Karagila wrote:


 you guys keep talking about how resources differs between windows, 
 linux,
 fbsd, osx, etc..
 but did it occur to you that the binary headers are differents between
 those as well ?
 windows uses PE,
 linux and fbsd use ELF,
 i don't really know what OSX uses..


 Mac OS X uses "Mach-O", usually (there's also a PEF / CFM legacy format
 from Mac OS 9 that works too, but is less and less used for new stuff)

 Resources are different on Mac, too. They are either kept in a separate
 "fork" of the file, or kept in a separate file from the executable...


 They are hardly ever kept in the same file as the program code itself.

 This is actually a good thing, since it makes them editable by people
 other than programmers - using old ResEdit or new Interface Builder...

 --anders
Mar 07 2005
prev sibling parent reply =?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= <afb algonet.se> writes:
Andrew Fedoniouk wrote:


 Anders, again, I am not speaking about OS resources.
 
 I am speaking about simple static initializers.
 I would like to be able to say:
 
 static byte[] FFTable = import(....my.binary.module.name....);
 instead of writing it as constants in-line.


Ah, OK, now I understand. I put those in modules,
and then I import those modules from the D code.

Like:

 private import iso88591;
 private import macroman;

         wchar[256] mapping = iso88591.mapping;
 //      wchar[256] mapping = macroman.mapping;


Just that: a) those are pretty rare, compared to
regular resources b) modern CPUs hates lookups...


Other "real" resources, like any images and localized
strings and GUI layout components and icons and so on
should not be mixed the code - except for maybe a final
packaging step, like you say : dragging just one icon is
easier than running an installer and getting 100 files.
I'll consider this issue settled, and not really for D.

BTW; I just use Perl to dump any such binaries into code,
      if I do need to include them in D for any reason...
      (i.e. preprocessing, instead of the import pragma)
      Sorta like the XPM image format, if you know that ?

--anders
Mar 07 2005
next sibling parent kris <fu bar.org> writes:
It's worth noting that the ICU libraries have pretty extensive support 
(tools also) for externalizing locale-specific resources and so on. This 
is supported in D via the mango.icu package at dsource.org



Anders F Björklund wrote:

 Andrew Fedoniouk wrote:
 

 Anders, again, I am not speaking about OS resources.

 I am speaking about simple static initializers.
 I would like to be able to say:

 static byte[] FFTable = import(....my.binary.module.name....);
 instead of writing it as constants in-line.


 
 
 Ah, OK, now I understand. I put those in modules,
 and then I import those modules from the D code.
 
 Like:
 

 private import iso88591;
 private import macroman;

         wchar[256] mapping = iso88591.mapping;
 //      wchar[256] mapping = macroman.mapping;


 
 
 Just that: a) those are pretty rare, compared to
 regular resources b) modern CPUs hates lookups...
 
 
 Other "real" resources, like any images and localized
 strings and GUI layout components and icons and so on
 should not be mixed the code - except for maybe a final
 packaging step, like you say : dragging just one icon is
 easier than running an installer and getting 100 files.
 I'll consider this issue settled, and not really for D.
 
 BTW; I just use Perl to dump any such binaries into code,
      if I do need to include them in D for any reason...
      (i.e. preprocessing, instead of the import pragma)
      Sorta like the XPM image format, if you know that ?
 
 --anders
Mar 08 2005
prev sibling parent reply "Andrew Fedoniouk" <news terrainformatica.com> writes:
 Just that: a) those are pretty rare, compared to
 regular resources b) modern CPUs hates lookups...

 Other "real" resources, like any images and localized
 strings and GUI layout components and icons and so on
 should not be mixed the code - except for maybe a final
 packaging step, like you say : dragging just one icon is
 easier than running an installer and getting 100 files.
 I'll consider this issue settled, and not really for D.


"icons and so on should not be mixed the code"

"Icons and so" are integral parts of GUI application.
GUI application just does not work without them.

Consider themed UI app. Default theme implementation must
be always available.

"b) modern CPUs hates lookups"

I didn't get this, what do you mean?


 BTW; I just use Perl to dump any such binaries into code,
      if I do need to include them in D for any reason...
      (i.e. preprocessing, instead of the import pragma)
      Sorta like the XPM image format, if you know that ?


I am using my C-SMILE for that. Other guy is using
Python, etc.
Do you want to see something like this
"To build this D project you need a Perl/whatever runtime"....

Do you know why .NET is winning? Because of
good development tools.
In D situation community should try to simplify dev process
and probably re-think some standard approaches.
Mar 08 2005
parent =?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= <afb algonet.se> writes:
Andrew Fedoniouk wrote:


 "icons and so on should not be mixed the code"
 
 "Icons and so" are integral parts of GUI application.
 GUI application just does not work without them.


Yes, but they are easier to edit with a GUI editor ?

They should go with the ready application, of course,
but I'm not sure about including them in the source code ?


 "b) modern CPUs hates lookups"
 
 I didn't get this, what do you mean?


I meant lookup tables for things like multiplication or
sine or other things that one used to put in such tables...

These days one tries to calculate as much as possible,
since accessing the memory is slower than doing the math.

--anders
Mar 08 2005
prev sibling parent reply "Andrew Fedoniouk" <news terrainformatica.com> writes:
Hi, Asaf,

See, if you put in your D code this:

static byte myres[1000];

you will get your exectubale increased in size by 1000 bytes.
myres will be placed in DATA section of exectubale and
in D code you'll get a read-only access to its bytes .

My proposal is just damn simple

static byte myres[1000] = import(..binary.module.name......)

is exactly a short form of

static byte myres[1000] = [
0xdf, 0xfd, ....
];

Having this I can use it as resorces - and this has nothing
common to OS (PE/ELF/whatewer) resources.
OS resources live by their own.

static byte myres[1000] = import(........)
is just the convenient form of static initialization.

Andrew Fedoniouk.
http://terrainformatica.com



"Asaf Karagila" <kas1 netvision.net.il> wrote in message 
news:d0i7q9$2j2$1 digitaldaemon.com...

I don't post here regularly, nor i am an expert in programming, or in D.
 you guys keep talking about how resources differs between windows, linux, 
 fbsd, osx, etc..
 but did it occur to you that the binary headers are differents between 
 those as well ?
 windows uses PE,
 linux and fbsd use ELF,
 i don't really know what OSX uses..
 but there is a difference. so instead of using something like MS's .rc 
 format,
 which is pretty damn simple, or even inventing a new format and compiler 
 for that,
 and inside the different binary headers codes, just add the resources 
 handling for each OS
 as needed.

 it's that simple...

 - Asaf.
Mar 07 2005
parent "Asaf Karagila" <kas1 netvision.net.il> writes:
i kinda lost you guys here..
when you say OS resources, are you speaking about resources like, HAL and 
such resources,
or .res files and .rsrc sections (windows..) ?

GUI programming is MUCH easier with resources... so if you don't support 
them,
you kinda miss a big part of the GUI coders, and not in the terms of people 
who make GUIs for living,
but people who wish to code a GUI application.

- Asaf.

"Andrew Fedoniouk" <news terrainformatica.com> wrote in message 
news:d0idoe$9ch$1 digitaldaemon.com...

 Hi, Asaf,

 See, if you put in your D code this:

 static byte myres[1000];

 you will get your exectubale increased in size by 1000 bytes.
 myres will be placed in DATA section of exectubale and
 in D code you'll get a read-only access to its bytes .

 My proposal is just damn simple

 static byte myres[1000] = import(..binary.module.name......)

 is exactly a short form of

 static byte myres[1000] = [
 0xdf, 0xfd, ....
 ];

 Having this I can use it as resorces - and this has nothing
 common to OS (PE/ELF/whatewer) resources.
 OS resources live by their own.

 static byte myres[1000] = import(........)
 is just the convenient form of static initialization.

 Andrew Fedoniouk.
 http://terrainformatica.com



 "Asaf Karagila" <kas1 netvision.net.il> wrote in message 
 news:d0i7q9$2j2$1 digitaldaemon.com...

I don't post here regularly, nor i am an expert in programming, or in D.
 you guys keep talking about how resources differs between windows, linux, 
 fbsd, osx, etc..
 but did it occur to you that the binary headers are differents between 
 those as well ?
 windows uses PE,
 linux and fbsd use ELF,
 i don't really know what OSX uses..
 but there is a difference. so instead of using something like MS's .rc 
 format,
 which is pretty damn simple, or even inventing a new format and compiler 
 for that,
 and inside the different binary headers codes, just add the resources 
 handling for each OS
 as needed.

 it's that simple...

 - Asaf.
Mar 07 2005