Anyone interesting in a Boot Image format?
Anyone interesting in a Boot Image format?
Hey people,
My projects use something I have been using called the Zenobit boot package. Basically, ZBP is a filesystem in a file. I created it out of laziness (I didn't want to have to write a floppy disk driver to retrieve the rest of my files from the drive).
Anywho, since my project (Zenobit) is officially on hiatus, I figured I would make a slightly improved ZBP Format and release it as public domain. Maybe it could be useful to someone out there.
So, these are ZBP2's features:
- Simple format.
- Tools to create and inspect ZBP2 Archives are ANSI-C89 compliant and use no crazy libraries. So, they will compile under almost everything (Windows, Unix, etc...)
- Ability to package multiple files into a single archive.
- Files can be organized in Directories.
- Variable-length Directory/Filenames.
- As it was designed for bootstrapping Zenobit, File data is aligned on 4KiB boundaries.
(So, I could create the new processes and such without actually copying any of the
data from the package).
- As Zenobit's Second stage bootloader (like everything else) was contained within the ZBP archive, the first file is ALWAYS at a known location. After I have finished tweaking ZBP2, I will post that information.
These are ZBP2's limitations:
- To save some space in the entry structure, it is only possible to have $FFFF files within a single ZBP.
+ A work around is to nest ZBP Archives.
- In the Effort vs. Time vs. Fun balance of creating new things, ZBPv2 doesn't use the GREATEST structure for organizing it's entry structures. Files are stored in a BST structure in alphabetical order.
- It does not support things like Compression or Encryption (as of yet).
+ However, there is a DWORD reserved for future use. This dword could point to a future structure to store compression/encryption information.
I'm in the process of forming a little website devoted to producing crazy things, like ZBP2.. All of it will be public domain.
In any case, if anyone is interested in rescuing ZBP from cyberhell, speak now or forever hold ye piece...
~Zeii, the 32bit Alchemist.
My projects use something I have been using called the Zenobit boot package. Basically, ZBP is a filesystem in a file. I created it out of laziness (I didn't want to have to write a floppy disk driver to retrieve the rest of my files from the drive).
Anywho, since my project (Zenobit) is officially on hiatus, I figured I would make a slightly improved ZBP Format and release it as public domain. Maybe it could be useful to someone out there.
So, these are ZBP2's features:
- Simple format.
- Tools to create and inspect ZBP2 Archives are ANSI-C89 compliant and use no crazy libraries. So, they will compile under almost everything (Windows, Unix, etc...)
- Ability to package multiple files into a single archive.
- Files can be organized in Directories.
- Variable-length Directory/Filenames.
- As it was designed for bootstrapping Zenobit, File data is aligned on 4KiB boundaries.
(So, I could create the new processes and such without actually copying any of the
data from the package).
- As Zenobit's Second stage bootloader (like everything else) was contained within the ZBP archive, the first file is ALWAYS at a known location. After I have finished tweaking ZBP2, I will post that information.
These are ZBP2's limitations:
- To save some space in the entry structure, it is only possible to have $FFFF files within a single ZBP.
+ A work around is to nest ZBP Archives.
- In the Effort vs. Time vs. Fun balance of creating new things, ZBPv2 doesn't use the GREATEST structure for organizing it's entry structures. Files are stored in a BST structure in alphabetical order.
- It does not support things like Compression or Encryption (as of yet).
+ However, there is a DWORD reserved for future use. This dword could point to a future structure to store compression/encryption information.
I'm in the process of forming a little website devoted to producing crazy things, like ZBP2.. All of it will be public domain.
In any case, if anyone is interested in rescuing ZBP from cyberhell, speak now or forever hold ye piece...
~Zeii, the 32bit Alchemist.
- Brynet-Inc
- Member
- Posts: 2426
- Joined: Tue Oct 17, 2006 9:29 pm
- Libera.chat IRC: brynet
- Location: Canada
- Contact:
Project?
ZBPv1 has been in use for over a year now. Just, I never thought it was worthwhile sharing to the world.
ZBP is what makes booting Zenobit possible.
ZBPv1 has the limitations of:
- 15 character names, maximum.
- No directories.
- No sorting.
- Linear searching.
But it does have:
- Same entry point for first inserted file (Bootloader Stage 2).
- Reserved word for future extensions (Now used as a DEBUG MODE toggle, so I can
'patch' the ZBP to enable Video,Serial and such).
~zeii
ZBPv1 has been in use for over a year now. Just, I never thought it was worthwhile sharing to the world.
ZBP is what makes booting Zenobit possible.
ZBPv1 has the limitations of:
- 15 character names, maximum.
- No directories.
- No sorting.
- Linear searching.
But it does have:
- Same entry point for first inserted file (Bootloader Stage 2).
- Reserved word for future extensions (Now used as a DEBUG MODE toggle, so I can
'patch' the ZBP to enable Video,Serial and such).
~zeii
Oh and just for the hell of it, since I remember now ... GLOOM LIB is completed.
If anyone remembers, Gloom was a Crossplatform ADT library, suited for freestanding environments.
It is coded in C, it is ANSI C99 compliant (sorry C89ers).
It provides:
- Linked lists (singly, doubly).
- Binary search tree.
- AVL tree.
- Heap.
All ADTs are written in a way that Memory allocation requirements are EXTERNAL to the library. This makes insertion and removal a little different.
ie:
- When you remove a node of any structure, it isnt destroyed, the node is returned via address to the caller. It provides the address for deletion.
- Failed insertions return the node for destruction. Otherwise, it returns 0.
Why?
- Its a major deal to NOT know when insertion fails...
- It isnt a MAJOR deal to create a variable to hold an address for the purpose of
performing an insertion . . .
Well at least, I think it is worth it for ADTs that if you wanted, you could use without any real MM at all.
~Z
If anyone remembers, Gloom was a Crossplatform ADT library, suited for freestanding environments.
It is coded in C, it is ANSI C99 compliant (sorry C89ers).
It provides:
- Linked lists (singly, doubly).
- Binary search tree.
- AVL tree.
- Heap.
All ADTs are written in a way that Memory allocation requirements are EXTERNAL to the library. This makes insertion and removal a little different.
ie:
- When you remove a node of any structure, it isnt destroyed, the node is returned via address to the caller. It provides the address for deletion.
- Failed insertions return the node for destruction. Otherwise, it returns 0.
Why?
- Its a major deal to NOT know when insertion fails...
- It isnt a MAJOR deal to create a variable to hold an address for the purpose of
performing an insertion . . .
Well at least, I think it is worth it for ADTs that if you wanted, you could use without any real MM at all.
~Z
Well.
I feel happy.
I have just written the ZBPv2 Archive tool! (woohoo!). Even better is that poking around in a hex editor shows me that everything has been written correctly, all offsets calculated successfully and that the BST is ordered correctly. Heck, even my string table is working fine.
Considering I sat down and wrote myself a letter THEN got to writing the tool, ALL WITHOUT A SINGLE COFFEE, Im chuffed. ^_^
command syntax is a little funky. Here is an example:
All I have to do now is make some extra tools for extracting data from and inspecting data in, such archives!
If anyones interested in the code now, I will post it on request.
If everyone would rather wait until its made sociable and has a few more little programs to tinker with (ie: extraction), alrighty then.
~zeii, 32bit alchemist.
I feel happy.
I have just written the ZBPv2 Archive tool! (woohoo!). Even better is that poking around in a hex editor shows me that everything has been written correctly, all offsets calculated successfully and that the BST is ordered correctly. Heck, even my string table is working fine.
Considering I sat down and wrote myself a letter THEN got to writing the tool, ALL WITHOUT A SINGLE COFFEE, Im chuffed. ^_^
command syntax is a little funky. Here is an example:
Code: Select all
archb -v -of= myArchive.zbp -if= /system/boot.bin@./build/boot.bin -if= /system/krnl.bin@./build/kernel-i386.bin
If anyones interested in the code now, I will post it on request.
If everyone would rather wait until its made sociable and has a few more little programs to tinker with (ie: extraction), alrighty then.
~zeii, 32bit alchemist.
Well, here is the first iteration archiver tool.
~z
~z
- Attachments
-
- archb.c
- ZBPv2 Archiver 0.1a
- ANSI C89 compliant.
- Maximum of 0xFFFE files within the archive.
- Sorted, via binary search tree.
Distributed under this license:
http://creativecommons.org/licenses/by-nd/3.0/ - (10.76 KiB) Downloaded 30 times
Last edited by elderK on Mon Sep 10, 2007 4:50 pm, edited 2 times in total.
Well, there is no official release yet. So, I suppose that code is up for grabs.
That being said, Id appreciate if you leave it in the state it is in (yes, its messy but hey, its my little contribution to the osdev community...).
You are welcome to use the system in your Kernel, you are welcome to improve it. If you do however, id appreciate being sent the updated version (via email). Any updates I make, I will release. Just, itd be cool if I didnt repeat the work someone else already did ...
In order to search the BST, you will need a STRCMP that can tell if a string is greater or less than another. However, if you dont have such a function, you can STILL retrieve files from the archive, just itd be slower - since you will have to linearly search the entry table for whatever filename...
Anywho, Id like feedback!
~Z
That being said, Id appreciate if you leave it in the state it is in (yes, its messy but hey, its my little contribution to the osdev community...).
You are welcome to use the system in your Kernel, you are welcome to improve it. If you do however, id appreciate being sent the updated version (via email). Any updates I make, I will release. Just, itd be cool if I didnt repeat the work someone else already did ...
In order to search the BST, you will need a STRCMP that can tell if a string is greater or less than another. However, if you dont have such a function, you can STILL retrieve files from the archive, just itd be slower - since you will have to linearly search the entry table for whatever filename...
Anywho, Id like feedback!
~Z
Sounds like CC:by-nd to me. If that sounds OK for you, add it to the archive description, so everyone knows what he's up to.
Every good solution is obvious once you've found it.
Hey people,
Was wondering if anyone found this vaguely useful, and if it is worth polishing for release.
Also, I have another little tool that could find some use in our circle. Is anyone in need of an XMLish grammar for storing data?
Out of boredom, I have created something I dub at this time 'Lilac'. I wanted to create a little syntax that I could use to universally retrieve data in most of the applications I create. I wanted to be able to retrieve:
- signed and unsigned 32bit integers.
- strings of arbitrary length.
- 32bit floating point numbers.
I also wanted to be able to store data in structures, or arrays.
- Store one dimensional, two dimensional arrays.
I wanted to be able to nest Containers / Objects.
Also, I wanted it to be able to function nicely in a freestanding environment (ie: without handy-dandy automagickal CSTDIO/CSTDLIB/CSTRING).
Here is an example of Lilac:
The syntax of Lilac can be changed easily by simply editing a few enumerations in its source, basically allowing you to change the entire appearance of the syntax to suit whatever your personal style is...
It also has very, very basic checking of scope ... For example:
If I tried to locate the object c, via this address: c@b@a, it would end up throwing an out_of_scope exception. That is because object c is inside object a, not b. The correct address is c@a.
All that is required for Lilac to work is a working STRCMP function, no more, no less...
If anyone is interested, give me a yell... or post in here. If desired, Lilac will be the same as the license as the archbin tool.
~Z
Was wondering if anyone found this vaguely useful, and if it is worth polishing for release.
Also, I have another little tool that could find some use in our circle. Is anyone in need of an XMLish grammar for storing data?
Out of boredom, I have created something I dub at this time 'Lilac'. I wanted to create a little syntax that I could use to universally retrieve data in most of the applications I create. I wanted to be able to retrieve:
- signed and unsigned 32bit integers.
- strings of arbitrary length.
- 32bit floating point numbers.
I also wanted to be able to store data in structures, or arrays.
- Store one dimensional, two dimensional arrays.
I wanted to be able to nest Containers / Objects.
Also, I wanted it to be able to function nicely in a freestanding environment (ie: without handy-dandy automagickal CSTDIO/CSTDLIB/CSTRING).
Here is an example of Lilac:
Code: Select all
person {
name $= "Mr. Sugar"
age @= 68
address [$] {
: "40 Candycane lane,"
: "Cuba."
}
ranked_hobbies [$@] {
: "Dream crushing" : 4
: "Brain mashing" : 10
: "Coffee drinking" : 1
}
}
It also has very, very basic checking of scope ... For example:
Code: Select all
a {
b {
}
c {
}
}
All that is required for Lilac to work is a working STRCMP function, no more, no less...
If anyone is interested, give me a yell... or post in here. If desired, Lilac will be the same as the license as the archbin tool.
~Z