- 退職後に古い原稿を整理していたユーザーが 旧式文書の復旧 を試みる中で、WordよりもLibreOfficeのほうがさらに古いファイルを開けた事例が確認された
- Wordは 1994年以前のファイル を読めなかったが、最新のMac向けLibreOfficeは1992年・1989年のファイルに加え、1986年の文書までおおむね開くことができた
- 変換品質は完璧ではなく、1989年のファイルでは小文字の
a が サーカムフレックス付き文字 に置き換わり、1986年の文書には一部ボックス文字が現れた
- ユーザーは原稿をクラウドとTime Machineにバックアップしたうえで、古い長編小説9本、未完の小説2本、短編およそ15本を確認した
- 古い独自ファイル形式は下位互換性の維持コストが大きいため、LibreOfficeのような外部ツールが 文書復旧のセーフティネット になりうる
古い原稿整理から始まった復旧作業
- 退職後に執筆へ時間を使えるようになったユーザーは、修正や書き直しが必要な 未刊の長編小説 を一覧化し始めた
- Macを業務用VPNから切り離したあと、フォルダのリンクが崩れ、FinderのDocumentsをクリックするとネットワーク上の場所を探して失敗する問題が発生した
- 再起動後、ユーザーディレクトリから直接Documentsに入ればアクセスできた
- すべての執筆フォルダをデスクトップにコピーし、古い長編や短編原稿が失われていないことを確認した
- 当初は完成した本が7本だと思っていたが、実際には 完成原稿が9本 あった
- そのうち3本は三部作を構成し、ある小説には続編が混ざっていた
- 未完の小説は2本あった
- 短編は約15本あるようで、複数フォルダの投稿記録からかなりの数が完成稿だと判断された
PagesとWordが開けなかった地点
- 1996年に書かれたある小説は Pages が開くことを拒否した
- ユーザーはこの作品を、初期に売れる可能性が高かった面白いスペースオペラだと見ている
- Wordの導入と、古いファイルを開けるプログラムの調査を計画していたが、その後Wordが 1994年以前のファイル を読めないことを確認した
- Apple ][ 時代の長編原本も保管していたが、PowerPC時代にMacと2000年代初頭のWordバージョンで更新済みの状態だった
LibreOfficeが実際に開けたファイル群
- 別のユーザーが「LibreOfficeは古いWordファイルをWordよりうまく読める」と助言し、ユーザーは最新のMac向け LibreOffice をインストールした
- 1992年のファイルは問題なく開けた
- 1989年のファイルも開けたが、すべての小文字
a が サーカムフレックス付き文字 に変換された
- ユーザーはこの程度の問題なら受け入れられると考えた
- Macで日付検索する方法を見つけたあと、拡張子のない
The Revenger というストーリー・トリートメントを発見した
- 日付は 1986年3月25日 だった
- いくつかボックス文字はあったが、全体としては読める状態だった
- ユーザーはこの文書をAndre Norton風のSFスペースオペラの試みだと見ている
- LibreOfficeは
Tree Castle も開いた
- この文書はMac Draw文書だった、あるいはその可能性がある
- 日付は 1986年1月1日 で、ユーザーが所有する最古の文書だった
- ユーザーは文書変換用途でLibreOfficeを高く評価し、古い文書の内容の一部は未熟だったものの、失われた知的財産はなかった とまとめている
下位互換性維持の現実的コスト
- あるユーザーは業務でもLibreOfficeを主なツールとして使っており、古いWordファイルをWordよりうまく復旧できた経験が何度もあると共有した
- 元の投稿者は、Microsoftが自社の独自形式に100%の下位互換性を提供できないのは、単なる怠慢だけではないと見ている
- 下位互換性の維持には 開発者コスト とテスト・デバッグのコストが継続的にかかる
- 大企業のプログラマーには、ボーナスを除いても15万ドル以上かかる場合があると述べられている
- 管理方法、プログラミングパラダイム、言語要件、リポジトリアクセス、プライバシー基準、監査可能性が変わるたびに、コード維持の負担が生じる
- サポート対象製品全体に専任プログラマーが必要になったり、コード変更時には季節要員のチームや管理工数が必要になることもありうる
- ほとんどのユーザーは数年以上前のファイルを持っておらず、業務では最大7年保管がベストプラクティスとして挙げられた
- 古いファイルは更新するか、PDF化して保管することが多い
- LibreOfficeにとって古いファイルを開けることはインストールベース拡大の機能になりうえ、寄付も受けているため、完全な無償労働とみなす必要はないという見方も出た
- 外部ツールが失敗した場合、Microsoftはその技術サポート負担や訴訟・不買・悪評のリスクを外部ツール側に残しておける
オープンソースのバグ報告とツール生態系の経験
- 1989年のファイルで小文字
a がサーカムフレックス付き文字に変わる現象は、バグとして報告する価値があるという意見が出た
- ファイルをバグレポートに添付できれば、誰かが確認してくれる可能性がある
- LibreOffice Writerの段落分割ダイアログのユーザー体験の問題を報告し、議論の末に修正された事例も共有された
- 元の投稿者は、これまで使ってきたいくつかのオープンソースプロジェクトでバグを報告したものの、数年後に実際に修正されたのは1件だけだったと振り返る
- しばしば「自分で直してほしい」と返され、他人の問題修正は優先順位が低いと感じた
- Microsoftでも似たような対応を経験し、Appleはややましだが大差はないとも付け加えた
- Gitやpull requestのようなオープンソースの貢献手順は、一般ユーザーや一部の開発者にとって障壁になりうる
- 元の投稿者はZowe関連のオープンソース作業とOpen Mainframe Projectの必須適合プロジェクトで
.md の指示を書き直す必要があり、GitHubのpull request要件で詰まった
- メインフレーム、JavaScript、C、Windowsの開発者であっても、GitHub流のやり方に慣れていなければ新たに学ぶ負担が生じる
- 別のユーザーは、Gitに慣れるのは難しく、Mercurialは似た分散モデルでありながら、はるかに理解しやすいと感じている
- WordPerfectをめぐる議論では、多数のプリンタードライバーを参入障壁とみなした戦略が、かえって弱点になったという意見が続いた
- Windowsがプリンター対応を増やし続ける一方で、WordPerfectはもはや不要なプリンタードライバーを読み込むのに10分以上かかったという体験も共有された
1件のコメント
Hacker Newsのコメント
何度も修正され、コメントも付いたdoc/docxファイルをLibreOfficeで5分おきに保存していても、次にまた開けると信じてはいけない
Wordファイルを直接編集すると、LibreOfficeがいつか文書を壊してしまう可能性がある。LibreOffice形式で作業したあと、doc/docxに変換して送るほうが安全
問題は巧妙で、LibreOfficeは編集内容を表示し、修正もできるように見せるが、実際に保存されたファイルは破損していることがある。次に開くときになって初めて分かり、内部XMLのタグ不一致のように直せる場合もあれば、文書の大部分が消えて復旧不能な場合もある
MS Officeユーザーに送る必要があるなら、そのままOpenDocumentを送ればよい。Officeでも開けるし、問題が起きるならLibreOfficeよりOffice側のバグである可能性が高い
MS Officeユーザーも標準文書形式であるOpenDocumentに慣れる必要がある
Wordで変更履歴を有効にしたDOCXを作り、LibreOfficeで何度も編集・保存したあと、Wordで再び開いて修正して保存すると、Wordがそのファイルを開けなくなることがあった。LibreOfficeで開いて再保存すると直った
これらの事例はいずれも変更履歴に関係しており、DOCXにおける変更履歴の内部表現が「RTFや雑多なものをXMLにダンプした」残りの形式よりさらにひどいので、驚きではない
Word形式そのものを避けたほうがよい
ベンダーAは形式Aと自社アプリケーションを一緒に開発・テスト・修正し、ユーザーデータとバグデータをすべて持っている。ベンダーBは自分のアプリと形式も開発しなければならず、Aの組織的知識やデータを持っていない
したがって、BのアプリがA形式の複雑なデータをAと同じくらい安定して扱うのは難しく、A自身にもバグはある。この場合、Microsoft OfficeチームはLibreOfficeよりはるかに多くのリソースを持っている可能性が高い
以前、Joel Spolskyが書いたものだと記憶しているXLS形式の設計についての記事を読んだが、Excelの内部メモリ構造をディスクにダンプし、当時の遅いディスクで保存・読み込みを高速化するための最適化を加えた程度のものだった
彼は性能にかなり満足していたようだが、私は「このファイルを扱わなければならない他のプログラムは終わった」としか思えなかった。そして「他のプログラム」には、その後のバージョンのExcelも含まれる
保存目的で古いファイルを復旧するには、昔のDOCとXLSの内部文書があるとよいが、Microsoftが内部的にでもきちんと文書化していた可能性は低そうに見える
そのため、公開標準を求められるとDOCX/XLSXへ全面的に作り替えなければならなかった。Microsoftには文書化する方法がなかったからだ
ただしDOCX/XLSXにも「Word/Excelの内部バイナリダンプ」タグがあり、同じ罠にはまる点は救いにならない
https://www.joelonsoftware.com/2008/02/19/why-are-the-micros...
Spolskyの言う通り完全な混沌ではあるが、技術的には文書化されている
結局のところ、すべてのファイル形式はバイナリとして記録されたメモリ構造にすぎない
Windows 7へのアップグレード時期に、会社で使っていた古い勤怠管理ソフトウェアがもう動かないことに気づいた
幸いIT部門が解決策を出し、会社全員にUbuntu VMを配布してWineでそのソフトウェアを実行させた。結局、Webベースのソリューションに移行するまで数年間その運用が続いた
https://techcommunity.microsoft.com/t5/ask-the-performance-t...
ところが、最新のWindowsよりもLinuxのSteam Proton上のほうがよく動くことが分かった。もちろん、実際にプレイするのに十分なほど良好というわけではなかった
主な理由は勤怠管理ソフトウェアを使わせるためだった。製造現場の従業員のように2ドルのRFIDカードを渡せばよかったが、そうするとタイムクロックまで歩いて出勤打刻しなければならなかった
結局、Mac版になかった機能のためにWindows版Outlookも使っていたようだ
そのため顧客はソフトウェアを購入すると、適切なサイズのモニターを無料でもらえた。実話だ
Windows XP 時代のゲームを Ubuntu では実行できたのに Windows 11 では実行できなかった、似たようなことがあった
そのゲームは何らかの Direct3D を使っているが、Windows 10 以降では動作しなかった。マシンに Windows XP/7/8 をインストールしたくはなかったし、仮想マシンはグラフィックアクセラレーションの対応がいまいちだった
ところが、実際にインストールした Ubuntu 環境で Wine を使い、正しいファイルを少し探して入れたら動作した。さらに笑えるのは、Windows 11 の WSL 上で動く Ubuntu に Wine をインストールしたところ、その環境でもゲームが動いたことだ。昔のゲームをこんな複雑な方法で動かすことになるとは思わなかった
https://fdossena.com/?p=wined3d/index.frag
Windows で動作するコンパイル済みの wined3d DLL がある
https://github.com/doitsujin/dxvk
これも Windows で動作する
ゲームフォルダに入れるだけで、実際の DirectX の代わりにその DLL をロードするはずだ。昔のゲームを動かし続けるための古い API 実装は他にもあり、その一部は Wine を使う Linux ユーザーも利用している。たとえば dgVoodoo がある
http://dege.freeweb.hu/dgVoodoo2/ は、3dfx 時代のカードの独自 API である Glide と、DirectX 1〜7、8.1、9 をサポートしている
https://github.com/FunkyFr3sh/cnc-ddraw は、古い 2D API である DirectDraw 関連の問題を修正してくれ、Windows ユーザーと Linux で Wine を使う人のどちらにも役立つ可能性がある
https://github.com/otya128/winevdm は、64ビット Windows で 16ビットアプリを実行する
ここに Windows 自体の互換モード調整まで加えれば、VM の重いオーバーヘッドなしに、Windows 向けにリリースされたほぼすべてのゲームを動かせるはずだ。私の知る限り、WSL は一度確保したメモリを解放する方法も知らない
ゲームも、この驚くほど忠実な互換レイヤーの恩恵を受けており、今日では最新作を含む多くの Windows ゲームを、WINE で Linux に透過的にインストールできる
https://www.youtube.com/watch?v=Bg1NiXtrJ6g
https://www.youtube.com/watch?v=3b50Stm8gu4
手順が簡単だったのか気になる
皮肉なことに、LibreOffice で開こうとした古いファイル形式の一つが StarOffice 5 ファイルだったのだが、開けなかった
LibreOffice は OpenOffice から分岐し、OpenOffice は StarOffice をオープンソースとして公開したものだった。変換機能はコードベースを単純化するために削除された
複雑さはあるだろうが、StarOffice は今では固定された形式だし、OpenDocument も変換先として狙える古い固定バージョンがありそうだ
誰も違う期待をすべきではないが、Apple も iWork 形式の下位互換性を維持しておらず、開くために古いバージョンを探さなければならないレガシー文書がいくつかある
https://wiki.documentfoundation.org/ReleaseNotes/4.0#Feature...
2024年だというのに Excel は CSV を壊さずに開けないので、すべての CSV ファイルは LibreOffice で開いている
インポートウィザードがあるのは知っているが、それでもまだ時々壊してしまう
1990年代中盤から後半にかけて、ウイルス対策ソフトウェアを作る会社で働いていて、Word ファイルのマクロウイルスを検査する必要があった
ところが Word 1.0 ファイルを開けなかったため、Microsoft の社員が米国から直接来て手伝ってくれた。当時は比較的小さな英国企業だったのでかなり大ごとで、私の知る限り、そういうことがあったのはその時だけだ
やや秘密めいた形で進められたが、私が聞いた話では、Microsoft は Word 1.0 形式ファイルを読み書きする元のソースコードを失っており、コンパイル済みバイナリだけが残っていたため、新しいコードをリバースエンジニアリングしなければならなかったとのことだった
LibreOffice は互換性を目標にしているが、MS は顧客により新しく収益性の高いバージョンへアップグレードしてほしいわけなので、こういう結果は驚くことではない
あるアプリがバグや文書化されていない機能に依存していても動き続けるよう、特別な処理を入れるほどだった
SharePoint に載せるために xls/doc ファイル 100GB を変換したが、公開フォーマットで保存し直すだけで容量がおおよそ5分の1になった
LibreOffice が古いファイルをよりうまく開けるのはまったく驚きではない。Microsoft には、セキュリティ設定で許可しないと開けないようブロックしているファイルもある。ほぼ30年前のライブラリを変換していて、20年以上前のファイルも多かったのだが、今どきなぜこんなゴミのような互換性を持ち続けなければならないのか
小規模なクイックオイル交換チェーンで使っていたカスタムDOS アプリが、Windows 7 以降では互換性設定をどうしても起動しなかった一方、Linux の Wine ではうまく動いたという似たようなことがあった
アプリを再開発するまでの暫定策としてそう使っていた。コンソールアプリを使った経験から、代替アプリもコンソールアプリのままにし、Linux シェルで動くように現代化して書き直した。ライセンス費用もすべて節約でき、結局かなり満足しているようだった
Microsoft は10年以上前に、会社全体が一斉にどんな代償を払っても下位互換性を守るという中核原則から離れたように思える
16ビット DOS と Windows アプリケーションは 64ビット Windows では実行できない
古い日本語 Word ファイルを LibreOffice で絶対に開いてはいけない。ファイルを壊してしまう
古い日本語 Word ファイルは Shift JIS で保存されているのに、LibreOffice が UTF-8 として開くからだ
なければ、新しく立てたことがあるのか、再現用サンプルを共有できるのかも気になる。Bugzilla で「Shift JIS」を検索してみたが、何も見つからなかった
[1] https://bugs.documentfoundation.org/