March 06, 2005 Re: resources | ||||
---|---|---|---|---|
| ||||
Posted in reply to Matthew |
"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 Re: resources | ||||
---|---|---|---|---|
| ||||
Posted in reply to Andrew Fedoniouk | 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 Re: resources | ||||
---|---|---|---|---|
| ||||
Posted in reply to Asaf Karagila | 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 Re: resources | ||||
---|---|---|---|---|
| ||||
Posted in reply to Asaf Karagila | 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 Re: resources | ||||
---|---|---|---|---|
| ||||
Posted in reply to Anders F Björklund | 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 Re: resources | ||||
---|---|---|---|---|
| ||||
Posted in reply to Andrew Fedoniouk | 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 Re: resources | ||||
---|---|---|---|---|
| ||||
Posted in reply to Andrew Fedoniouk | 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 Re: resources | ||||
---|---|---|---|---|
| ||||
Posted in reply to MicroWizard | > 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 Re: resources | ||||
---|---|---|---|---|
| ||||
Posted in reply to Andrew Fedoniouk | 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 Re: resources | ||||
---|---|---|---|---|
| ||||
Posted in reply to Andrew Fedoniouk | 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 |
Copyright © 1999-2021 by the D Language Foundation