Jump to content











Photo
- - - - -

GOBIES - not your average fishes


  • This topic is locked This topic is locked
40 replies to this topic

#26 Nuno Brito

Nuno Brito

    Platinum Member

  • .script developer
  • 10544 posts
  • Location:boot.wim
  • Interests:I'm just a quiet simple person with a very quiet simple life living one day at a time..
  •  
    European Union

Posted 05 January 2011 - 05:46 PM

Since we don't have dots in the strings we will use, nor version numbers, that's pretty much a non-problem

Ok then. :)

BTW, those are backslashes, and a lot of people (like Unix/Linux users and web users, and grub4dos and Syslinux users ) will identify / (forward slashes) as separators.

Yes, that is the reason why I called them merely as slashes. (don't want to start a flame war.. ;))

JFYI .ini/.inf files do normally use dots and not backslashes or slashes.

Good to see you're following a specification. My concern is for seeing the slash act as a sub-section separator that is understood intuitively by writers and even a specification should be challenged and questioned within good sense.


I seem to remember you wrote a .ini/.inf parser some time ago

OMG. That was over two years ago! I didn't even had a twitter account back then.

which you left unfinished and only partially working

Well, at least I was nice enough to include the source code. Nobody is really interested in working with delphi anymore so I might as well start using .NET 5 for the next apps.

Ninf is not running on my machine thought, Panda quickly treats it as a virus:
Posted Image
I guess he knows better than me, knowledge is evil and panda keeps me safe by removing the ninf.exe without asking my thoughts on the matter.. :whistling:



I presume next contribution will be something of utter relevance, such as "Why don't you use # instead of ; for comments?" (and yes a lot of people will "instinctively" see // as commenting separator)

My apologies, I tend to worry quite a lot about how software "looks" for an end user (or writer in this case).

#27 shamurshamur

shamurshamur

    Frequent Member

  • Developer
  • 322 posts
  •  
    India

Posted 05 January 2011 - 05:51 PM

Well, at least I was nice enough to include the source code. Nobody is really interested in working with delphi anymore so I might as well start using .NET 5 for the next apps.


.NET wins.Posted Image
LOL

#28 Wonko the Sane

Wonko the Sane

    The Finder

  • Advanced user
  • 14778 posts
  • Location:The Outside of the Asylum (gate is closed)
  •  
    Italy

Posted 05 January 2011 - 06:01 PM

My apologies, I tend to worry quite a lot about how software "looks" for an end user (or writer in this case).

Sure :ranting2:, now I see WHY you chose "," as separator for Winbuilder .script syntax:
  • you wanted .scripts to be more READABLE :w00t:

Let's say that it was an early attempt that completely failed. :)

And since I am after all a nice guy, I won't even mention the "quotes" problem .... :cheers:

About Panda, maybe you forgot that you UPXed the ninf .exe.... :whistling:

You know how I approve of the use of .Net 5, but of course you also need to at-least:
  • make a new site www.ninf.info
  • create a set of videos for it's usage
  • do BOTH a Powerpoint and a Silverlight presentation
  • write a whitepaper for it
  • add an automatic internet connecting app so that Status line reads twits while you work with .ninf 2.x

@shamurshamur
Is it OK with the . (dot) or whatever?

Can you post some examples of Syslinux syntax?

@all

What you CANNOT do :ranting2: :

  • discuss the usage of .ini files, suggesting using .xml, hives, or ANY other non plain text, human readable, file format
  • post the usual off topic and thread hijacking unrelated and senseless comments



In other words, if you like the idea , contribute to it ;) , if you don't, just ignore this thread, there are a lot of better things in life than spreading negativity around :cheers: .

Can we §@ç#ing go back to work? :unsure:

:cheers:
Wonko

#29 shamurshamur

shamurshamur

    Frequent Member

  • Developer
  • 322 posts
  •  
    India

Posted 05 January 2011 - 06:22 PM

@shamurshamur
Is it OK with the . (dot) or whatever?

Can you post some examples of Syslinux syntax?

@all

Can we §@ç#ing go back to work? :whistling:

;)
Wonko



its Ok with Dot.



main point here is that we can create many sub sub sections inside sections as many we want.
ie we can have hierarchal sections.

sections

[Source001]



[Source002]



[Source003]




sub-sections

[Source001.grub4dos]

[Source001.syslinux]




sub-sub-sections

...

[Source001.grub4dos.from_iso_1]

...

[Source001.grub4dos.from_iso_2]

...



...

[Source001.syslinux.from_iso_0]



And for this we have to make this rule that dot will be reserved for representing hierarchies in section names., and should not be used as normal naming character.

#30 Wonko the Sane

Wonko the Sane

    The Finder

  • Advanced user
  • 14778 posts
  • Location:The Outside of the Asylum (gate is closed)
  •  
    Italy

Posted 05 January 2011 - 06:42 PM

its Ok with Dot.



main point here is that we can create many sub sub sections inside sections as many we want.
ie we can have hierarchal sections.

....

And for this we have to make this rule that dot will be reserved for representing hierarchies in section names., and should not be used as normal naming character.


Yep. :whistling:
We all (actually just you and me ;)) agree that:
  • . (dot) is valid hierarchy delimiter
  • that anything inside [] (square brackets) won't contain a . (dot) unless it is a hierarchy delimiter


...if someone doesn't post a few examples for Parted Magic 5.8 and Slitaz 3.0 with Syslinux/Isolinux/whatever soon, I'll start screaming! :)

:cheers:
Wonko

#31 maybeway36

maybeway36
  • Members
  • 8 posts
  •  
    United States

Posted 06 January 2011 - 01:04 AM

I don't know if you can use something like the "from_iso" in syslinux/isolinux, but "flat" is no problem.
Here's what I have for MultiCD:
label slitaz

	menu label ^SliTaz GNU/Linux

	kernel /boot/slitaz/bzImage

	append initrd=/boot/slitaz/rootfs.gz rw root=/dev/null vga=normal
MENU BEGIN ^Parted Magic$VERSION



LABEL normal

MENU LABEL ^Parted Magic: Default settings (Runs from RAM / Ejects CD)

KERNEL /pmagic/bzImage

APPEND noapic initrd=/pmagic/initramfs load_ramdisk=1 prompt_ramdisk=0 rw vga=791 sleep=10 loglevel=0 keymap=us



LABEL live

MENU LABEL ^Parted Magic: Live with default settings (USB not usable)

KERNEL /pmagic/bzImage

APPEND noapic initrd=/pmagic/initramfs load_ramdisk=1 prompt_ramdisk=0 rw vga=791 sleep=10 livemedia noeject loglevel=0 keymap=us



LABEL lowram

MENU LABEL ^Parted Magic: Live with low RAM settings

KERNEL /pmagic/bzImage

APPEND noapic initrd=/pmagic/initramfs load_ramdisk=1 prompt_ramdisk=0 rw vga=normal sleep=10 lowram livemedia noeject nogpm nolvm nonfs nofstabdaemon nosmart noacpid nodmeventd nohal loglevel=0 xvesa keymap=us



LABEL xvesa

MENU LABEL ^Parted Magic: Alternate graphical server

KERNEL /pmagic/bzImage

APPEND noapic initrd=/pmagic/initramfs load_ramdisk=1 prompt_ramdisk=0 rw vga=791 sleep=10 xvesa loglevel=0 keymap=us



LABEL normal-vga

MENU LABEL ^Parted Magic: Safe Graphics Settings (vga=normal)

KERNEL /pmagic/bzImage

APPEND noapic initrd=/pmagic/initramfs load_ramdisk=1 prompt_ramdisk=0 rw vga=normal sleep=10 loglevel=0 keymap=us



LABEL failsafe

MENU LABEL ^Parted Magic: Failsafe Settings

KERNEL /pmagic/bzImage

APPEND noapic initrd=/pmagic/initramfs load_ramdisk=1 prompt_ramdisk=0 rw vga=normal sleep=10 acpi=off noapic nolapic nopcmcia noscsi nogpm consoleboot nosmart keymap=us



LABEL console

MENU LABEL ^Parted Magic: Console (boots to the shell)

KERNEL /pmagic/bzImage

APPEND noapic initrd=/pmagic/initramfs load_ramdisk=1 prompt_ramdisk=0 rw vga=normal sleep=10 consoleboot keymap=us



LABEL back

MENU LABEL ^Back to main menu

COM32 menu.c32

APPEND isolinux.cfg



MENU END
Although, that "back to main menu" entry depends on the main config file being isolinux.cfg and it being in the same folder as isolinux.bin.

#32 shamurshamur

shamurshamur

    Frequent Member

  • Developer
  • 322 posts
  •  
    India

Posted 06 January 2011 - 06:13 AM

@All

By introducing the concept of sub-sections in our draft we are introducing a Non-standard functionality in .INI files.
So if other programmers wan't to have their say , they can speak now.

@ Wonko the sane

How many programmers till now have been agreed to follow the GOBIES standard?

#33 Wonko the Sane

Wonko the Sane

    The Finder

  • Advanced user
  • 14778 posts
  • Location:The Outside of the Asylum (gate is closed)
  •  
    Italy

Posted 06 January 2011 - 11:29 AM

@All

By introducing the concept of sub-sections in our draft we are introducing a Non-standard functionality in .INI files.

I have to disagree with you. :(
The fact that we use a "sub-section" like mnemonics for the labels does NOT mean, in ANY way that the resulting file is not .ini compatible.
Besides, we have - as said - .inf files that do use a similar approach.
BTW some .inf files made by the good MS guys are non standard in the sense that the same label (or set of label) can appear more than once, something that I would exclude in "our" .ini/.inf's.

@ Wonko the sane

How many programmers till now have been agreed to follow the GOBIES standard?

Davide Costa (SARDU) has preliminary promised support. (since he is not familiar with English I am doing some "background work" with him in Italian via PM)
maybeway36 (MULTICD) is interested (and has already posted something :thumbsup: ).
François Fabre (Multisystem) is interested (but since he is also not very familiar with English, we had a couple mail exchanged in French - and as soon as we have anything even marginally like a real something, I will make a French version of the examples).

@maybeway36
Maybe we need an additional "sub-section" for "media on which the target is made". :dubbio:
Something like:

[Source001.syslinux.flat_1.on_CD]

[Source001.syslinux.flat_2.on_CD]

[Source001.syslinux.flat_1.on_HD]

[Source001.syslinux.flat_2.on_HD]

[Source001.grub4dos.from_iso_0.on_CD]

[Source001.grub4dos.from_iso_0.on_HD]


:cheers:
Wonko

#34 shamurshamur

shamurshamur

    Frequent Member

  • Developer
  • 322 posts
  •  
    India

Posted 06 January 2011 - 12:13 PM

I have to disagree with you. :(
The fact that we use a "sub-section" like mnemonics for the labels does NOT mean, in ANY way that the resulting file is not .ini compatible.
Besides, we have - as said - .inf files that do use a similar approach.
BTW some .inf files made by the good MS guys are non standard in the sense that the same label (or set of label) can appear more than once, something that I would exclude in "our" .ini/.inf's.

Actually it is non-standard. .INI files DO NOT support sub-sections.

There are no standard way of having sub-section in .INI file. If it was there , then operating systems and programming languages would also identify the sub-section for us , but they don't . whoever want sub-section create its own way of implementing sub-section.
For windows and any other parser , that dot (or whatever convention used) in the names of sections doesn't mean anything. programmer itself has to write code separately for it to identify each sub-section.



Davide Costa (SARDU) has preliminary promised support. (since he is not familiar with English I am doing some "background work" with him in Italian via PM)
maybeway36 (MULTICD) is interested (and has already posted something :thumbsup: ).
François Fabre (Multisystem) is interested (but since he is also not very familiar with English, we had a couple mail exchanged in French - and as soon as we have anything even marginally like a real something, I will make a French version of the examples).

@maybeway36
Maybe we need an additional "sub-section" for "media on which the target is made". :dubbio:
Something like:


[Source001.syslinux.flat_1.on_CD]

[Source001.syslinux.flat_2.on_CD]

[Source001.syslinux.flat_1.on_HD]

[Source001.syslinux.flat_2.on_HD]

[Source001.grub4dos.from_iso_0.on_CD]

[Source001.grub4dos.from_iso_0.on_HD]


:cheers:
Wonko


you can have as many additional "sub-section" as you want , but each programmer will use its own algorithm to identify each subsection.Cause there is no standard way to identify Sub-sections.

So don't take idea of sub-section taken for granted. Basically by introducing sub-section we are creating our own format.

i also want to see the views of other programmers if they are comfortable with idea of sub-section or they have some better ideas.

#35 Wonko the Sane

Wonko the Sane

    The Finder

  • Advanced user
  • 14778 posts
  • Location:The Outside of the Asylum (gate is closed)
  •  
    Italy

Posted 06 January 2011 - 12:43 PM

And, again, they are not (from a .ini point of view) sub-sections.
They are "normal labels" that the actual parser used will read "normally".
The fact that they represent sub-sections is our way to better recognize them (and to allow the app to easily parse them).

For all it matters to .ini files, labels could be:

[çp১]
[.ç^#@@*]


it is the program that looks for the given label "[.ç^#@@*]" and reads it's settings.

What we are saying is that "our" .ini will have labels EXCLUSIVELY in the form:

[SourceNames] <- optional, only in "type #2" files.
[Source<lmn>]
[Source<lmn>.<main_loader>]
[Source<lmn>.<main_loader>.<method>]

and maybe the latter will become:

[Source<lmn>.<main_loader>.<method>.<target>]

and that there will be NO repetitions of the SAME label.


But our differing view is not relevant :dubbio:, as long as the approach works and it "delivers" what is needed.


:thumbsup:
Wonko

#36 shamurshamur

shamurshamur

    Frequent Member

  • Developer
  • 322 posts
  •  
    India

Posted 06 January 2011 - 01:00 PM

But our differing view is not relevant :dubbio:, as long as the approach works and it "delivers" what is needed.


:(
Wonko


As far as i am concerned I am OK with what we have decided till now ie using dot to implement subsections.

May be we can finalize this and move to next thing.:thumbsup:

#37 Wonko the Sane

Wonko the Sane

    The Finder

  • Advanced user
  • 14778 posts
  • Location:The Outside of the Asylum (gate is closed)
  •  
    Italy

Posted 06 January 2011 - 01:53 PM

Draft 2 attached.

Example follows:
Spoiler


:dubbio:
Wonko

Attached Files



#38 steve6375

steve6375

    Platinum Member

  • Developer
  • 6943 posts
  • Location:UK
  • Interests:computers, programming (masm,vb6,C,vbs), photography,TV,films,guitars, www.easy2boot.com
  •  
    United Kingdom

Posted 06 January 2011 - 03:37 PM

There is already a format we could adopt which is Windows INF files - but personally I find these very hard to understand and would rather not go there! However we could use some tips from the INF file format such as SourceDiskFiles, DestinationDirs, Version, DefaultInstall, etc?

Going back to the example above, some lines have comments about extracting files to \xxx\yyy or renaming a file or creating folders, but I cannot see any valid INI file entries/commands which say to do this?
We could have sections for sourcefiles, copyfiles, delfiles, modfiles (for hex mods)




Also, it is probably wise to change the destination folder names to include the version number in the folder name, where possible, so that you can have more than one version of the flat files on the same drive? Thus if the folder already exists the user can be warned, if not then the new version is installed alongside the old version.

The first line of the grub4dos menu starts with title as well, so the examples should look like this...?

title title for this menu
line_001 title here is grub4dos menu title
line_002 find --set-root /slitaz/slitaz-3.0.iso
line_003
line_004 ;comment
line_005 title here is 2nd menu title
line_006 find --set-root /xxxx
etc.
The first line is for parsing by app/XBOOT/SARDU etc. - not used in grub4dos/syslinux menu

suggest we use 3 numbers (line_xxx) as we could have more than 99 lines?

so instructions for copying/preparing the files (including compressing to save space) could be

(just as nonsense examples - do not pay any attention to if it will work!)

[Source001.grub4dos.from_iso_1]

;this example uses a renamed pmagic-5.8.iso in a folder root\pmagic\

;create directory root\pmagic58\

;copy pmagic-5.8.iso (renamed as per new_filename as pmagic58.iso) to root\pmagic\

filesystem=FAT16;FAT32;CDFS;NTFS;EXT2;EXT3

title=PartedMagic 5.8 from iso renamed

copy_001.source=*.*

copy_001.dest=pmagic58\*.*

copy_001.type=recursive

copy_002.source=fred.img

copy_002.dest=pmagic58\doris.img

copy_003.source=peter\fred.vmz

copy_003.dest=pmagic58\peter\fred.vmz

compress_001.source=xxx.iso

compress_001.type=gz

compress_001.dest=pmagic58\xxx.iso.gz

delete_001=pmagic\ddd.txt

delete_002=pmagic\sss.txt



main_config=menu.lst

line_001=title PartedMagic 5.8 from iso renamed

line_002=find --set-root /pmagic/pmagic58.iso

line_003=map --heads=0 --sectors-per-track=0 /pmagic/pmagic58.iso (0xff)

line_004=map --hook

line_005=root (0xff)

line_006=kernel /pmagic/bzImage edd=off noapic load_ramdisk=1 prompt_ramdisk=0 rw vga=791 sleep=10 loglevel=0 keymap=us iso_filename=/pmagic/pmagic58.iso

line_007=initrd /pmagic/initramfs


#39 Wonko the Sane

Wonko the Sane

    The Finder

  • Advanced user
  • 14778 posts
  • Location:The Outside of the Asylum (gate is closed)
  •  
    Italy

Posted 06 January 2011 - 04:22 PM

@steve6375
You are going FAR ahead of the current status. :dubbio:

We are still about checking if the "base" is solid enough (also to later be able - as an extension - to add to it actual commands).

The general idea is NOT to invent a new "batch language".
It is to exchange loader settings. (now)
IF the idea has some success, then we may think of adding actual commands, (or command settings), but - judging from the current status I sincerely doubt we will ever manage to have such a large consensus.

I guess that what you are saying is that we should invent a new "meta-language" that understands parameters like:
copy_<lmn>.source=

copy_<lmn>.dest=

copy_<lmn>.type=

compress_<lmn>.source=

compress_<lmn>.dest=

compress_<lmn>.type=

compress_<lmn>.source=

compress_<lmn>.dest=

compress_<lmn>.type=

....

The idea is nice, but as I see it a bit premature.

suggest we use 3 numbers (line_xxx) as we could have more than 99 lines?

No prob. :(

The first line of the grub4dos menu starts with title as well, so the examples should look like this...?

title title for this menu
line_001 title here is grub4dos menu title
line_002 find --set-root /slitaz/slitaz-3.0.iso
line_003
line_004 ;comment
line_005 title here is 2nd menu title
line_006 find --set-root /xxxx
etc.
The first line is for parsing by app/XBOOT/SARDU etc. - not used in grub4dos/syslinux menu

I don't get it. :cheers:

There is already the line:
title=PartedMagic 5.8 from iso renamed
right after the
filesystem=FAT16;FAT32;CDFS;NTFS;EXT2;EXT3

WHY repeating it after:
main_config=menu.lst

I mean in the "body" of your post you have:

title title for this menu
line_001 title here is grub4dos menu title
line_002 find --set-root /slitaz/slitaz-3.0.iso
line_003
line_004 ;comment
line_005 title here is 2nd menu title
line_006 find --set-root /xxxx

and in the snippet you use "current" convention.
I don't understand. :(
My original idea is that it would be theoretically possible for the app Author to choose two different "titles", one for internal use (the title= in the [Source<lmn>.<main_loader>.<method>] and one in the actual config file, BTW grub legacy, grub4dos and Syslinux/Isolinux/whatever do have as first line "title" but GRUB2 has "### BEGIN", gujin has <who knows> and the same goes for the n other available (though possibly only a "niche") loaders.

Also, it is probably wise to change the destination folder names to include the version number in the folder name, where possible, so that you can have more than one version of the flat files on the same drive? Thus if the folder already exists the user can be warned, if not then the new version is installed alongside the old version.

This is up to the developers of the single apps, as I see it.
Finding a "common convention" for folder names would be another (as I see it) nice, but completely unrealizable in practice goal.
To me it would be already an excellent goal to understand which .iso's (and folders/directories and filenames) can be actually renamed and which not (or not without some hexediting and if yes with which hex editing).

Have you noticed my new signature on 911CD? :

- In theory there is no difference between theory and practice, but in practice there is. -


I have my ways :thumbsup: , but if someone would produce the FINAL menu.lst, syslinux.cfg, isolinux.cfg, grub.cfg , etc. of EACH of the mentioned multi-booting apps with ALL the currently available distro's/source's I could try manually expanding the sample (or produce multiple samples) and see if any conflict is created (and consequently a change in structure is needed)

:cheers:
Wonko

#40 shamurshamur

shamurshamur

    Frequent Member

  • Developer
  • 322 posts
  •  
    India

Posted 06 January 2011 - 05:11 PM

The more we are going towards the actualization of this draft , the more i am having serious doubt about the capability of .INI files of handling complex data.


just the introduction of a hierarchal data is making it looks ridiculous.And forcing the programmers to adopt Non-standard ways.


And i am missing the ease and gracefulness of XML in handling such type of data.

During previous discussions you were emphasizing that XML is not powerful than .INI.
Sorry but i am now totally convinced that that statement was very inaccurate.

There is a reason that XML has become the most favorite way of storing data in whole software industry.I can appreciate that fact now.

PS: sorry but i had to raise this point. I do not want to invest my time and hard work in a project whose platform is so weak that it cripples the productivity of whole project.

cheers.

#41 Wonko the Sane

Wonko the Sane

    The Finder

  • Advanced user
  • 14778 posts
  • Location:The Outside of the Asylum (gate is closed)
  •  
    Italy

Posted 06 January 2011 - 05:37 PM

The more we are going towards the actualization of this draft , the more i am having serious doubt about the capability of .INI files of handling complex data.


just the introduction of a hierarchal data is making it looks ridiculous.And forcing the programmers to adopt Non-standard ways.


And i am missing the ease and gracefulness of XML in handling such type of data.

During previous discussions you were emphasizing that XML is not powerful than .INI.
Sorry but i am now totally convinced that that statement was very inaccurate.

There is a reason that XML has become the most favorite way of storing data in whole software industry.I can appreciate that fact now.

PS: sorry but i had to raise this point. I do not want to invest my time and hard work in a project whose platform is so weak that it cripples the productivity of whole project.

cheers.


No problem. :)

It simply puts the final tombstone over the GOBIES project.

Too bad. :(

I will ASAP contact AGAIN all the people I disturbed about this stoopid idea to excuse myself for bothering them needlessly.

We'll wait for a new XML based initiative. (or for no initiatives)

Remember to also create a .Net 4 based XML parser for it.

About this:

PS: sorry but i had to raise this point. I do not want to invest my time and hard work in a project whose platform is so weak that it cripples the productivity of whole project.

thanks for having considered my time and hard work.

I should have known better.

Project is closed.
Move on peeps, there are MUCH better things to do in life. :smiling9:

:cheers:
Wonko




0 user(s) are reading this topic

0 members, 0 guests, 0 anonymous users