Graham Perrin's Library tagged binary → View Popular

Filter:
All
Annotated

13 Aug 09

XBinary: Extended Binary Format Support for Mac OS X

osxbook.com/xbinary - Preview

XBinary Extended Binary Format kernel binary Universal Binary format Apple Inc. Mac OS X Diigo 48946 2009

Extended Binary Format Support
© Amit Singh
52 more annotations...
- January 2009
- Executive Summary
  
  This document discusses XBinary, a new software that lets you add kernel-level support for executing files in arbitrary binary formats on Mac OS X.
- —With the advent of x86-based Macintosh computers, Universal binaries, originally known as "fat" or multiple-architecture binaries, appeared in Mac OS X.
- Universal Binaries
- along with a header that describes each constituent binary.
- for one or more architectures
- a wrapper that contains Mach-O binaries
- a "4-way fat" executable could consist of Mach-O executables for the i386 (32-bit Intel), x86_64 (64-bit Intel), ppc (32-bit PowerPC), and ppc64 (64-bit PowerPC) architectures
- we'll need to write special software
- Mac OS X does not provide any kernel-level or user-level interfaces to extend binary format support.
- software will involve a kernel extension.
- extend the kernel
- new kernel functionality
- and execute them through specified handler programs.
- Extending Executability
- Let us call the new software that implements these features XBinary.
  
  binfmt_misc
  
  Those familiar with the Linux kernel will realize that functionality similar to what's been described here exists in Linux as the binfmt_misc kernel feature. XBinary is conceptually similar
- recognize arbitrary binary formats
- XBinary also has some Mac OS X specific features.
- a command-line tool (xbinary
- download and install the XBinary package
- a kernel extension (xbinary.kext)
- make experimentation involving new binary formats easy
- research software at this point
- for developers, researchers, and power users
- take XBinary for a spin
- XBinary: extended binary format support for Mac OS X
  Copyright (c) 2009 Amit Singh. All Rights Reserved.
  http://osxbook.com
  
  The XBinary software allows you to extend the Mac OS X kernel such that it
  can recognize arbitrary binary formats and execute them through specified
  handler programs. (Mac OS X natively supports executing only Mach-O binaries,
  Universal (fat) binaries, and interpreter scripts.)
  
  XBinary consists of a kernel extension (xbinary.kext) and this command-line
  tool, which lets you control the XBinary facility. This requires superuser
  privileges, so you should run this tool using sudo(8). The XBinary kext must
  be loaded for the facility to be available.
- The XBinary software
- using the xbinary tool
- You can add and manipulate in-kernel entries that enable recognition of
  binary formats.
- copious "help" output
- You can also specify flags that affect how a matched entry is processed. By
  default, the argument vector IS adjusted and setuid/setgid binaries are NOT
  allowed.
- Each entry must have as its name a unique identifier string up to 31 bytes
  in size. Additionally, a set of other arguments specify to the kernel how
  to recognize that binary format and which interpreter to invoke to handle
  it. XBinary can recognize a binary EITHER by matching magic bytes within
  the first page of the file OR by matching a file extension. OTHER_ARGS must
  be a valid combination of the following arguments (some are optional).
- These examples assume that you are on an x86 (little-endian) machine.
- Let us look at Java applications
- given a Java class file
- then specify this wrapper script as the interpreter
- a wrapper script
- and subsequently invoke the Java application launcher.
- We don't even have to write such scripts
  - :-) - on 2009-08-13
  Add Sticky Note
- that will determine the startup class name
- a Universal binary containing, say, Tiger and Leopard versions
- simplify code creation and maintenance.
- Consider a 2-way fat binary containing i386 and x86_64 architectures.
- Now think of an "extended" fat binary mechanism that incorporates
- operating system versions in addition to processor architectures.
  - :-) - on 2009-08-13
  Add Sticky Note
- Bonus Feature: Extra Fat Binaries
- our hypothetical extended fat binary contains eight "architectures"
- Since XBinary is experimental, why not experiment with such a feature too?
- the extended fat feature as implemented by XBinary is not a complete implementation
- choosing the best library from an extended fat library file.
- XBinary requires Mac OS X 10.5.x (Leopard).
- XBinary wouldn't be able to help the dynamic linker

29 Jul 09

Is ODF the new RTF or the new .DOC? Can it be both? Do we need either? - O'Reilly Broadcast

broadcast.oreilly.com/...ocument-file-format-lands.html - Preview

ODF HTML standard XML RTF doc Microsoft binary OpenOffice.org FOSS Sun IBM dataloss Portable Document Format 2009 Office Open XML World Wide Web Consortium

A fabulously written, very readable article with great insight. - grahamperrin on 2009-07-29
HIghlights are very disorderly (sorry) so be sure to read them as overlays to the original page. - grahamperrin on 2009-07-29
Quoting Gary Edwards, from his group on Diigo:

"The Web is the future … HTML+ (HTML5, CSS3, SVG/Canvas, JavaScript)." - grahamperrin on 2009-07-29
Highlights here are not only disorderly, I now realise that many of my highlights are lost :-( - grahamperrin on 2009-07-29

Again, the centre requirement is the document packaging
mechanism, enhanced to allow unpackaging and web service. The following
diagram, though almost uselessly general, lists various components that are
entirely common to both websites and XML-in-ZIP compound documents: why are we
squabbling in such minute detail on solutions to XML-in-ZIP formats that do
nothing to address this tectonic rift between documents and websites? Because
we allow our expectations to be dictated by menu bars: something that currently
has a Save As.. or Open menu item is real...
Is ODF the new RTF or the new .DOC? Can it be both? Do we need either?
87 more annotations...
- By Rick Jelliffe
  October 21, 2008
- recently wrote an article concerning the position of ODF,
  Open XML and PDF
- Jon Bosak
- Jon's public writings are rare, well-considered and
  always of interest.
- Jon
  has been exemplary
- he has a side, he does not take
  sides
- a potted history of the document format landscape over last 25 years
- One Thousand Islands
  
  At the start of the 1990s, the document landscape looked a
  little like this:
  
  In the above diagram, each of the bubbles represents
  numerous formats
- One Thousand Islands
  
  At the start of the 1990s, the document landscape looked a
  little like this:
  
  In the above diagram, each of the bubbles represents
  numerous formats
- Consolidation
  
  By the mid 1990s, this had changed, in a period of massive
  consolidation as the web, Microsoft and Adobe starved rivals of oxygen
- Consolidation
  
  By the mid 1990s, this had changed, in a period of massive
  consolidation as the web, Microsoft and Adobe starved rivals of oxygen
- Standard Generalized Markup Language SGML consolidated many
  divergent capabilities of existing markup languages
- One fairly unheralded aspect of this was the rise in the publishing
  community, including high-end vendors, of an awareness of the benefits of
  co-operation and standardization of different kinds. SGML was born out of such
  cooperation at ISO
- One fairly unheralded aspect of this was the rise in the publishing
  community, including high-end vendors, of an awareness of the benefits of
  co-operation and standardization of different kinds.
- Realignment
  
  By the end of the 1990s, there had been a realignment of the
  rationales for the formats: in particular, HTML had moved from the dumb end of
  town into having its own compelling rationale
- Realignment
  
  By the end of the 1990s, there had been a realignment of the
  rationales for the formats: in particular, HTML had moved from the dumb end of
  town into having its own compelling rationale
- Of these formats, Microsoft controlled .DOC, .RTF, and was
  actively involved at W3C in XML and HTML development. PDF was controlled by
  Adobe.
- Of these formats, Microsoft controlled .DOC, .RTF, and was
  actively involved at W3C in XML and HTML development. PDF was controlled by
  Adobe.
- Digestion/Stagnation
  
  The early part of the 2000s was a period of extraordinary
  growth for applications of XML, matched by stagnation in the other areas.
- Digestion/Stagnation
  
  The early part of the 2000s was a period of extraordinary
  growth for applications of XML, matched by stagnation in the other areas.
  
  The dynamism of the open standards was in marked contrast to
  the stagnation of the corporate-controlled formats.
- Microsoft adopted a policy of containment
- to prevent HTML from taking
  market share
- notoriously with an unwillingness
  to support CSS thoroughly
- to prevent HTML from taking
  market share from .DOC or even .RTF systems:
- notoriously with an unwillingness
  to support CSS thoroughly
- either import or export to a foreign format, but not
  both
- provide either import or export to a foreign format, but not
  both
- animation areas
  (e.g. Flash)
- remain non-standard.
- Standardization
  
  In the late noughties, a period of standardization broke
  through, with all the major formats being taken by their stakeholders through
  industry consortia and on to ISO.
- Standardization
  
  In the late noughties, a period of standardization broke
  through, with all the major formats being taken by their stakeholders through
  industry consortia and on to ISO.
- The enormous controversy over the standardization of OOXML
  comes largely down to, in my opinion, two different views of the emerging
  landscape.
- The enormous controversy over the standardization of OOXML
  comes largely down to, in my opinion, two different views of the emerging
  landscape.
- Business as Usual
  
  The first landscape (lets call it business as usual)
  sees ODF as superseding RTF
- In other words, the primary
  role of RTF is for medium quality
- OOXML distinguishes itself from ODF by being DOC-in-XML-in-ZIP, with an
  emphasis on fidelity to a particular rich feature set rather than
  RTF-in-XML-in-ZIP, with an emphasis on interchange between systems with a basic
  feature set.
- The Bermuda Triangle
  
  The second landscape (lets call it the Bermuda triangle)
  sees ODF as replacing .DOC, with RTF becoming swallowed by both ODF and HTML. I
  think this is the landscape anticipated by people who don't see much value in
  IS29500 or multiple targeted fornats.
- This second approach has a lot to commend it: HTML really
  does supersede RTF as being the interchange format for simple rich text.
- Getting There
  
  My own view is that the Bermuda triangle would be preferable,
  and it may be where we end up,
- standardize business as usual
- but that the only way there is to first
- hope of moving
  forward, but only if ODF, HTML and even PDF are significant improved, with
  proper vendor support:
- HTML needs to be developed further.
- ODF (2.0) needs to be re-developed with a view to better
  supporting alternatives and graceful degradation.
- Microsoft has its XPS format (another XML-in-ZIP),
- PDF has three challengers, none particularly serious at the
  moment:
- there is a mooted Chinese push for the OASIS
  UOML (Unstructured Objects Markup Language: a simple modern PDL) to be
  standardized.
- Adobe has some
  similar technology (MARS)
- various efforts to standardize profiles of PDF
- the challenge is for PDF with embedded SVG,
  and for ODF (2.0) with embedded PDF alternatives, and so on.
- if we are to move from business
  as usual to the Bermuda triangle?
- So what are common threads required
- Support for a common next-generation document packaging
  (XML-in-ZIP) format to be assertively supported by W3C, ODF (2.0) and
  son-of-PDF.
- Ubquitous support for unvarnished SVG Tiny, MathML, and XForms by
  W3C, ODF (2.0) and son-of-PDF.
- A co-operative carve up of RTF's functionality between HTML and
  ODF 2.0.
- A real effort to add support for features in IS29500 and UOF etc
  to ODF 2.0,
- with an emphasis on graceful degradation
- More support for richer XML media and specialist content types.
- down the path
  towards the Bermuda triangle.
- Carrots and sticks to entice and direct Microsoft
- these are just for word processing
  - ! - on 2009-07-29
  Add Sticky Note
- The Real Present and the Real Future
- the looming
  challenge for document standards is
- in integrating the packaged world of documents with the fragmented world of web
  resources.
  - This is very thought-provoking. - on 2009-07-29
  Add Sticky Note
- Page description files with external
  resources.
- Documents that can be websites.
- Web applications that are single
  files and editable as applications by word processors
- Arbitrarily nestable documents.
- in this vision, Open
  Office or MS Word (or perhaps MS Powerpoint) should be able to open up and edit
- a .WAR web archive file
- or their successors.
  - I imagine a gradual increase in awareness of potential benefits of WebArchive — within and without WebKit. - on 2009-07-29
  Add Sticky Note
- almost uselessly general
  - :-) - on 2009-07-29
  Add Sticky Note
- not an outlandish vision: there is piecemeal
  support for many parts already
- We need to be able to have our cakes and eat them.
  - +1 - on 2009-07-29
  Add Sticky Note
- support plurality
- I don't have high expectations of leadership from many other
  groups.
- FOSS people often are concerned with pioneering individual efforts
- rather than collective efforts.
- the large
  vendors or open source projects which straddle both documents and the web, such
  as Sun, IBM, and Microsoft, are still (I think) focussed on the dubious
  delights of business as usual and the Bermuda triangle
- Towards Web-able Document Formats
  
  So what is there that we can do to nudge us in the direction
  of this large-scale interoperability?
- encourage them to support plurality
  (modularity, alternatives, feature harmonization with each others standards,
  graceful degradation) and the dissolution of the great website/document divide.
- Participate in the most congenial
  standards body to your interests,
- foster good reasons (carrots and sticks) so that the large developers
  see value in this kind of enabling standard.
- make browser
  plugins that locate resources in an unzipped XML-in-ZIP document delivered
  from a vanilla web server
- enhance the existing XML-in-ZIP formats to cope with web
  formats (ODF and OOXML with CSS and SVG Tiny, for example) better
- round-trip
- lots to do —unblock
  the plumbing:

1 - 2 of 2

Showing 20▼ items per page

Selected Tags

binary

Related Tags

Top Contributors

Click in to find related links.

Groups interested in binary

The Apple Group

Members (572)

bookmarks (1392)
CTJHS Algebra II

Members (14)

bookmarks (101)
Free Ebook Gratis

Members (3)

bookmarks (180)

Related Lists on Diigo

Compatibility matters

The lessons of Massachusett...

Items: 6 | Visits: 10

Created by: Gary Edwards
Zaurus Software

Programs I've found that ca...

Items: 5 | Visits: 1

Created by: Xyzzy Zorker

Highlighter, Sticky notes, Tagging, Groups and Network: integrated suite dramatically boosting research productivity. Learn more »

Join Diigo

Graham Perrin's Library tagged binary → View Popular

XBinary: Extended Binary Format Support for Mac OS X

Executive Summary

`binfmt_misc`

Is ODF the new RTF or the new .DOC? Can it be both? Do we need either? - O'Reilly Broadcast

One Thousand Islands

One Thousand Islands

Consolidation

Consolidation

Realignment

Realignment

Digestion/Stagnation

Digestion/Stagnation

Standardization

Standardization

Business as Usual

The Bermuda Triangle

Getting There

Towards Web-able Document Formats

Selected Tags

Related Tags

Sponsored Links

Top Contributors

Groups interested in binary

The Apple Group

CTJHS Algebra II

Free Ebook Gratis

Compatibility matters

Zaurus Software