March 06, 2005
"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.



March 07, 2005
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.


March 07, 2005
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
March 07, 2005
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.
> 


March 07, 2005
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


March 07, 2005
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.
>>
>
> 


March 07, 2005
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


March 08, 2005
> 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
>
> 


March 08, 2005
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
>>
>>
>
> 


March 08, 2005
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