新しいアーカイバプラグインを開発するスレ

今、多数のアーカイバが統合アーカイバAPI仕様を元に作られていますが、
開発者と利用者の利便を考えると既に時代遅れで、使いやすいとは言えません。
なら、いっそ新しい仕様を造ってしまおうYo！という目的のスレです。

圧縮解凍ソフトいいのはどれ？ Part6
ttp://pc2.2ch.net/test/read.cgi/software/1043165952/
プロジェクトページ
ttp://hikoboshi-arcm.sourceforge.net/

詳細は＞2-5ぐらい

プロジェクト概要
ttp://hikoboshi-arcm.sourceforge.net/index.php?%5B%5BAbout%5D%5D
API仕様(策定中)
ttp://hikoboshi-arcm.sourceforge.net/index.php?%5B%5BHPD_API%5D%5D
雑談
ttp://hikoboshi-arcm.sourceforge.net/index.php?%5B%5BLounge%5D%5D

・Unix、Macの事情に詳しい方
・プログラムや文章を作ってもらえる方
・圧縮形式一覧を拡充してもらえる方
・その他、意見番さん(煽りは勘弁)
いつでもお待ちしております。おながいします。

FAQ
Ｑ．目的は？
アーカイバを扱う新しいプラグイン仕様の開発。
Ｑ．統合アーカイバとやること被ると思うが？
被りますが何か？
Ｑ．具体的には何をやってるの？
プロジェクトページをご覧ください。
Ｑ．ソース(もしくはバイナリ)はまだ？
仕様やら何やらが固まり次第書き出します。バイナリはﾏﾀｰﾘとお待ちください。
Ｑ．誰がやってるの？
(ここで言う)営農ギコでつ。よろしゅう。
Ｑ．そんなことより聞いてくれよ>>1よ(以下略
このスレか、プロジェクトページ各所に設けてあるフォームへどうぞ。

このプロジェクトに関連した話題以外は、各種圧縮スレへどうぞ。

人柱以外にはなんにも手伝えないけどおめ
焦らず良いもの作ってくらさい。期待しとります。

スレタイトル見てただの依頼スレだったらあーやってこうしてやろうと思ったのだが

>>1
板違い
そういうことはプログラム板でやろうね

そう言えば肝心なところでｗ
もぅ、お茶目なんだから♥

>>7
この板でもプロジェクトやってるスレはあるので。
ユーザ側の意見を伺うには、こちらが良いと判断した次第。

もちろん、ム板とかLinux板とかにも（スレは立てないものの）色々と
伺ってみようかと。

あ、もちろん細かい開発などの話はプロジェクトページの方をメインにヨロです。
こちらはテスト版提供とか、全般的な要望が中心つことで。

激しく着たい

ネタ振ってくらはい。

テスターはアーカイバの作者が対象だよね？
具体的にどんな機能つけるの？

>>13
別にアーカイバ作者ではなくても( ﾟДﾟ)ｳﾏｰ
アーカイバDLL経由せずにやりたいもんで、互換性とか検証してくれる方はやぱ必要。

機能としては、普通に圧縮解凍その他を、なるべくシンプルにするべく考えてます。

非常に期待しています。
統合アーカイバ＋αレベルではなく、世界標準を目指して欲しい。

情報むしりとって、その挙句シェアウェアにするんだろ？

朝っぱらから妄想の華やかな人が。

>>16
しっかり読んでね。

>>16

「修行中のアマグラマーである漏れは、シェアウェアなど作る資格なし。」
・・・と思ってまつよ(笑

もちろん、ここで作った物はできる限りソース付きのフリーソフトにします。

rarや7zを扱えるDLLは出来るの？
それが無ければはっきり言って使えない。

7zはオープンソースだから問題ないでしょ。
rarは圧縮は無理。解凍はどうだろ。

>>21
解凍はなんとかなると思う。
圧縮も、内部で rar.exe を呼び出す方法で実現可能。UNIX でも同じ。

要するに今までと同じって事ですね。

>>22
rar.exe を呼び出すって、結局コマンドラインを送るって事？
それじゃ、統合アーカイバとやることいっしょじゃん。
ってことは統合アーカイバに皮をかぶせるだけでOKってことになるけど。
7zは7-Zip自体UNIXに対応してないけどできるのかな？

とりあえず物がでるのを待とうぜ

結局lzhとかzip以外は統合アーカイバのラッパで終わりそうなﾖｶﾝ。
まぁ、それでも使いやすくなるならいいけど。

>>24
シェアウェアとかの影響で、内部で扱えない場合は、その方法しか無かったりする。
でも統合の方とはやってることが違うと思う。

7zは・・・ソース見る限り、激しくWindows(・∀・；)
UNIXに移植するとなると大変っぽい。

>>26
ラッパは(やむを得ない場合を除き)なるべく避けたい。

これってユーザが使いやすくなる云々の次元ではなく
・マルチプラットホーム
・共通仕様
というところに重点があるというだけで、あんま長所は無いかも。
強いて言えば設定が容易になるくらいかな。

エンドユーザーにとってのメリットはｳﾆｺｰﾄﾞ対応ぐらい。

作者さん達には結構大きなメリットがあると思うので期待してますが。

新Deaces作成中NAOさんも巻き込んでみると面白くなりそうかな（野次馬）。

LHAのおっさんもキボンヌ

>>29
ウニコードにするとどんな良い事があるの？

>>31
ファイル名

ファイル名ってアーカイバに格納するファイル名のこと？
それだったら7zのように圧縮形式自体がunicodeで格納する仕様じゃなければ
一般のアーカイバで解凍できなくなって激しく迷惑なんですけど。

そんな話なのか？

DLL内の文字処理でunicode使うってのならエンドユーザにはほとんど恩恵ないし。
処理内容によるがむしろ文字コード変換のために余計時間がかかるかも。
unicode版でビルドするなら速くなるだろうが、その場合win9x系で使えなくなるしな。

って、良く見たら>33でアーカイバとアーカイブ（書庫）間違えてた。

WinRARなんかはunicodeファイル名は無理やりs-jis変換して格納するね
このあたりは各アーカイバで仕様が違ってくると思うので対応が難しいと思う
対応できたとしてもそのアーカイバでしか利用できないアーカイブができてしまう

>>35
Windowsでunicodeファイル名が作れる以上、もうunicodeに対応するしかない。
ユーザが作ったファイルを扱えないアーカイバなんて、これから先許されないと思う。
XP,2000は内部的にもunicodeベース。
速度も裏でSJISにコード変換しているほうが時間がかかる。素直にunicodeを使った方がいい。
ビルドに関してはアプリはW系とA系のAPIをラップすればいいとおもう。
少なくともSJISに拘っていたら、世界標準にはなれない。

>>37
うん、漏れも実は同意見だよ

でもなぁ、他のアーカイバで解凍できないアーカイブができちゃうんだし
いくら『世界標準』だっていっても実際には殆どのアーカイバで解凍でき
ないのが現状なんだしなぁ・・・ま、SYNさんと同じ考えではあるんですが・・・

＃unicodeファイル名が格納されているLHA書庫って不気味でちょっと面白い

>>37
すでにファイル名がUnicodeで格納されるのを想定して作られてる形式・・・
（たとえば7z。rar3.xもそうだっけ？）を扱う場合は 当然アーカイバ側も
Unicodeで処理するべき、というのなら激しく同意。

あるいは、今後作られる書庫形式（DGCAとかね）がUnicodeファイル名を
扱えないなんてのは許されん、というのも猛烈に同意。64bitのファイル
サイズとか日時管理、についても同じことが言えると思う。

けど、既存のlzhとかzipとかを扱う統合ライブラリを作る（>>1さんが
考えてるのはとりあえずはこれだよね？）、ってんなら要するに今存在する
他のアーカイバでは解凍できない書庫を作成してしまおう、ってことに
なるわけだから、これは賛成できない。euc-jpとsjisですら混乱してるのに
余計わけがわからなくなるだけだろうから。

---

SYNさんの構想としては、古い書庫形式との互換性とかは切ってしまって、
これからの時代にあったunicode/64bitなフォーマットを統一的に
扱えるAPIを設計しよう、ということ？
その辺はっきりしないせいで混乱を呼んでるような気がする。

>>40
ちょっと混乱あったかなぁ？
LZHやらRARやら、ファイル名を Shift-JIS で格納するものについてはShift-JIS に
変換して格納するつもり。無理に Unicode にして互換性を無くしたくない。

そのような形式だと、少々速度は落ちそうだし、一部文字の欠落も考えられるが。

・・と書くと、プラグインを作る側で大変かと思うが、その辺は補助ライブラリで
文字コード変換のための関数を用意するつもり。

>>35
ちなみに、Win95 以降なら普通に Unicode とか W 系関数は扱えたような。
ただ、UNIX 側の事情はまだ調査中。

>>37
＞Windowsでunicodeファイル名が作れる以上、もうunicodeに対応するしかない。
たしか9xは扱う事が出来なかったはず。
＞XP,2000は内部的にもunicodeベース
NT系のみで考えるのであれば確かに速くなる、が、9x系も考えると遅くなる。
と言う訳で9x系は捨てNT系だけに絞るのというのであればそれもアリかとはと思う。
9x系の人は既存の奴でも使ってくれと言う事で。(個人的にそれは嫌だが）
しかしlha等のunicodeでファイル名を格納する事を考えていない形式に
無理矢理unicodeで突っ込むとか言うのは不正書庫を生むだけなので論外。

>>41
W 系関数は扱えないです。

>>39
>＃unicodeファイル名が格納されているLHA書庫って不気味でちょっと面白い
LHAでは日本語ファイル名は ShiftJIS使うのは仕様で決まっているので、単なる不正書庫ですね。

>>37
Unicode はベンダ毎に一部文字の割り当てが違ったりしてるので
逆にユーザに混乱を与えるかもしれません。

日本以外でもこーゆー事が起こっているのかは知らないですが。

>>43
そぉ？

ﾏｼﾞで最初のWin95(Kernel32.dll)
...
0154 0003541c CreateDirectoryW
0155 000073f1 CreateEventA
0156 00035452 CreateEventW
0157 00007893 CreateFileA
0158 00007479 CreateFileMappingA
0159 00035476 CreateFileMappingW
0160 00035488 CreateFileW
...

普通に関数名あるのだが。
ただ、使えるかどうかは試してない。

LHAは和製なのでShiftJISでいいと思う。
っつーか作者のおっさんが決めることだと思われ。

>>45
細かい問題だなぁ・・・　(・∀・；)
どうすりゃいい？できれば標準仕様の Unicode に沿いたいが・・。

>>47
・・・でいい、というか、Shift-JIS「 じゃなきゃ」混乱するという見解。

ま、拡張ヘッダで Unicode ファイル名を入れることは可能だけどね。
そのうち Unlha32.dll の作者さんが実装するかもしれんし。

別にユーザーに直接的なメリットはほとんどない、ってんでも
作者さん等にメリットがあるなら一向に構いません。

>>42
つか、MSDNにはっきり書いてあった・・・。(；´Д｀)
>Windows95 では Unicode 規格をサポートしていません。

API を避ける方法をとるにしても、Win95 のサポートは大変そー。

＃98以降なら( ﾟДﾟ)ｳﾏｰということが言える。

Win95はサポート終わってるし、Meも今年でサポート終了。
NT系推奨で9xでは多少速度落ちるって感じでも構わないと思う。

>>48
>ま、拡張ヘッダで Unicode ファイル名を入れることは可能だけどね。
で、非互換の問題が増える、と。
個人的には、LHAみたいな「枯れた」と思われている形式に
わざわざトラブルの種になるような拡張をして欲しくないです。
UNLHA32.DLL の作者さんが同じ意見かどうかは知らないけど。

もし互換性とろうとすると、結局 ShiftJIS のファイル名入れなきゃいかんし。

俺の言いたいことみんなが書いてくれちゃってる

>>52
いくらLHAがかれた存在でもシェアはGCAより遥か上なんだよね

>>52
僕は LHA 形式の拡張はするつもりはありません。一応。

ただでさえ LHA は拡張ヘッダのカタマリだし。いじりたくない(w

俺は何だかんだ言ってソフト配布しる時はLZHだったなぁ。

規格がunicode+64bitにしようというだけで、実際に書庫内でどういうデータになっているかは
関係ないのではないでしょうか。
別に書庫が架空の文字コードを持っていても、受け渡しでunicodeにすればOKだと思います。
扱えないファイル名を受け取ったら、現状のようにエラーを返せば良いわけで、
過去の形式を拡張する必要は全く無いと、個人的には思います。

おまえらがあーだこーだいてる間に完成させちまいますた

と一度言ってみたかったんです。

>>50
MSDNのWindows95ってWindows9x系のOSを指すんじゃないかな？
だから98もMeもダメだと思う。試してないからわからないけど･･･。
つーか、マルチプラットホームを目指すならWin32APIを使うのは無しでしょ。

>>59
だからラッパーを使って各OSに対応するようにするんでしょ。
第一、ファイル処理回りはAPIを使うかか処理系依存の関数使うかの
2択しかないはずだが｡
（Cにはファイル移動・削除関数がないし）

>>54
吉崎さん、多忙で開発がストップしているのだし、この際、統合アーカイバ作者
とも皆で話し合って拡張ヘッダの仕様を決めれば良いのでは？
昔のNifty FLABOみたいに

＃ でも面倒そう(無理があるかも)＜unicode

>>59
となると、真に Unicode のファイル名が扱えるのは NT 系のみ、ということか・・。

ま、どっちにしてもWin32のfopen()系関数じゃ4GB超えのファイルサイズは
扱えないみたいだし、ラッパーは必須かと。
＃Unixだと、libcのfopen64()系でなんとかなる・・・のか？(汗

>>61
Unlha32.dll の作者さんに相談すればなんとかなりそうなのだが。

>>62
ためしに統合アーカイバの開発系MLで提案してみたら？
ttp://www.csdinc.co.jp/archiver/dev/ml.html

>>60
あれ？renameやremoveってCじゃ無かったけ？
確かコピーは無かったと思うけど･･･。
いまいち純粋なCは分かってなかったりする。
ただ、これらもユニコードは使えないんだよなー。
VC++なら_tremoveでいけるけど。

>>64
ごめん、調べたらあったわ｡
ないのはディレクトリ周りの関数だっけな？　←自信がなくなってきた

Win9x の Unicode 対応だけど、これを使えば可能っぽい。
ttp://download.microsoft.com/download/platformsdk/Redist/1.0/W9XMe/EN-US/unicows.exe

つことで、ファイル周りの関数を実装中。
しかし、Win はいいが Linux 辺りはどう対応すべきか。
Glibc がそのまんま Unicode 対応なら楽なのだが。

LHA拡張ヘッダの仕様を統合アーカイバの開発系MLで提案しる

>>67
やりたきゃ自分でやれば良いのに…

正直LHAの拡張仕様は(ﾟ�听)ｲﾗﾈ


つーかヤメレ

>>69
不可能なことは無いし、互換性がなくなることは無い(拡張ヘッダにまだ空きある)。

で、>>67さん、提案して(　ﾟдﾟ)ﾎｽｨ。

>>70
きちんとした提案があれば他のアーカイバも従うのではないかと思うのであるがなぁ

>>69
漏れは全体の事を考えて発言している

>>71
>他のアーカイバも従う
・・・のか？

対応済：7Z
言えば対応できそう；LZH
苦労かも：ARJ、ZIP、TAR、・・・
無理ぽ：ISH、CAB、・・・

統合の方で、仕様拡張の融通が利くのは Unlha32.dll ぐらいだと思う。

LHAにunicodeが欲しい。Unlha32.dllにも働きかけてくらさい
64ビットタイムスタンプとファイルサイズ拡張ヘッダはUNLHA32.DLLの
拡張ヘッダ仕様に従えばいいんだし

まぁ、全体のことを考えてても他力本願なことしか言わないんでは意味はなかろ

要望だったのだが

CABは某社のお気に入りだからね。

>>69
公開MLで潰しておいたほうが安全では？

>>77
とか言われると提案しにくいなぁ(・∀・；)

さぁ！労農ギコ氏が漢を上げられるかどうか！非常に見物です！ｗ


ま、多少強引に行っちゃっても大丈夫なんでない？

女の子はリードしてくれる男の人が好きです。

でもレイプは嫌いです。

UnicodeはUTF-8使うって書いて有るけど
NTの内部はUTF-16LEじゃなかったでしたっけ？

>>82
UCS-2だと思ったけど、サロゲートペアに対応していたっけ？
まぁ、どっちでもいいのだけど、UTF-8へのコンバートは軽いし、
UTF-8の方が過去の文字列処理の資産が利用できるので、いろいろと楽ですし、
ASCII文字(7bit)だけを使っている人は、特に何も考えずにUTF-8へ対応できるので、
有利な面が多いと思います。

>>83
内部はどうか知らないですけど、少なくともAPIに渡す文字はワイド文字じゃないと。
その度にわざわざ変換させるつもりなのかな？
それともそのまま突っ込んでも問題なく動作するのか。
それにマルチバイト文字とワイド文字の変換なら
nkf使わずともmbtowcやらwcstombsで一発で出来るし。
ま、どっちにしろ文字変換にかかる負荷など
圧縮・解凍の負荷に比べたら無視できるレベルのもんですけど。

っつか、そんなに Unicode 使いたいなら .NET やら Java やら使えば…

>>84
マルチバイト文字⇔ワイド文字の変換はテーブルも必要で、かなりのコストがかかりますが、
UTF-8⇔UCS-2の変換はテーブル不要で負荷はほとんど無視できます。
文字列処理に関しては、APIに渡す時だけワイド文字にしてでも、
それ以外はUTF-8を使ってASCII感覚で処理する方が楽だと思います。
本当ならOSでUTF-8をサポートすべきだと思いますけどね。A系、W系、U系とあると嬉しい。
自分はWinAPIにU系のラッパを用意して、OSによってA系とW系を呼び出すようにしています。

>>86
>それ以外はUTF-8を使ってASCII感覚で処理する方が楽だと思います。
扱うんだったら UCS-2 のが楽じゃないの？
ASCII 感覚ってのが具体的に何のこと言ってるのか良くわからんけど。

>>87
まぁ確かに何を楽と思うかは人それぞれですし、UCS-2の方が楽な人もいるとは思います。
ただ、ソースコードを含む、あらゆるテキストを世界で何かに統一するとしたら、UTF-8が良いとは思いませんか？
ASCII文字で書かれた物は既にUTF-8にもなっているわけですし。

この新しいアーカイバプラグインの登場によって、統合アーカイバDLLも
刺激され、お互い良い意味で発展すると面白い
個人的にはLHAの昔からのファンなのでＭｉｃｃｏ氏にも奮起して頂いて
unicode対応、あと、幻だったLevel3ヘッダ形式に対応したりするとますます
面白いのだけどなぁ。新形式でlh8なんかも対応しちゃったりして

>>88
いや、テキストを保存する訳じゃないしそんな例えは全く見当違いかと。
それからAPIに渡す時だけワイド文字にしてってのもAPIが使われるのは1度だけじゃないんですよ。
あらゆる場所で使われる訳ですしいくら負荷が軽いといっても積もれば山ですよ。
それにDLLを使う側から見ればファイル名とかをUTF-8なんかで返されたら
自分たちも変換しなくちゃ使うことが出来やしない。
DLL使う側にもnkf使わす気ですか。扱いにくくしてどうするんですか。
ついでにASCII文字しか使わない人はそりゃいいかもしれませんが
だからと言ってマルチバイトの事を無視する事は出来ないです。
マルチバイトのことを考えてない海外製のソフトはたくさんありますがあれと同じですよ。

>>85
そうですねぇ、.NET使うのが一番手っ取り早いかも。
これならマルチプラットホームの対応もデフォですし。

>>90
ファイル名処理をテキスト処理の一部と見なすか否かという違いではないでしょうか。＞見当違い
USC2⇔UTF8は変換といっても数行のコードを書くだけですし、
負荷も引数のキャストと思えば、気にするほどではないでしょう。
それを気にするなら、現状の裏のSJIS⇔UCS2変換コストの方が遥かに重いです。
また世界では、ASCII文字しか考えていない人が多いという実情は変えようが無いです。
国産でもSJIS以外のマルチバイトのことを考えている人がどれだけいるでしょうか？
あと、ワイド文字の場合、将来U+110000以降の文字が出て来た時にどうするのですか？

>>89
Level 3 ヘッダは UNLHA32.DLL で実装されていますし、
-lh8- も既に使われていますね。

>>91
>あと、ワイド文字の場合、将来U+110000以降の文字が出て来た時にどうするのですか？
WindowsAPI 等と歩調を合わせて変更していけばよいのでは？

それに U+110000 まででもファイル名に使う文字集合としては十分な気がします。

>>92
そうなの？ やっぱりさすがだなぁ・・・。

案外、unicodeなんかも既に拡張ヘッダで対応しているのかも・・・。
コメントアウトされていたりして。

>>94
あー… 誤解されると困るので一応補足。

>>92 に書いたのは Level 3 ヘッダは幻でもなんでもなく、
-lh8- も既に誰かが使っちゃってるので今更使えない、って意味です。

なんか既に役者が揃っているような予感がしますが・・・
unicode対応に向けてのLHA拡張ヘッダ仕様をここで一気に決めちゃったら(笑)

>>91
文字の保存コードがどうのこうのは単純に内部処理と置き換えられるものじゃないですよ。
で、USC2⇔UTF8は変換はキャストと思えばいいってキャストと比べれば遥かに重いですし
キャストを多用するプログラムなんて決してよい物だとは思えません。
それからSJIS⇔UCS2変換を問題にするのならSJIS⇔UTF8変換を問題にしないのは変では？
次にマルチバイトを考えない人が居るからこそワイド文字を使おうってんじゃないですか。
ワイド文字なら考える必要も無く対応できます。

結局UTF-8は標準から外れ混乱とプログラムの複雑化と速度低下を引き起こし
ユーザの利便性を下げるものでしかないとおもわれ。
利点としてはACSCIIしか使わない極一部の人がそのまま移行できるのと
将来Windowsの仕様が大きく変わらなければ使うことが出来ない
U+110000以降の文字が扱えるといったとこぐらいかな？

ファイルに保存する文字コードはUTF-8をってのならまだ分かりますがね。

64Bit&Unicode(8か16かは未定)対応なファイル処理ライブラリを書いてるとこでつ。
しかし、実際にUTFの問題とか・・・ややこしぃ。

>>82
そだったかな、つことでMSDN見てみたけどやっぱUTF-16っぽい。

>>85
それじゃあ面白ない。

>>86
W系の扱いが謎なんすよね。
_UNICODE定義してればUnicodeになるんだけど、じゃないとMBCS。
まぁ、今回MBCSは使わない方針ですが。

Win9xでは、Microsoft Layer for Unicode(unicows.dll)使って楽すべきかどうか。

>>95
誰か使ってるのか・・。て誰？LHA32？

LHAのおにいさん降臨(･∀･)ﾏﾀﾞｰ?

>>98
Unicodeについていろいろ書こうかと思ったけど
DBCS使うとの事なのでもう止めときます。
でも.NET Frameworkは選択肢の1つとして考慮したほうがいいかと思います。
7-Zipなんかも今後.NETで他のプラットフォームに対応させるそうだとか。

>>97
>それからSJIS⇔UCS2変換を問題にするのならSJIS⇔UTF8変換を問題にしないのは変では？

問題にするというより、現状のXPや2000でマルチバイトを使っている時は気にしてないのなら、
UCS2⇔UTF8は負荷として気にする必要がないということです。SJIS⇔UTF8については、
2000やXPではそんな変換パスは不要です。それに、この規格が広まる頃にはWin9x系は
絶滅していると思います。
とはいえ、おっしゃるとおりのワイド文字の方のメリットを考えるのなら、この規格はワイド
文字(UTF16orUCS2)にした方がいいでしょうね。ただ私個人はそれが理解できないので、
余計な事を言って混乱させないためにもここは引いて見守るだけにします。

この際後方互換を諦めるのも手なのかもね。ME使ってる人間が言うのもなんだけど。

とりあえず SJIS/EUC⇔UTF-8⇔UTF-16 の変換関数は用意しようかと。
もうわけわからんというのが本音なんですが、対応しなきゃ先に進めないもんで。

>>100
>.NET Frameworkは選択肢の1つ
なるほど。

といっても、統合の方で出た話題なんですが、Win32 DLLの状態では.NETに
対応することは難しいようです。
COMでラッパー書けばいいようですが、色々と制約あるようで。

>>100さん、V?.NETでのプログラム書けます？
漏れは.NET方面はあまり知識ないもんで(；´Д｀)

>>103
あらら、DLLだと対応は難しいんですか。
わたしも実際に.NETを使ったことは無いんで･･･。
雑誌やウェブでどんなものか調べたぐらいの知識です。

>>103
おいおい、大丈夫なのかな？

アカイーバできましたか？

新しいアイカバーの話題はこっちには流れてこないかな。

×アカイーバ
○アカーイバ

愛馬鹿

（＾＾）

プラグインという形態から考えて､GPLなソースを利用する形式への対応は無理じゃないの？
（GPLなプラグインを利用するソフトは必ずGPLでなければならないため）

>>107
新しいアーカイバ？なら形式スレで Ratbeta 氏が流すと思うが。
それじゃ違う？

>>111
>GPLなプラグインを利用するソフトは必ずGPLでなければならないため
そうかなぁ？特に問題ないと思っていますが。

GPLなモジュールを、(GNUで言う)独占的プログラムから呼び出している
事例もありますし。もちろん、GPL部分はソースを公開していますし、動的
リンクの状態で、ですが。


一応、プラグインってのは動的ライブラリ(DLL)の形状ですし、プラグインを
呼び出す(管理する)モジュール等は GPL と矛盾せず、GPL より緩い
MIT ライセンスを適用するつもりなので、その辺は大丈夫と考えています。

>>112
ところで君、統合の方ではなんのDLLの作者なの？教えてきぼん

統合の方には参加していないのではないかな。

>>113
えーと、それは・・・じきに分かると思います(ﾟ∀ﾟ；)

確かに漏れは統合の方も参加してますが。

Unyz1とUnace32じゃないの？

UNIMP32.DLL! でしょ？

ぉぉっと？

>>116

(；ﾟДﾟ)　・・・・。
完全にバレてやしたか。


ちなみに、Unbel32やJam32なんかも。(ぉぃ

＃突っ込まれる前に言っておきますが、厨房の頃に書いたDLLは下手でつ。ｽﾏｿ。

>>117
Unimp32.dll は HyperBeat さんのDLL。

じつはUNKO32.DLL

lzh
zip
cab
tar
rar　 ○
bga　△
gca　◎
yz1
ace
7z　 ×
他　 注

あら、予想して書いてるうちに答えが…。
しかもかすりもせず。鬱だ、死のう。

そうそう、ばれた方が親しみやすいし応援しやすい
頑張れ、応援してるよ！

つーことは・・・
Lmu+fFpM＝UNIMP32.DLL作者かな？
ど−でもいーんですけどね！

>>121
何の図すか？

>>123
ありがとうです。未だ未熟ですが頑張ります　･ﾟ･(ﾉД`)･ﾟ･｡

漏れはこう読んでた

lzh
zip
cab
tar
rar
bga　×
gca　△
yz1
ace
7z
imp　◎
他　 ○

はずしたな・・・

>>125
なんの。頑張れー！

ライセンス形態はBSDのが良いと思うなぁ。GPLは拒絶感ある人も居るやろうし。

>>127
もちろん、そのつもり。
ここでは、BSD ライセンスと等価な MIT ライセンスを使います。

BSD License
http://www.opensource.org/licenses/bsd-license.php
MIT License
http://www.opensource.org/licenses/mit-license.php
GNUによる、各ライセンスの見解
http://www.gnu.org/licenses/license-list.ja.html

ん。分かってますえ。要するに>>112に同意ってことで。

http://linux.nikkeibp.co.jp/column/ash/license/FreeLicense.org.html

>>119
＃突っ込まれる前に言っておきますが、厨房の頃に書いたDLLは下手でつ。ｽﾏｿ。

ライセンス形態以前の問題で・・・
もう配列とポインターの違いやCの基本的な理解はだいじょうびなんかな・・・？

コラ！

スマソ！(爆)

>>130
その辺は今は大丈夫です。既に C++、STL も分かるようになりますた。

＃始めて書いた C プログラムが DLL だったりする漏れ・・・何かが違う(藁

＞＃始めて書いた C プログラムが DLL だったりする漏れ・・・何かが違う(藁
はじめは基礎的なものから学習しようね。
DLLってみんな利用するものなんだし。そのあたりはくれぐれもご理解を。

でも見守ってるよ！

コラッ！

>>134
まぁそれは分かってます。いきなりDLL書いた漏れでしたが、その後
(普通な)基礎的なことを習得しますた。
＃Unbel32は厨房全開なDLL・・・書き直さないと。。


それはそうと、最近全く動き無いYoと思ってる方。
その通りです。申し訳ない。
現在、個人的にバタバタ？してる状況なんですが、4月から本格的な
実装に集中するつもりです。もうしばらくお待ちくださいまし。

今月はまだ準備つことで、よろしくです(・∀・)

保守

こういうスレから何かが完成したためしがない

こんな早い時期に何を言うか。まだまだこれからだ。

なあ>1よ…と責任丸投げしてみる

>>140
ny

おにいちゃんいいのがｱﾙﾖ!!

>>141
責任なんたらの問題じゃないっしょ。


現在 Win32 の W 系関数を実験中。
・・・って、これって UTF-16 なのかぁ。めんど。(ぉ

がんがってくらはい。

といつも通り応援だけしときます。

スレは動いていないように見えても、
動いている人はいるのだ。

dat落ちしなければいいね。

このプラグイン使う人いるのかな。

う〜ん、できてみないと何とも言えない。

漏れは使ってみる予定。面白そうだし。

成果物を世に出すかは知らんが。

ここチェックしるのめんどいから
出来上がったら統合スレで報告してね

RKにも対応して欲しい

期待してますよ。
こうならないようにおながいします。

http://pc2.2ch.net/test/read.cgi/software/1031331041/

こんなのだったら悲惨だった

http://tmp.2ch.net/test/read.cgi/download/1048497322/

>154

いくらなんでもここの１はひどすぎだなｗ
ここはぜんぜんまともだと思う

現在ﾏﾀｰﾘとnkfを改造中でし。
libiconv を使うのもいいかなと思ったんすが、デカイし GPL。

まず Unicode 対応となると変換ライブラリは必須ということで。

>>152
もちろん対応しますよ。
ただ、DOS コマンドの形なので、アーカイブ内の一覧は難しいかと。

>>153-154
ｲｲﾀﾞｼｯﾍﾟｰ(ﾟ∀ﾟ；)
漏れはこうならないように頑張る次第でつ。
現在マターリペースですが、やるときはやりますんでー(・∀・)

ｶﾞﾝｶﾞﾚ!!

>>156
大体のDOSアーカイバにはリスト取得コマンドがあるから、
それを適切に加工できれば大丈夫じゃないの？

現に書庫内表示に対応しているアーカイバもいくつかあるし。

>>158
確かにそうなんですが、EXE 毎にリストを加工してちゃきりが無い、ということが
あるので・・・。

本当は、自前でファイル一覧できれば一番いいのですが。(RKとか

おそい
早く作れボケ

手伝えバカ

>160

　　　　　　　 ∧
　　　　　　　_|::::|＿_
　　　　 　／::|::::|　　＼
　　　　 /　　 |:::|　　　:＼
　　　　/　　　 ||　　　　:ヽ
　　 ┌|（⌒ヽ :||　..:⌒:　|┐　　 ／￣￣￣￣￣￣￣￣￣
　　　|::|::ヽ.__:）:||（___ノ　::|::|　　│　いつもソフトウェア板を応援してくれてありがとう。
　　　 |:|: ..　　 :||　　　 .. |:|　　│　このｽﾚは急に終了することになった。
　　　　:|: ..　　 ||　　　 ..||　＜　　いつまたみんなの前に姿を見せる事ができるようになるのか、
　　　　 :＼　［_￣］　/::|　　　│　私にもわからない……
::　　　　　|＼|_|_|_|_／:::|　 　　＼＿＿＿＿＿＿＿＿＿＿＿＿
　　 ＿＿|　|　　　/ /　:|＿＿＿
　 　＼　_| ＼ 　 /........ﾉ~ 　-r　　＼
　　＼....|:::＼:＼丿　/,　／,/...／._　＼
　 /....＼.レ...　／＼..|　/　　／　／￣ ｀＼
　 ﾚ.........|/....／ �R‐＼′

ここに動きはなくとも、プロジェクトページの方に色々書いてるから
そっちを見てもらえば動いてるかどうか分かる、ってことで。

それはそうと・・・文字コード変換に libiconv 使ってよかですか？
激しくデカイけど、コードの国際化ができそう。

見てますよん。

iconvか。中でｳﾆｺｰﾄﾞ通すんだっけ。どうだろ。
俺は別にいいと思うけど。

>>163
自作する。

>>165
きつい。(；´Д｀)

メインはアーカイバなもんで、自作とかしてると辛い。

じゃあ、ヤメロ

なーんつってな。

>>163
libiconvのソース改造して軽くしたら。

>>169
それもどうかなぁ・・・。


という訳で、HCL(マルチプラットフォームのための低次元ライブラリ)に何の関数を
乗せるかが大体固まって？きました。詳しくはこの辺。
ttp://hikoboshi-arcm.sourceforge.net/?%5B%5BHCL_API%5D%5D

開発者サイドの方(特にSYNさん)、ご意見とか追加希望とかお願いします。

乙

保守したい年頃

ZIPだけでも何とかして欲しいな。
unzip32.dllがあれだし

保守

（＾＾）

保守

やいこの野郎！馬鹿にされとるぞ！もっとがんがってくらはい！おながいしまふ。。。


Noah 〜 とりあえず圧縮解凍
http://pc2.2ch.net/test/read.cgi/win/1016177454/760
760 sage 名無し~3.EXE 03/04/19 13:16 ID:8rT+5DHY
>>759
そこならあまり期待せんほうがよろしいかと。
作成者がちょっと・・・(´ー`) ＜unixxxx.dll

だって。

>>177
ご心配ありがとうです。今勉強中っす。

馬鹿にされるのは慣れてるのでお気になさらないで・・・。

つことで、開発再開は1日後でつがな。よろしう。

あー、プログラミングとかの勉強って意味じゃないのでー。補足。。

> プログラミングとかの勉強
俺もCプログラミングの基礎って本持ってます。
貸しましょうか？なんつって。

気長に待ってるので適当に程ほどにがんばってくらはい。

　　 ∧＿∧
　　（　　＾＾ ）＜ ぬるぽ（＾＾）

>>179
皮肉るしか能のない奴よりはマシだから、まあ適当にがんばれや
ちょっとずつは進んでるようだから生暖かく見守っておくよ

禿同

密かに期待しつつジットリと生暖かい目で見守ってる。

いつか使えるようになればいいのだけれど。

遅いなぁ
ｲﾗｲﾗ

がんばれ

大和きゅん？

>>179
実は開発進んでないだろ？
がんばってくれヨ。
たのむぜ。
期待支店だから世。

期待保守

期待してたのにがっかりだ。

確かにがっかりだ。
やはり >>180 は実力不足だったのか。
期待だけさせといてよ。できないことは最初からやらないでね。

>>193
できないことは無い(むしろやらできる)のだが・・・
むしろ少しづつ進んではいるのだが・・・

今はソースに向き合う時間がそんなに無いんす。スマソ。

今月下旬頃からせっせと作ろうかと思ってますんで、それまでお待ちくだせぇ。

期待保守

早漏どものことはほっとけ。

はぁぁぁ、遅い。

遅漏ももんだいだべ。

>>194
馬鹿はほっといて
少しずつでも進んでるならからがんばってくらはい。

なんかプロジェクトページ消えてるようですが。。。http://hikoboshi-arcm.sourceforge.net/
できる気配ないから逃げたな。

>>200
たまに鯖落ちしてるんだよね。sf.netって。見れないこともありますがご了承を。

＃ちなみに、一度sf.netに立てたプロジェクトは消すことができなかったりする。

ってほんとに消えてるしオイ・・・(；´Д｀)

今すぐにデータ消えてるか確認することができないので、
とりあえず編集とかはしないでお待ちください。

よろしくおながいします>>200さん。

sourceforgeはセキュリティが甘いから止めた方がいいよ。

>>203
そうか。
ガンバレ。

>200

　　　　　　　 ∧
　　　　　　　_|::::|＿_
　　　　 　／::|::::|　　＼
　　　　 /　　 |:::|　　　:＼
　　　　/　　　 ||　　　　:ヽ
　　 ┌|（⌒ヽ :||　..:⌒:　|┐　　 ／￣￣￣￣￣￣￣￣￣
　　　|::|::ヽ.__:）:||（___ノ　::|::|　　│　いつもソフトウェア板を応援してくれてありがとう。
　　　 |:|: ..　　 :||　　　 .. |:|　　│　このｽﾚは急に終了することになった。
　　　　:|: ..　　 ||　　　 ..||　＜　　いつまたみんなの前に姿を見せる事ができるようになるのか、
　　　　 :＼　［_￣］　/::|　　　│　私にもわからない……
::　　　　　|＼|_|_|_|_／:::|　 　　＼＿＿＿＿＿＿＿＿＿＿＿＿
　　 ＿＿|　|　　　/ /　:|＿＿＿
　 　＼　_| ＼ 　 /........ﾉ~ 　-r　　＼
　　＼....|:::＼:＼丿　/,　／,/...／._　＼
　 /....＼.レ...　／＼..|　/　　／　／￣ ｀＼
　 ﾚ.........|/....／ �R‐＼′

Wikiデータが綺麗まっさらになっていたのを確認。
という訳で復旧は無理なので改修しまつ。ふぅ。

>>204
とは言ってもなぁ。sf以外に置く所考えてないし。

期待age

　　　　　　　　　　　　　　　 ＿∧＿∧＿∧＿∧＿∧＿∧＿∧＿∧＿
　　　　　ﾃﾞｹﾃﾞｹ　　　　　　|　　　　　　　　　　　　　　　　　　　　　　　　　 |
　　　　　　　　ﾄﾞｺﾄﾞｺ　　 ＜　　　　　　　　　　　まだぁ〜！？　　　　　　 ＞
　　　☆　　　　　　ﾄﾞﾑﾄﾞﾑ　|＿　 ＿　 ＿　＿　＿　＿　＿　＿　＿　＿|
　　　　　　　 ☆　　　ﾀﾞﾀﾞﾀﾞﾀﾞ! ∨　 ∨　∨　∨　∨　∨　∨　∨　∨
　　ﾄﾞｼｬｰﾝ!　　ヽ　　　　　　　　　ｵﾗｵﾗｯ!!　　　 ♪
　　　　　　　　　＝≡＝　∧＿∧　　　　　☆
　　　　　　♪ 　　／　〃（･∀･ #）　　　　/　ｼｬﾝｼｬﾝ
　　　　♪　　　〆 　┌＼と＼と.ヾ∈≡∋ゞ
　　　　　　　　　|| 　γ ⌒ヽヽコ ノ　　||
　　　　　　　　　||　ΣΣ 　.|:::|∪〓 　||　　　♪
　　　　　　　 .／|＼人 ＿.ノノ _||_.　／|＼

やっぱここも >>153,>>154 になるのか・・・。
残念だ。

>>210
早漏

保守

つーか、なんだかんだいって開発するきないだろ？
いろいろいいわけしてさ？

完全なる遅漏だぞ。

形になるまで放置しとこ。








>>1を。

だから>>194で言ってる通り、こっちの開発をさっさとやりたいんだけど、こっちは
そう言ってられない状況なんす。それらが片付いたらスピード上げまつ。
ちなみに復帰は22日。それまでﾏﾀｰﾘとお待ちくださいまし。

簡単に途中経過を。長文スマソ。
[できたこと]
・プロジェクトで使う変数型等を決定
・UTF-8、64Bit変数使用する関係での調査をほぼ完了
[やっていること]
・hikocrtの内部実装(プラグイン作るにもこれ作らなければ話にならん)
・Glibのサブセット製作(同上)
[これからやること]
・プロジェクトページの再構築(バックアップ体制の構築、2ch型掲示板の設置等)
・hgikocrtを搭載したアーカイバ単体の試作
・hpd仕様の細かい設計(最初議論していたこととかを盛り込みます)

ﾘﾎﾟｼﾞﾄﾘ>ttp://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/hikoboshi-arcm/

…みんな心配なだけだよ（はぁと

　　　　　　　　　　　　　　　 ＿∧＿∧＿∧＿∧＿∧＿∧＿∧＿∧＿
　　　　　ﾃﾞｹﾃﾞｹ　　　　　　|　　　　　　　　　　　　　　　　　　　　　　　　　 |
　　　　　　　　ﾄﾞｺﾄﾞｺ　　 ＜　　　　　　　　　　　まだぁ〜！？　　　　　　 ＞
　　　☆　　　　　　ﾄﾞﾑﾄﾞﾑ　|＿　 ＿　 ＿　＿　＿　＿　＿　＿　＿　＿|
　　　　　　　 ☆　　　ﾀﾞﾀﾞﾀﾞﾀﾞ! ∨　 ∨　∨　∨　∨　∨　∨　∨　∨
　　ﾄﾞｼｬｰﾝ!　　ヽ　　　　　　　　　ｵﾗｵﾗｯ!!　　　 ♪
　　　　　　　　　＝≡＝　∧＿∧　　　　　☆
　　　　　　♪ 　　／　〃（･∀･ #）　　　　/　ｼｬﾝｼｬﾝ
　　　　♪　　　〆 　┌＼と＼と.ヾ∈≡∋ゞ
　　　　　　　　　|| 　γ ⌒ヽヽコ ノ　　||
　　　　　　　　　||　ΣΣ 　.|:::|∪〓 　||　　　♪
　　　　　　　 .／|＼人 ＿.ノノ _||_.　／|＼

くだらないことしかできてないんじゃん
いままでなにしてたのさ

まあ気長に待とうや。

保守

終了

□□□□□□□□□□□□□□□□□□□□□
□■■■■■■■■■□■■■■□■■■■□
□□□□□■□□□□□■□□■□■□□■□
□□■■■■■■■□□■■■■□■■■■□
□□■□□■□□■□□■□□□□□□□■□
□□■■■■■■■□□■□■■■■■□■□
□□■□□■□□■□□■□□■□■□□■□
□■■■■■■■■■□■□■■■■■□■□
□□■□□□□□■□□■□□■□■□□■□
□□■□□□□□■□□■□■□□■□□■□
□□□□□□□□□□□□□□□□□□□□□

つーか、UCS-2使うんじゃなかったんかい。
メンドクセーな。

まぁ待とうや。
22日らしいし。

でもあまり期待できない。
またなんだかんだいって引きのばしそうだし。

だね

期待保守age

副副(略)委員長のネタだったら面白いんだが。

ラジオなんて放送してる暇が有るならさっさと作っちゃいなさい

約束の２２日がちかづいてまいりました

さぁ営農ギコ氏今こそ漢を見せるときです。

残り9分

あと24時間待ってやる

ﾑｽｶ「時間だ！答えを聞こう！」

(´･ω･`)

営農ギコ「バルス！」

>>218
そうか？
これが固まってりゃかなり進んだと見れると俺は思うけど。
引継ぎも楽だしなー

━―━―━―━―━―━―━―━―━[JR山崎駅（＾＾）]━―━―━―━―━―━―━―━―━―

つか22日に作業再開って言ってるだけで、何を出すって話ではないだろ
なにをそんなにがっついてるんだ？

いや本人から報告してもらわんと（･∀･）ﾆﾔﾆﾔ

22日キター

>>215
進んでるかい？

22日もあと30分なわけだが

復活してるじゃん。ホーム見て来なって。

はい、ご無沙汰しますた。いままで保守ってくれた方に感謝でつ。
これから約1ヶ月間開発期間がとれるので、できるところまで突っ走ります。

まず5月中にWikiの内容の充実とhikocrtをなんとかすべく。

ちなみに。上旬にWikiの内容が�dだ事件ですが、どうやらsf.netの全域で
ﾊﾟｰﾐｯｼｮﾝ全開とか管理者が居ないファイルが削除されてようで。まったくもぅ。

>>223
SYNさんの意見により、UTF-8でつ。
んでも、UCS-2への変換関数とかも用意できると思います。

>>228
今日は失敗してたんだって。

sf.jpで再構築してくらさい。.net嫌い。

>>244
期待してます
頑張って下さい

DGCAｽﾚでもお呼びがかかったし(；´Д｀)

>>245
その手もあるんだけど、sf.netの方と使い分けるのメンドイ(Unaceの方で経験済)

sf.netってMLとか謎の文字化けするし…

なんでデメリットばかりのUTF−8を無理に使おうとするのか理解できん。
まーアンチUCS-2で使いたくないってのが本音だろうな。

ところでHPDの仕様決まったの？

　　 ／￣￣￣￣￣ ミ
　 /　　 ,――――-ミ
　/　　／　 ／　　 ＼ |
　|　 /　　　,（･）　（･） |
　 (6　　　　　　 つ　　|
　 |　　　　　　＿＿_　 |　　 ／￣￣￣￣￣￣￣￣￣
　 | 　　　　 /＿＿/ ／　 ＜　 時間かかるよ！
／|　　　　　　　　 ／＼　　 ＼＿＿＿＿＿＿＿＿＿

>>249
どのあたりがデメリット？
ASCII7bit文字がそのまま使えるメリットは凄く大きいよ。
世界を相手にするならUTF-8がいい。

日本語しかねーのに

UTF-8でいいんじゃない？

cabとか7zとかまで考えるならUTF-8は必須だろう
XPあたりからUTF16だからWCHARのメリット無いし

>>255
Unicodeは処理中はUCS-2(UTF-16)、保存時はUTF-8というのが基本では？

>>256
処理も保存もUTF-8がいいよ。
UTF-16にはUTF-8に対するアドバンテージは一切無い。
サロゲートペアが出てきた時点でUCS2のメリットは死んだ。

>>252
UTF-8じゃそのまま処理する事は出来ないから変換しなきゃならない。
ASCII7bit文字がそのまま使えるメリットなんて絶対7bit文字しか使わないってところでしか意味無い。
ほかの文字が少しでも使われる可能性があるなら結局その事を考えた仕様にしなければならない。
絶対7bit文字しか使わないってところなんて世界中捜してもあるか？
英語圏だって結構ASCII以外の文字使うこと多いぞ。

>>258
違う。
UTF-8のメリットは、7bit文字もそれ以外のunicode文字も表現できながら、
7bit文字がそのまま使えるということ。SJISが成功したのと同じなんだよ。これは。

>>259
だからそのまま使えたとこで意味が無いといってんの。
そりゃ、保存の時は都合が良いかもしれないがそんなの関係ない。

>>259
じゃあSJISでいいじゃん。

>>260
意味が無いと思っているだけだろ？
既に日本や欧州や米国でUTF-8を使っている奴がたくさんいるのは、
メリットがあることの証明だよ。
そいつらは何らかのメリットがあって使っているのは確実だし、
そういう奴らと仕事するにもUTF-8はメリットがある。

>>261
UTF-8採用している書庫形式もあるんだからSJISだと困るでしょ

>>261
SJISでは表現できる文字が少ないし、全言語の文字を同時表示することを考えると、
unicode系でないと話にならない。

実際にすべての文字を格納することを考えると、UCS4かUTF8しかない。

>>265
「将来拡張されても」が抜けていた。念のため。

結局、どういう話し合いだったのですか？

激安ソフト！！

ご提供するソフトは
　Illustrator10 : Photoshop7 :FLASH MX：Painter6.0j
で一本五千円でご提供します！！

新規インストール版のCDとシリアルナンバーのみお渡しします。
その他箱、説明書等の付属品はありません。登録はできません｡
細かいことは気にせず使えれば良いという方､安く手に入れたい
という方や学生さんにお勧めです｡

購入を希望される方は

[email protected]

までをメールください。
まっております。

>>262
だから保存の時と処理の時をいっしょにしないでよ。
で、内部処理でUTF-8を使ってる奴がたくさんいるってのはどこで調べたの？
そんなにたくさん人のソース見て回ったの?
俺も勉強の為に山ほど見てきたがUTF-8使って何か処理するたびにUCS2なりSJISに変換してる奴は見たこと無い。
逆にUCS2なりSJISで処理してUTF-8で書き出すってものなら見かけるが。

処理の時にASCII7bit文字しか使わないことが前提のソフトなんて只のバグ持ちだ。
だからそんなものは意味が無いといってるの。
UTF-8自体が意味のないものだとは言っていない。

あと将来拡張云々言ってるけどそんときゃ今のWiindowsもその他OSも大きな仕様変更されてるし
どの道その時にはプラグインも調整しなくちゃならないだろうよ。

じゃあ文字セットは UCS-4 でエンコードは UTF-8 でいいんじゃないの。

なーんか理想ばっかり追っかけて結局何もできなそうだな。
頭でっかちのプログラミングヲタにありがちな結末(w

>>271
理想を追わないなら統合アーカイバで十分じゃないか

>>271
理想を追い求めてスレを消費しているのは、その他の一般人だろ？

>>271
てかここでやり合ってるのは部外者同士だから

理想を追いかけるにはそれ相応の実力が必要。
>>247 にはそれがあるかは微妙なところ。

動かない実力者より、動く未熟者を応援したいな、俺は。

他人の足を引っ張る事しかできんヘタレがいるな。

鹿毛ながら応援しとります｛´・ω・｀｝ｶﾞﾝﾊﾞｯﾃ

>>269
SJISで処理しているのなんて、世界的に見れば無いに等しい。
分かっている人間のコードや、新規格にはUTF8ベースが多い。javaもUTF8だ。
マルチプラットフォームを考えるなら間違いなくUTF8にアドバンテージがある。
さらに、wchar系のエンコードには根本的な問題がある。
それは、文字列の任意の一部のバイト列を正しく解釈できないという問題。
データの破壊に弱く、ビュアは非常に作りにくいが、これがUTF8なら全く起こらない。

まぁ、ここでも読んどけ。
http://homepage1.nifty.com/nomenclator/unicode/ucs_utf.htm

特に、
>UTF-16では，UCS-4のU+110000以降の文字を表現することができません。
とかの問題もな。

UTF-8を使うからには、全てのDLL及び対応アプリはUCS-4のU+110000以降の文字に対応して、
そうじゃないDLLやアプリは（ベータ版とかの限定的な扱いだとしても）絶対に出ないってこと？

>>280
UTF-16 じゃない(XPのNTFSとかで扱えない)文字が扱えると、
それはそれで混乱のもとになる気がしなくも無いが。

>>279
Java が UTF-8 ってのは何処の事を差して言ってるんだ？

まぁ決定権は作る人間にあると思うので UTF-8 でやれば良いと思うけど。

そもそもWin専用じゃないんだからUTF-16を選ぶメリットはまったく無い

>>279
＞SJISで処理しているのなんて、世界的に見れば無いに等しい。
相変わらず分かってないなぁ、ここは日本だぞ？
だから例でSJISの名前出しただけであって世界中でSJIS使われてるだなんて事いってる訳じゃないんだが。
韓国行けば韓国の文字コード、中国なら中国、ロシアならロシア、それぞれの文字コード使ってるだろうよ。

＞分かっている人間のコードや
誰よ？具体例あげてソースの場所教えてくれ。

＞新規格にはUTF8ベースが多い
新規格の言語がどうだろうがこれはCだぞ。関係ない。
WindowsAPIがそのままUTF-8を扱えるのであればそれで良いだろうがそうじゃない。

＞それは、文字列の任意の一部のバイト列を正しく解釈できないという問題。
安心しろ、UCS-2のWiindowsも同じ問題を抱えている。
いくらプラグインのほうが対応してようがWindowｓの方でこけるだろうよ。
そもそも、UCS-4のU+110000以降の文字なんて今のWindowsで扱えないだろう。
将来、対応した時のため?その時そのプラグインも手を加えなくちゃ使えないだろうっての。
素直にUCS-2使っておいて、変更された時にプラグインのほうも調整すればいい。

>>285
メリットが無かろうが無理に扱いづらいUTF-8を使う必要も無い。

>>287
目標はクロスプラットフォーム(Win32,Linux,MacOS X,etc...) なんだってば

Linux,MacOS X,etc...がUTF-8に対応してるとは知らなかったよ。

結局UTF-8とUTF-16ってどっちの方がたくさんの文字表せるの？

>>290
UTF-8

けどども道使えないから一緒

ドモドウ？

>>292
確かに現時点ではFSの方が対応していなかったりするけど
だからといってUTF-16を選ぶ意味は無い
WinNT系で変換がいらないからといってそれが大きなアドバンテージにはなりえない

トモゾウ

>>291
つことはUTF-16はもう使えない？

>>294
だからといってUTF-16を選ぶ意味は無いというなら
同じくUTF-8を選ぶ意味も無い。

何を根拠に大きなアドバンテージにはなりえないといってるのか分からないが
少なくともアドバンテージが存在するということは認めるんですね。
だったらそんなものを使う必要も無い。

サルでも分かる説明。

対応アプリが"C:\ほげほげ.txt"を圧縮しようとする時
UNICODEを定義してプログラムを書いていている場合。

プラグインがUCS2の時
wchar lpszFileName[MAX_PATH];
::lstrcpy(lpszFileName, L"C:\ほげほげ.txt");
hc_add(lpszFileName, option); // 以降プラグイン内部でもlpszFileNameはそのまま使用することが可能。

UTF8の時
wchar lpszFileName[MAX_PATH];
::lstrcpy(lpszFileName, L"C:\ほげほげ.txt");
DWORD dwLen = ::WideCharToMultiByte(CP_UTF8, 0, lpszFileName, -1, NULL, 0, NULL, NULL);
char* lpszU8FileName = malloc(dwLen + 1);
::WideCharToMultiByte(CP_UTF8, 0, lpszFileName, -1,lpszU8FileName, dwLen + 1, NULL, NULL);
hc_add(lpszU8FileName, option);　// プラグイン内部でAPIを使う際はwcharに戻す必要がある。
frre(lpszU8FileName);

仮に文字コード変換のマクロを定義しても見た目が多少良くなるだけでやってることに変わりは無い。
さてどちらがスマートか。どちらがバグを生む可能性が低いだろうか。
これはプラグイン作者が書くコードではなく利用者が書くコードだということを忘れずに。

あ、どうでも良い事だが\\としなくちゃならんかったな

WinNT系専用ならそれでもいいんだがね

>>300
だからさ、これはプラグインのコードじゃないって言ってるでしょうが。

>>301
インターフェースの問題なら利用者がラッパでも書けば良いだろ

>>302
インターフェイスとかそんな問題じゃない。
どれだけ利用しやすいかだ。
で、インターフェイスの問題というのが何かわからないが利用者にラッパまで書かせるきですか。
とことん使いにくくなっていくな。

>>289
http://www.apple.co.jp/macosx/technologies/darwin.html
http://www.zdnet.co.jp/help/tips/linux/l0672.html
http://www.olug.gr.jp/~hhide/OIA/19980704/beos.html
http://jp.sun.com/products/software/solaris/fcc/ucc-details1000.html
http://www-online.kek.jp/~keibun/javaprog/unicode.html

>>298
プラグインがUTF-8のとき
　int main( int argc, char* argv[] ) {
　　hc_add( "MyArchive", argv[1] );
　}
UCS2のとき
　int main( int argc, char* argv[] ) {
　　size_t len1 = strlen(argv[2])+1, len2 = len1*2;
　　char* buf = (char*)malloc( len2 ), name=buf;
　　iconv( iconv_open("UCS2", "UTF-8"), &argv[1], &len1, &buf, &len2 );
　　hc_add( "M\0y\0A\0r\0c\0h\0i\0v\0e\0\0", name );
　　free( name );
}

>>304
UTF-8の方の引数にASCII以外の文字列が来た時が考慮されてない｡
0点｡

あと、VC++限定なら_wmainもあるのだが｡

>>305
だから、今時のOS（除くWindows）なら、ファイル名中の
ASCII外の文字は元々UTF-8なんだ（or そうできるんだ、）
と言う意味で上に５個くらいリンクを並べておいたんだが。足りないか？

あるいは、UTF-8にしとけばASCII-Only圏の人達は
ASCIIのつもりでプログラム組みゃ済むから普及しやすいだろう。
　・実装レベル１： ASCIIのみ
　・実装レベル２： UTF-8のみ
　・実装レベル３： ShiftJIS、EUC-JP、UTF-16などのレガシー文字コードもサポート
とか規格でアプリの実装レベルを明確に定めとけば混乱も減るだろうし。

> あと、VC++限定なら_wmainもあるのだが｡

　うむ。対象をWindowsに限定するならUTF-8に対してUCS2に
　利点があるというのには激しく同意だ。が、UCS4ならまだしも、
　UCS2を楽に扱える環境なんてWindowsだけだと思うんだが。
　大抵 sizeof(wchar_t)==4 だし。

>>304
上
Windowsもそうやって対応していれば問題ないんだがな。
Windows「も」対応しているUCS2を使った方がいい事に変わりは無い。

下
引数で必ずUTF-8が来るならそれでいいんだがな・・・。

>>306
＞ASCII-Only圏の人達
そんなところは無い。

Win32 APIでUTF-8に変換する関数ってある？

>>309
MultiByteToWideChar, WideCharToMultiByte のフラグで。Win95だとUTF-8は扱えないが。

>>307
> Windows「も」対応しているUCS2
　Windows「以外で」UCS2に対応している環境を教えてくれ。
　もちろん glibc はUCS4だから、一旦wchar_tに変換して上２バイト
　削ればOKだが、それを言ったらWindowsもUTF8対応してることになっちまう。

> 引数で必ずUTF-8が来るならそれでいいんだがな・・・。
　それ、どの文字コードでも同じ。
　RedhatLinux8.0以降をデフォルトインストールすれば必ずUTF-8が来る。
　つーかLinuxカーネルの内部はUTF8なので全体的にだんだんUTF-8への
　移行が進んでくだろう。MacOSX、BeOS辺りは絶対必ずUTF-8。

--
まとめると、俺の知る限りWindows以外の全ての環境ではUTF-8が
ネイティブコードか、でなくても"UCS2の方が楽に使える"ことは無い。
# いや、もしかしたら超漢字だとUCS2のが楽か。よく知らんが。

それをふまえた上で「他の全てよりWindowsの方が普及してるから優先」
というのならそれは妥当な判断だと思うから、どうぞ主張してくれ。
ただ、>>289 を見る限りとてもそうとは見えないのでなぁ。

>>308
使ってる文字コード系は Windows-1252 でも MacRoman でもいいけどさ、
じゃあ、「ファイル名にUS-ASCII外の字を使う習慣のない圏」 と解釈してくれ。

オナニープロジェクトだな、こりゃ。
断言する。ぜったいにこのプロジェクトは失敗する(w

んゎ(ﾟ∀ﾟ；)なんか文字コード議論が凄くなってるし。。。
じっくり読ませていただいてますが、まだ読み終わってないので
流れに逆らうレスご了承くださいませ。

>>294
最近はFSによっては対応してるっぽい。

>>298-303
その辺のルーチンは利用者側でなく、hikomgr の方で行おうかと思ってます。
利用者側でこんな処理してれば使いにくい一方ですから。
A系W系みたいに関数を分けるとか。

あと、現在の文字コード周りの実装状況(hikocrt)ですが、
・WinNT -- MultiByteToWideChar(実際、こいつの挙動が心配)
・それ以外 -- iconvでUTF-8→システムのコードページ
hpdは全面UTF-8、hikomgrはいくつかの文字コード向けのインターフェイスを用意します。

>>313
HCLをVC6でもビルドできるようにしてほしい。

>>310
＞Windows「以外で」UCS2に対応している環境を教えてくれ。
知らないよ、だがUCS2に対応できないOSばかりなのか?
UTF-8に対応してる（できる）ならUCS2に対応できないことは無いと思うが。

＞それ、どの文字コードでも同じ。
windowsは文字コードを使うかはプログラマが指定するもの。
引数にどの文字コードでくるかは必ず決まってる。だから同じで無い。
linuxの場合、環境でも違ってくるのでしょ。linuxにも色々有る。
RedhatLinux8.0以前なら?デフォルトインストール以外なら？
結局UTF8ならwindows以外の全ての環境で対応が楽なんて事は無いだろう。

>>311
そんな圏も無いだろう。
習慣のない人なら幾らでもいるだろうが。
そもそも使いもしないUNICODEファイル名の事で云々言ってるのになんだかなぁ。

>>313
まぁ、なんにしても応援はしてるから頑張ってくだされ。

>>298
それは単にハードコーディングしたファイル名をコンパイラが対応してないエンコードで
渡そうとしてるからUTF-8の方が複雑に見えるだけじゃねーの？

入力がASCII文字列だったら逆にUTF-8の方が変換が不要な分簡単になるじゃん。

今更U+10000以降すら表せないUCS-2にするのもなあ
>>283
クラスファイル内での文字列の持ち方や.jarのファイル名のエンコード

>>318
Java の char は符号無し2バイト整数でモロに UTF-16 なわけで。
String を初めとする char を扱う部分も UTF-16 でしょ。

そーゆー意味では >>318 の示した UTF-8 の部分って UCS-4 をサポートするためでなくて、
単に ASCII の出現確立が多いと想定して節約のために使ってるとか、
ASCII オンリーで済む連中が自分たちの既存の資源がそのまま扱えるからとかそーゆー理由だよね。

UCS-4 の サロゲートペアでも使えない部分とかってそんなに需要あるのか？

>>317
>入力がASCII文字列だったら逆にUTF-8の方が変換が不要な分簡単になるじゃん。
入力がASCII文字列だけならSJISでも良いじゃん。
ウニコードにしかない文字も出てこないんだから。

SJISは\でハマルのでこの世から無くなって欲しい。

>321
たしかに \ と同じ文字コードが入ってる文字のせいでパスの切り分けとかに失敗するバグはよく聞くな。
PGのミスと言えばミスだけど、UTF-8でそういう類のものが少なくなるならいいなあ

>>322
特に問題なのが、海外ソフトを日本で使う場合なんだよね。
日本ではA系のAPIがSJISになるからどうしようもないんだけど。
A系のAPIがUTF-8だったら、何も問題なかったのに。
UTF-8用にU系APIを用意してほしい＞MS

wchar_t使うとWindowsの場合UCS-2になり
その他の場合UCS-4 になるだけでなんか問題ある?
文字コード変換でUTF8<->UCS-2って固定しないで
UTF8(char型)<->UCS-2,UCS-4 (wchar_t型に合う方）っての用意すれば問題ないような気もする。

スレ主はこれ全部読まなきゃならんのか。
ま、がんがれ。色々と……。

>>323
そもそも MS が '\' なんぞ使わずに素直に '/' にしとけば問題はおきなかった、
とか言ってみるテスト。

UTF-8 っつか、Unicode の変換テーブルの問題だけど、
0x5C を U+00A5 == '￥'の半角に割り当てるのか
U+005C == '＼'の半角に割り当てるのかで違いがあったり、他にもイロイロ。
日本語Windows は 0x5C を U+005C に変換するくせに '￥' の半角で表示したりする。
まぁ、円記号問題はみんな諦める方向で合意してるっぽいけど
Unicode は Unicode で別の問題があるってことで。

これは作ったプログラマの問題だけど
http://www.eternal.nest.or.jp/~shiro/macosx/life0201.html
の 12/25 日あたりとか。

UTF-8で決定してるんでしょ？
概要のページにはUTF-8と書いてあるし。

>>325
スレ主の思惑とはとっぱずれたところで玄人筋がやりあってるだけだと思われ
読むか読まないか、参考にするかしないかはまた別の話かと

まあ保守保守と続くよりはいいんでないの？

これだけ熱く語れるならみんな開発に参加しる！

と>>1がおっしゃっています。

>>313
いくら議論が盛り上がっても進んでないと全く意味がない。
で、進んでるかい？

期待していいのだろうか　鬱

期待したいけど・・・
進んでるように見えて実は全然進んでない。だから期待できない。
まぁここの開発者実力ないし・・・。仕方ないか・・・。
http://www.valley.ne.jp/~hirosoft/

そこそこあるんじゃないの？
しかし鬱

>>1よ今の開発状況ゆってくれ。
そろそろみんな萎えてきてるみたいだし。

とりあえず何か成果をみせてくらはい。

まだ構想段階っぽいし成果もくそもないと思うが。
まぁ、開発状況が見たけりゃプロジェクトページに行って見ればよかろ。

　　　 　∧＿∧
ﾋﾟｭ.ｰ　(　　＾＾ ） ＜これからも僕を応援して下さいね（＾＾）。
　　＝〔~∪￣￣〕
　　＝ ◎――◎ 　　　　　　　　　　　　　　　　　　　　　山崎渉

保守ってみたい今日この頃

　 ＿＿＿＿＿＿＿　　　　　　　　　＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿
　|悲しいときー！　|　　　　　　　 　|ﾚｽ来てると思って開いたら保守だったときー!!|
　 ￣￣￣∨￣￣￣　　　　　　　　　￣￣￣￣∨￣￣￣￣￣￣￣￣￣￣￣￣￣￣
　　　　　∧∧　　　　　　　　　　　　　　　　　　∧＿∧
　　　　（　ﾟДﾟ）　　　　　　　　　　　　　　　　　（ ´д｀ ）
　　　⊂○　○ヽ　　　　　　 　 　 　 　 　 　||””””””””””|
　　　　　|　　|￣　　　　　　　　　　　　　　（　）　 保守　 （ ）
　　　　 / /＼＼　　　　　　　　　　　　　 　 ||＿＿＿＿＿|
　　 　 / /　　> /　　　　　　　　　　　　　　　　/ /　 )　)
　　　（＿）　 ��＞　　　　　　　　　　　　　　 （＿） （＿）

hosyu

http://homepage.mac.com/hiroyuki43/jaz01.html

＿|￣|○＜期待した俺が馬鹿だった・・・

そんな簡単に出来るもんじゃねーよｺﾞﾙｧ



>>1の心を代弁してみますた。

>>344
> そんな簡単に出来るもんじゃねーよｺﾞﾙｧ
> >>1の心を代弁してみますた。












おまえ>>1だろｗ

糞スレになりつつある今日この頃

ほんの少しでも状況報告すればいいものを
「忙しい」で終わらせているのが原因。
管理できないぐらいならスレたてなければいいのにたててしまったのがそもそもの間違い。

たまにホーム覗いてみてるけどはっきり言ってまだここでなんか報告出来るようなレベルにまでは全然達してないっぽいが。
このスレはある程度出来上がるまでモチベーションを保つために立てんではなかろうかね。

今日初めてC++インストールしたのですが開発に参加してもいいですか？
HelloWorldも動かしてない不束者の初心者ですが。。。

>>349
ダメと言われる事を期待しているようにしか見えないけど、
釣りが趣味の方ですか？

>>349
自惚れすぎ

いや、本当に参加してもいいかなぁと思ったんだけど、
さっき新規作成でhelloworld初体験しました。
150ｋもファイルサイズがあったので早くも自信喪失気味です。

>>352
人の足を引っ張るレベルから卒業できたら考えてもいい。

頼られるほどの状態なら参加しない方がいいですなｗ

空いたマシンに無駄にFreeBSD入れてみたけどそれでよければテスト手伝ってあげるぞなもし。
UNIXとかよぉ知らんのでコンパイルが通るかどうかぐらいしか役に立たないけど。

誰の言葉だったか忘れたが、
10人のプロジェクトチームがあったとする。
それは7人の優秀なプログラマと3人の普通のプログラマで構成されている。
このチームで最も効率を上げてバグの少ない良いものを作る為に最初に行う事は
普通のプログラマ3人をプロジェクトチ−ムから外す事である。

商業プロジェクトじゃないんだから
オープンソースなソフトのフォーラムとか覗けば分かるだろうけど

プログラマ
的確なアドバイスできる人
動作検証・バグ報告等

みたいなのでヒエラルキー？できてるわけじゃん
で上の方のプログラマだけいても
裾野の方からのフィードバックがなきゃ
大概そのプロジェクトは成功しにくいわけ

helloworld君がプログラマとして参加するかどうかよりも
今はまず協力体制を作るのは悪くないはず

>>352
恐らく>>1は誰でもいいから手伝ってくれ。と思っているはず。
だから手伝ってあげたらいいかも。

>>358
何にもできないのに手伝いに入るのか否か

>>356
優秀な7人を1人に減らした方が早く回るケースもある。

>>358
猫の手も借りたい、とかいってたら本当に猫が来ちゃったって感じなのかも。

まぁ、C++は初心者だと言っただけなんですけどね・・・。

>>362
つーことは、他の言語ではｽﾊﾟﾊｯｶ気味なのか！！
ぜひとも参加してくださいませ。
自分は応援することしか出来ないですけど・・・
C++は初心者ってことはCですか？

これでVBとか言い出したら…いや、悪くはないよ、漏れもVB派だし。
でもでしゃばったりはしない。

ここでがたがたいってるやつは役に立たない。

http://homepage.mac.com/yuuka20/

>プログラマ
→ 技量が伴わない

>的確なアドバイスできる人
→ 初心者は大抵的外れな発言をする

>動作検証・バグ報告等
→ 「コンパイル出来ません」（実は間違ったやり方をしてただけというオチ）

>>1 は知識はあるが実力がないパターンかもしれない。
だから仕様などの提案はプロジェクトページで進んでいるがソースがほとんど変化がない。

ここでがたがたいってるやつは役に立たない。

やめるなら今のうち。
できないならできないとはっきり言え。

http://hikoboshi-arcm.sourceforge.net/index.php?%5B%5BHCL_func_date%5D%5D
>現時点では細かいことは気にしない。(Win32 APIでの細かい差異など)
いや。気にしろよ。
わからないだけじゃないのか？

ここでがたがた言ってないで教えてきてやれば？

何だ？ここでそんなにがたがた言われるのが不満か？
だ　っ　た　ら　最　初　か　ら　ス　レ　た　て　ん　じ　ゃ　ね　え

(´-`).｡ｏＯ（なにやら朝っぱらからおっさんがヒートアップしてるもよう）

この板はソフトを使う人がほとんどだから、開発系のスレは板違いなんじゃないかと。

unix 7-zipでググると上の方に来るのね。
UNIX界隈の人も見てんのか？

>>1
調子はどうですかい？

保守

……パトラッシュ……糞スレだよ……もう終わりだね……
　 　 　 　　　　　　　　　　 .　-‐- .,. '　￣　 `　.　 ＿,.-―-　、__,,....ィ
　　　　　　　　　　　　 ,　´　　　　　　　　　　　　ヽ 　 i　　　　ヽ　　 '-､
　　 　　 　 　 　 　 ／　　　　　 　 　 　 　 　 　 　 ＼ l　　 ,　　ﾄ ､　~ヽ.＿＿＿,,,...,.
　　　　　　　　　　/ 　　　　　　　　　　　　　　　　 　 ` ､‐ ' 'ｚ__ l　,>-‐''　 　　　,／
　　　　　　　　 　i 　 　　　　　　　　 　 人　l、　　　　 ヾ　　　　｀´　　　 　　／/
　　　　 　　 　　/　　　　　　　 　,ｨ　／ 　ヽi ヽ.　l､　 　,|　　　　　　　　 ／ 　 /
　　　　　 　 　 "i　 　 　/^ヽ! ／ !,/　-―-　　|,/ | 　 ﾊj　　　　　　　　 そ　人
　　　　　　　　　ｉ 　　　l　ﾊ i/ 　　 　　━ 　　 ヽ. l/ /　　　　　　　　　　　ﾞヾ.　ヽ、
　　　　　　　　　ﾞｌ.　　　ヽ_　 　　　 　 　 　 　｛ ､_ｿﾉ　　　,..　-　 ..、　　 　　 ';　!~
　　　　　　　　 ／ヽ!　,ｨ/ 　 　 　　　　　　 `-　 ;'　　　　;'　　　　　　` :,　　　 ヽ!
　　　　　　　／　 ＿Y 　 　 ヽ　 　　　 ｔ　、　　/_　　　 　':,　　━ 　 　 ;　　　 　 ヽ,
　　　　　　〃´￣　亠─----;:＞- ､. 　｀´　／,,. ';　 ,,　_　 ` ､ _ ,,, ..　'　　 　 　 　 ;"
　　　　　i'´　　　　　　　　 ￣ 　__ ,,.. -`＜´ ;: '",:' ,:' 　 　 ｀　 -　 、　　,,..　--‐ ／
　　　　 /l　　　　　　　　　,. - ´　/ 　　　　ヽ`´,. ' 　　　　　　　　　 ｀ ~ 　　　／l
　　　　i　 !　　 　 　 　 ／　　 　/ 　　　　　　`'`i 　 ,.-‐ ､　　　,　,　 　 ,. -‐'　　|
. 　 　 ｌ　　i　　　　　／　　　　　l 　　　　　　　　 !　 ` -: '　　　　'　　 ｨ　　 　 　 i
　　　 l　 　 !　　 ／　　　　　　　l 　　　　　　　　 ＼　　　,...､__,,.-'' ／;'　 　 　 　 l
　　　 |　　　ヽ／　　　　　　　　　! 　　　　　　　　　 `-:イヽ-'　 ／　/　　　　 　 ;ﾘ
　　　｜　　　　　　　　　　 　　 　 ｉ　 　　　　　　　　　　　` ~ ´　　/　 　　 　　 ;'
　　　 i　　　　　　　 　　 　 　 　 　 !　　　　 　 　 　 　 　 　 　 　 /　　　　　　 /

　　　　　　　　　＝≡＝　∧＿∧
　　　　　　　 　　／　　　（・∀・　） ﾄﾞｷﾄﾞｷ
　　　　　　　　〆 　 ┌　 ∪ ∪ | .∈≡∋
　　　　　　　　　|| 　γ ⌒ヽヽコノ　　 ||
　　　　　　　　　||　.｜　　　|:::|∪〓　 .||
　　　　　　　 .／|＼人 ＿.ノノ _||_.　／|＼

糞スレ決定！！

ホーム見てこいって

プロジェクトページではりきってこのスレは放置ってか>>1よ。

単独スレ立てるの早過ぎだよな

この話題を隔離するためにスレ分化したんじゃなかったっけか？

HP作ったわけだし。このスレいらないな

このスレ腐ってるよ。

>>1よなんとかしてくれ

マジレスな意見なんだが、完全新規のDGCAか、機能限定LHA/ZIPなら対応できそうだけど、あとは使いものになりそうもないと思う。
あ、俺一応アーカイバ作者ね。

将来的に出てくるであろう仕様が皆無だし、仕様拡張も無理っぽい。
せめて引数は構造体にして、仕様バージョンか構造体サイズを渡すとかすべきだろ。

あと、現時点の関数インターフェースも穴だらけに見える。
例えば、複数のファイルを１つのデータとみなす方式(cab/tar/gca/rar)の書庫への追加/削除で、ファイル名を１つしか指定できないと、そのたびに全展開/全再圧縮を繰り返すので、遅くて重くて使い物にならなくなるはず。

ついでに、メモリへの展開ができないと、Susieプラグインのような画像アーカイバとしても訴求力がない。

SYNさんの場合は独自形式で、自分で好きなようにDLLを作ればいいだけの話だけど、コア部分が非公開の形式への対応は、DLL作者に求める事は酷じゃないかなと思うような仕様だね。
統合アーカイバでもBGA/JACKだけだし、原作者とDLL作者が一致する事の方が少ないし。
たびたびSYNさんを引き合いに出して悪いとは思うけど、GCAのSDKが圧縮機能を封印したまま放置されているから、UNGCA32.DLLにはいつまで経っても圧縮機能が載らないわけでしょ。

また、圧縮方式を研究開発する人に対しても同様だね。
何でわざわざDLLにしなきゃいけないのか、商業的な理由でもない限りメリットがあるように思えないし、商業的な理由なら簡単にオープンプロジェクトに荷担するとは思えない。

というわけで、現時点では頭でっかちの学生の先走りにしか見えないという状況だな。

で、何の作者ですか？

以下予想↓

Noah

>>390
DLLイラネと言い、商業的商業的言ってるからDLL不要でシェアウェアのアーカイバだろう。
ZELDAが本命だな。

>>391
いや、そんなに若くないが。（ｗ
ここで晒しても俺にメリットないし。

せっかく降臨したんだしヒントくださいよ〜。
>>393さんのソフトはVectorで上位いってるの？

あいつじゃない？現在職業プログラマで
SFC出身で見るからにキモヲタで散々叩かれた…

こんどは自信あるよ、Ｍｉｃｃｏ氏だね。ﾌﾌﾌ…。

>せっかく降臨したんだしヒントくださいよ〜。

じゃ、ちょっとだけ。
392,395,396が言ってるのは違う（ｗ

>393さんのソフトはVectorで上位いってるの？

うん。
でも、アーカイバ以外の方が有名だけどね。

いや、興味ないから帰って良いよ。

助言があるならしてやれ。ないなら帰んな。

>>389
確かに見る限り将来性を考えてUTF-8等を使ってるようだがその他の関数をみてみると
とても将来性を考えてるようには見えない。
タイムスタンプなど・・・

>>194
あんたの実力でとてもできるとは思えない。

となるとSusieの人くさいですな。

>389
>例えば、複数のファイルを１つのデータとみなす方式(cab/tar/gca/rar)

ソリッド圧縮のことを言ってるなら tar は違うのではないかと…。

2chがらみはいつもLhaplus

>>401
tar+gzipとかなら事実上のソリッド圧縮だが｡

>401

rarだってソリッドだけじゃないし

つまりrarのソリッド形式は無視して捨てろと。

欠陥だらけなHPD仕様。
なんか使いもんにならない予感がする今日この頃。

＿|￣|○＜期待してた漏れがばかだった…

>>1-1000
>>369

>>408
>>373

>409
>385

アーカイバ作者の意見募集中。。。

VBからでも使いやすいものにしてね　by VB屋@海馬作成経験あり

美味しいリゾット食いたい。

HPD仕様を見る限り、統合アーカイバの方が断然良い。
つまりHPDは洋梨。

なら思う存分統合アーカイバを使うが良かろ。誰も止めんし。

＿|￣|○＜期待してた漏れがばかだった…

そろそろ統合アーカイバでソフトを作るとするか・・・・

>>416
初晒しは２ちゃんでよろ

自己処理の解凍ツールだとたまにうまく解凍してくれないのがあるのですが。
ところで、UnZip32.DLLでワールドカードに[]が使えるわけですが、これのせいで
ファイル名に[]があるとうまく動きません。
とりあえずファイル名の [ と ] を ? に置き換えてDLLに送ってます。他に回避する方法ありますか？

>>418
普通だったら \[ \] とかすればエスケープできるような気がするけど。

>>418
Noahでは"["、"]"、"-"を"[]"で囲ってた｡（"[[]"とか）

>>419-420
なるほど、おかげできっちり処理することができそうです。
ありがとうございました。
というか、\は説明書に書いてありましたね(汗。

あと4時間

hikocrt-0.0.0なるものをリリースしますたが、まだまだこれからの漏れでつ。
かなりご無沙汰してしまい申し訳ありません。
保守ってくれた方に感謝。

そろそろプラグインの方の仕様を固めますので、ご意見よろしくです。
http://hikoboshi-arcm.sourceforge.net/index.php?%5B%5BHPD%5D%5D(プラグイン仕様)
http://hikoboshi-arcm.sourceforge.net/index.php?%5B%5BHMGR%5D%5D(プラグイン管理ライブラリ)

やったこと
-ライブラリの基礎部分
-プラグイン仕様書き（半ば）

これからやること
-プラグイン関係の仕様固め→コーディング
-デバッグ等

なお、ここまでのレスは順次読んでレスやら反映やらします。

乙。

まだ見てないけど。

訂正。
ここのレスはまともに読みませんので、もしご要望ある方はプロジェクトページの
掲示板へどうぞ。


＃特にユーザーさん、騒がないでお待ちいただければ嬉しいです。
　確かに当方はｺｰﾃﾞｨﾝｸﾞ力も気力もそんなにありませんが、それでも期待を
　裏切ってはならない、煽られても作り上げたい。。と思っています。

　それでもお前は・・・という方、メッセ辺りで小一時間語りますがな。

…だったらここは破棄してム板にでもひっそりスレ立てれば？

>>426
ここが埋まったら。

さよけ。

>>425
んじゃこのスレいらねーじゃん。
じゃ聞くけどこのスレたてた目的は？ってこのスレ見ないんだっけ？

糞スレまっしぐらだな。

>>427
ム板にたてたところで何も変わらない。

間の悪いやっちゃね。

正直、統合アーカイバの仕様をきっちり纏めて
ちゃんとした仕様書作ってくれたほうがありがたい。

そういう次元じゃないと思うが。
とりあえず1氏がんがれ。

漏れも応援してマフ。
漏れはあなたのヒラメ筋です。

>>430
>＃特にユーザーさん、騒がないでお待ちいただければ嬉しいです。
だからだろ。
まあどうせ見ないならどこにも立てないでSFの掲示板に
ずっと引きこもってろって感じだが。

>>427
埋まるまでとか言ってないでとっとと捨てろやこんなスレ
それにあんたが黙ってれば素人とか自称アーカイバ作者がが勝手に騒いで埋める(w

まあ、意見聞こうとでも思ったのかしらんがまともな書き込みなんて出てこないと思うよ

ム板でまともな意見ほしかったらさっさとここ捨ててム板にたてなしゃい。

>>436
貴兄が書き込んでいたら、いつまで経っても落ちませんよ？

>436

>埋まるまでとか言ってないでとっとと捨てろやこんなスレ
>それにあんたが黙ってれば素人とか自称アーカイバ作者がが勝手に騒いで埋める(w

？

I6 COMPとcabinetは拡張子被ってるけど、
前者の統合アーカイバは存在する？

>>440
スレと関係ないような。でも答えるテスト。
純粋な統合DLLは存在しませんが、解凍だけならXacRett.dllで可能。
因みに、CabとIs5とIs6を判別しますので、ほぼ確実に解凍できるかと。

b2e作ろうと思ったが、非対応じゃないっすか？
本家のinaba氏が作った実行形式は対応してるけど。。。


対応形式.txt
Cab(IS)| × | ×

　・InstallShield-Cab (-- 5.0x)

　　　data1.cab とか _sys1.cab みたいな奴です。
　　　展開する時は同じ場所に *.hdr ファイルが必要なので注意。
　　　5.5 や 6.0 の書庫はＯＫです。古いのが駄目ってこと。

うーむ、やっぱ使えるのか！！

Wise-Unwiser使え。色々必要なEXEがあるけど。

あ、でも本家cabが解凍できないか…

>>1
CAB用はIS-Cabinetも対応してほすぃ

>>440
cab.b2e
----
load:
(name XacRett.dll)

check:
decode:
(cmd x (arc))
----
これじゃ解凍できなかったしょぼーん。。もうちょっと努力必要かな。。。

>>447
iniをいじってデフォルトのCab用ルーチンを殺さないとダメでつ。
（「Kill=C」をNoah.iniに書き込む）

うーむ、、、何が悪いのかサパーリでございます。
NoahのCab32.dll操作を切断したけど、だめっぽい。。。
やっぱり>>442なのかな？？Inaba氏の実行ファイル形式の方使おうかなぁ。。。

XacRett.b2e
----
load:
(name XacRett.dll)

check:

decode:
(cmd x (arc))

decode1:
(cmd x (arc) (list))
----
うちではこうだな

やばい、たまたま使ってたアーカイブにhdrファイルが無かったしょぼーん。。。
無事解凍できますた。ありがとうございますた。スレ違いすまんでした。

ところで、、、
シームレスに解凍できるアーカイバプラグインとかってこのスレで出来上がるんですかね？

ｷﾀｲｱｹﾞ!

あぁどんどんスレが腐ってゆく・・・

まあ気長に待ちましょうや

そやね。
待ってたらいつかできるだろう

>>425
＞ここのレスはまともに読みませんので
＞ここのレスはまともに読みませんので
＞ここのレスはまともに読みませんので
＞ここのレスはまともに読みませんので
＞ここのレスはまともに読みませんので
＞ここのレスはまともに読みませんので
＞ここのレスはまともに読みませんので
＞ここのレスはまともに読みませんので
＞ここのレスはまともに読みませんので
＞ここのレスはまともに読みませんので
＞ここのレスはまともに読みませんので
＞ここのレスはまともに読みませんので
＞ここのレスはまともに読みませんので
＞ここのレスはまともに読みませんので
＞ここのレスはまともに読みませんので

>456
なにがしたいん？

もうこのスレは捨てられたって事だろ。

ばかばっかだもん

このスレはもう死んでいる

>>456=>>1

>>461
結局糞スレになっちゃいましたとさ。

だね

結局いらねーじゃん。このスレもソフトも。

ここが踏み台になったからいいじゃん。

このスレは腐ってるが
ソフト開発は進んでる。

そもそもこのスレは>>1が放置した時点でもう終わり。

でも完成が近づいてテスト段階に入ったら戻ってくるんじゃない。

> でも完成が近づいてテスト段階に入ったら戻ってくるんじゃない。
じゃ、もう戻って来ないかもね。

このスレ埋め立てようぜ。後は放置。

ということで、スナップショット(hikocrt-0.0.1)を出しました。
これだけじゃ使えませんが、近日hikocrtを使用し試験移植してみたアーカイバを出します。
それが出ましたら、テストお願いします。

プラグインマネージャ辺りの実装も(まだWikiには書いていませんが)固まっていますので、
今後１ヶ月で組み立てようかと考えています。来月の今ごろにはそれなりの成果を出すつもりなので・・・


なお、このスレ放置してしまい申し訳ありません。
しかし、こちらに書き込みはなくとも開発は進んでいますので。
もうしばらく時間がかかりますが、よろしくお願いします。

＃どうもこのスレでの失言が多いなぁ・・・＜漏れ

ふむふむ

まぁ、ゆるゆると期待しているのでゆるゆると頑張ってくれろ

>>469
期待してまつ。
漏れはここしかみてない(失言？w)ので
今回のように経過報告だけでもきて頂けたらうれしいです。

みんなで応援しようぜ！(*＾−’)ｂ
http://hikoboshi-arcm.sourceforge.net/

ｷﾀｲｱｹﾞ

ﾌｷﾀｲｻｹﾞ

保守sage

now on hikoboshi-arcm month
ほんとーに加速するのか

　__∧＿∧_
　|（　　＾＾ ）|　＜寝るぽ（＾＾）
　|＼⌒⌒⌒＼
　＼ |⌒⌒⌒~|　　　　　　　　　山崎渉
　　 ~￣￣￣￣

>>477
加速するわけないじゃん

↓これ行く人いる?
http://hikoboshi-arcm.sourceforge.net/20030720.html

漏れは行くが。

>>480
ﾏﾝｾｰ橋…？

…だから？って話ですが(^^;)。

>>480
漏れも行きたいが東京って遠すぎる。。。

>>481
分かりやすいから。

改蔵の秋葉マップの88箇所目だな。＜万世橋警察署

デジキャラットって…こいつもか。ｹﾞﾝﾅﾘ

>>482
漏れは横浜だから, あまり遠くない。

>>483
アキバに近いし。

>>484
へぇ。

>>485
肩を落とすなぁ

秋葉原(JR)か神田(銀座線), どっちの駅から行くか迷ってる。

コテハンでそういうことしてるとうざがられるぞ。俺とかに。

>>487
俺漏れも

>>1
487は多分
http://www.mapfan.com/map.cgi?SPOTICON=&Func=INDEX&MapSize=&CENTERICON=&MAP=E139.46.26.1N35.41.38.5&ZM=12&NC=&CN=&GMain=&IStat=0&LStat=0&MapF.x=200&MapF.y=128
↑の辺にカメラ持って潜んでいるから気をつけたほうがいいよ。

488はここだな。
http://www.mapfan.com/map.cgi?ZM=10&SbmtPB=MAP&MAP=E136.08.55.4N35.20.18.9&Func=INDEX&&


てか窓の杜だと普通に顔出ししてる作者多いから、
1も載るかな？

>>477-478
Multiｳｾﾞｰ

http://fantstage.hp.infoseek.co.jp/drpepper.swf

漏れはマルチじゃないよー
向こうのスレ真似しただけ

>>493
そうか。

ｷﾞｺさんどこ?

いまから万世橋渡ります　それが私です

傘age

厨房Liveｽﾏｿ

まだいる？

ｽﾏｿ　今武蔵小杉　時間なかったんで

赤と黒のカバンしょってました?

多分1に騙されたんじゃないかと。

すいません。ちょっと誰にも会えなかった上、携帯でここを
見ることができなかったもので・・・。１０：３０以後、別の
用事があったこともありますが。

本当にすいません。
３：１５頃もういっかい居ますので、滞在している方どうぞ。
場所は同じで、姿は>>501で正解です。気軽に声かけてください

一人しかきてなかったら寂しいな

>>503
ｽﾏｿ行けなかった

>>499
>>1ぢゃないのね。やられた。

>>503
携帯いぢってたから, ここ見てるかとｵﾓﾀ

カキコできる環境に戻ってきました。
探して頂いてた方、ご迷惑おかけしてすいませんでした。
今度やるとしたら、その辺のことをもうすこし考えようと思います

（ただ、オフではないので。その辺だけ補足）


それでは開発を続けます。お騒がせしました。

今度やる時はもうちょっと前に告知してくらはい。そう簡単に予定明かないっす。

>>507=Gozilla News Network

>>507
"Hikobshi"書いた旗でも立ててくらはい。
ﾃﾞｼﾞｷｬﾗｯﾄよう分からへんです。

>>487がﾏﾝｾｰ橋にしがみついてﾀｼｰﾛしてますたYo....
| Φ(|´|Д|｀|)Φ |>>1来ねぇかな.... ←>>487

来年の七夕に会いましょう。

(´・ω・` )　　　　　　　　　( ´・ω・`)
(´・ω・` )　　　　　　　　　( ´・ω・`)
( ´・ω・`)　　　　　　　　　(´・ω・` )
( ´・ω・`)　　　　　　　　　(´・ω・` )
　( ´・ω・`)　　　　　　　(´・ω・` )
　　　( ´・ω・`)　　　　(´・ω・` )
　　　　　( ´・ω・`)(´・ω・` )
　　　　　 ( ´・ω・`´・ω・` )
　　　　 　 ( ´・ω・・ω・` )
　　　　 　　　(´・ωω・`)
　　　　　 　　 (´・ω・`)
　　　　　 　　　.(・ω・)
　　　　　 　　　　(ω)
　　　　　 　　　　 ω
　　　　　 　　　　 .・

hikoboshi-arcm month も半分以上経過したわけだが、なんか成果あがったんか？

オフ会で写真をゲッツしますた！

|.Φ(|´|Д|｀|)Φ.|>>1の写真ｹﾞｯﾂ.... ←>>514

hikocrt-0.0.2

来そうなﾖｶｰﾝ

7月終わったな・・・（´ー｀）

　　　 　∧＿∧　 ∧＿∧
ﾋﾟｭ.ｰ　（　 ・３・） (　　＾＾ ） ＜これからも僕たちを応援して下さいね（＾＾）。
　　＝〔~∪￣￣￣∪￣￣〕
　　＝ ◎――――――◎ 　　　　　　　　　　　　　　　　　　　　　山崎渉&ぼるじょあ

hikocrt期待age

http://homepage.mac.com/hiroyuki44/hankaku06.html

hiroyuki44がきますた

　　　　　　　　　　　: ::.゜ ゜ ゜゜｡･｡゜.゜..
　　 ﾐ /彡　　　　　　　:::.゜｡ ゜･｡゜゜. . 　. .
..ﾐ､|ﾐ /／彡　　　　　http://hikoboshi-arcm.sourceforge.net
ミ.|.ﾐ/ .／.| 　 　　　　　　　　　:::.゜｡ ゜･｡゜゜. . 　. .
.|/／|.　　[]　 ∧ｖ∧　　　　　　　　　　: ::.゜ ゜ ゜゜｡･｡゜
/.　 []　　 　（〃ﾟーﾟ）　　　　　　　　　　　:::.゜｡ ゜･｡゜゜. . 　. .
┬┬┬┬┬┬┬┬-O∞O‐┬┬
‐┼┼┼┼┼┼┼┼‐┼┼┼┼┼
┼┼┼┼┼┼┼┼┼‐┼┼┼┼┼

>>522
長野県人？

>>522
.｡.:*･゜ﾟ･(´ー｀).｡*･゜ﾟ･*:.｡.

hikoboshi-arcm month 2003 7/7-8/7 1ヶ月経ったわけだが…
zip でも lzh でも良いけど圧縮/解凍出来るようになったのはあるのか？

>>525
ていうかHPD仕様ができてないしそれ以前の問題

もう>>1はへたれすぎ

イマイチ理解できんのだが圧縮/解凍部分を
後回しにして営農ギコは何して遊んでるの？

幼女観察

妹いぢり

>>527
もう反論することもできない今日この頃な>>1でつ。
てかもう放棄したんじゃない。プロジェクトページも。。。

>>530
今もプロジェクト進行してる模様。
プロジェクトページ見てみれば？
>>527
プラグインのインターフェースの仕様を練ってるんでしょう。
それが終わってからじゃないと圧縮展開部分もできないし。

一応、応援しとりますのでがむばってね。
って、もうここ見てないか・・・・

531は営農ｷﾞｺ

バレタ!!━━━━(・∀・)━━━━

>>531
> プラグインのインターフェースの仕様を練ってるんでしょう。
http://hikoboshi-arcm.sourceforge.net/index.php?%5B%5BHPD%5D%5D
HPD のページは1ヶ月前から動いてないみたいだが…

>>534
ほい
ttp://hikoboshi-arcm.sourceforge.net/index.php?%5B%5BStat%5D%5D

>>534
って、よくみたら534はリンク先の「ご意見はこちらへどうぞ」の日付で
判断してたのか・・・・・

>>535
？？？ ほいって言われても…
成果が出たのかって意味ではやっぱり「動いてない」し(少なくともHPDは)。
外野から見れば何もやってないようにしか見えないんだが。

>>537
成果って入ってるけどあなたの考える成果ってどういうものなの？
もしかして普通のソフトみたいにベータ版みたいなものが出てほしいの？

>>538
> 成果って入ってるけどあなたの考える成果ってどういうものなの？
仕様、またはその草案、ソースコード、実行可能ファイルなどなど。

一応言っとくけど、漏れが言った仕様を練るっての、作者が仕様を考えているってこと。
外野からはそら見えない。
ちゃんと不都合がないかチェックしてからでないと公開できないでしょ。
HPDのページ自体は動いてないけど>>535のリンク先でHPDの作業を2003-07-17から始めたって書いてある。
でも内部構造の考え直し中らしいから、どなんだろ。

>>540
ひょっとして営農ギコは最初から完全な仕様を作りたい、とか思ってる？

とりあえず作ってみて、失敗作だったら作り直すって方が若者らしくていいやね。
失敗の度合いが小さければ部分的な修正で済むし、
失敗の度合いが大きければ全部作りなおさにゃならんけど、今の状態よりマシ。

営農ギコでてこいｺﾞﾗｧ！（ロッカー叩いてるAA

>>541
失敗作を出すとそこで見切りを付けられる。
あとから挽回は不可能。


















になる事もあるから慎重になってもいいと思う。

これ基本的にはユーザーが直接使うソフトではないだろ

たしか、UNLHA32.DLLの中の人が施した変更・改訂がそのまま統合アーカイバの仕様になる状況に嫌気がさして
ある程度カチッとした仕様を作ってその上でやりたい、とかそんな風なことを言ってた気がする。

>>541
もしものために言っとくけど漏れは営農ギコじゃないから（>>533で冗談でふ）
あとこのプロジェクトは、
「アーカイブを操作するライブラリ仕様などを開発するプロジェクト」
なので間違ってたらそれを使って圧縮・展開DLL作った人が迷惑するから。

これが完成したら統合アーカイバDLLはどうなるのかな？

>>546
> なので間違ってたらそれを使って圧縮・展開DLL作った人が迷惑するから。
対応ソフトが作られなければ誰にも迷惑はかからんし、
仕様とか草案のレベルでは叩かれても見切られることは無いと思うが。

それに一発目から完全な仕様ってのは無理だと思うけど、それについては どー思うね？

>>547
変わらず存続

>>547
それ以前に、これは完成するのか？

>>548
仕様や草案ならすでに出てるジャン。
最初から完全ってのが無理なのは当たり前でしょ。
作者が完全な仕様を作ろうとしてるってのはあなたが勝手に言っただけど、
それがいったい何？

>>543
DLL利用者の側から見れば、
とっとと消えてくれたほうがサッパリするって考えもあると思うぞ。

>>552
意味が分からないけど。
今現在DLL利用者にはなんの被害もないじゃん。

アルファ版を名乗っている間は仕様の書き直しも許されるんじゃないの？
ベータ版を名乗って以降はその通りのコーディングをしていく他ないだろうけど。
一般論として。

ZIP関連（特にUNZIP32.DLL）、CAB32.DLLはｲﾗﾈ
営農ギコさんのでまともなの作ってほしいね

>>551
> 仕様や草案ならすでに出てるジャン。
でてるね。よく見て無かったよ。すまん。

でも逆に言うと、(仮であれ)仕様があるのにコードが出てこないってのは何でだろ？

>>553
> 意味が分からないけど。
(自分も周りも)変な期待をしなくて済むようになるので。

>>556
普通は仕様が固まってからコーディングするでしょ？
仮の仕様でソース書いてたら、仕様変更したら無駄になる。

>>557
そんなこと言ってたら新規な物作れないじゃんか（；´Д｀）

>>558
> 普通は仕様が固まってからコーディングするでしょ？
仕様が固まるっていつよ？
ウォータフォールモデルの信者じゃあるまいし、
普通はある程度の仕様が出来たらコーディング開始するけどね。

> 仮の仕様でソース書いてたら、仕様変更したら無駄になる。
新仕様と旧仕様に同じ部分がまるで無い、ってんでなければ完全に無駄にはならんが。
どうせ「固まった仕様」だって変更されないって保証はないし。

いま周辺ライブラリ作ってるじゃないか
進行遅いって言うのは置いておいて

>>561
> いま周辺ライブラリ作ってるじゃないか
それって、仮の仕様でソース書いてるんじゃ？

>>559
> そんなこと言ってたら新規な物作れないじゃんか（；´Д｀）
？

>>560
ああ、ごめ。「大体」固まってからだね。
大体が抜けてた。
でもこれマルチプラットフォームに対応するんで
そこら辺の調査やテストに時間かかるでしょう。
周辺ライブラリってこれかな？
ttp://hikoboshi-arcm.sourceforge.net/index.php?%5B%5BHCL%5D%5D

>>564
> でもこれマルチプラットフォームに対応するんで
> そこら辺の調査やテストに時間かかるでしょう。
もはやマルチプラットフォーム対応のための調査がメインになってるような印象…

10日も放置か　age

あーじゅ

そろそろ半年たつけど何か決まったー？

ttp://hikoboshi-arcm.sourceforge.net/
日に日に氏にゆくぺぇじ。。。。

終了でつか？ｗ

もうとっくに終わりでつよ。

保守

ttp://hikoboshi-arcm.sourceforge.net/
＞事情により終了することになりマスタ。

営農ギコもうやめちゃったの？

なんかうれしいね

夏草や

言及ｷﾎﾞﾝﾇ

事情を説明しろ

隠れて続けてる模様。

営農ギコどういうことなのか説明しろよ。SYNさんも困ってるぞ。

誰かがWiki書き換えたオチ?

箔られたんじゃないの？
ここセキュ甘いって噂聞いたことあるし

やる気ない事には変わりない

八苦されたことにすれば威厳も保てるからこれでいいじゃないか！

>>583
営農ギコに威厳なんぞあったんかいな？

なんかいつぞやのLhaplus作者みたいな展開だな

で、釈明のコメントまだ？

釈明ｷﾎﾞﾝﾇ

言い訳でもいいから

飯能汁!!

　　　　　　　 ∧
　　　　　　　_|::::|＿_
　　　　 　／::|::::|　　＼
　　　　 /　　 |:::|　　　:＼
　　　　/　　　 ||　　　　:ヽ
　　 ┌|（⌒ヽ :||　..:⌒:　|┐　　 ／￣￣￣￣￣￣￣￣￣
　　　|::|::ヽ.__:）:||（___ノ　::|::|　　│　いつもソフトウェア板を応援してくれてありがとう。
　　　 |:|: ..　　 :||　　　 .. |:|　　│　このｽﾚは急に終了することになった。
　　　　:|: ..　　 ||　　　 ..||　＜　　いつまたみんなの前に姿を見せる事ができるようになるのか、
　　　　 :＼　［_￣］　/::|　　　│　私にもわからない……
::　　　　　|＼|_|_|_|_／:::|　 　　＼＿＿＿＿＿＿＿＿＿＿＿＿
　　 ＿＿|　|　　　/ /　:|＿＿＿
　 　＼　_| ＼ 　 /........ﾉ~ 　-r　　＼
　　＼....|:::＼:＼丿　/,　／,/...／._　＼
　 /....＼.レ...　／＼..|　/　　／　／￣ ｀＼
　 ﾚ.........|/....／ �R‐＼′

>>332 に押しかけてみるとか。

368 営農ギコ ★ [ 2003/09/10(Wed) 23:01 ]
営農ギコの無糖焙煎屋 (Cafe EINOU-GIKO)　〜でじらじ〜

本放送第14回　漏れの季節に突入・・・秋の夜長に延々と。
ということで、今週からは忙しいのですにょ。

370 営農ギコ ★ [ 2003/09/11(Thu) 00:03 ]
後半は24:30からです。

営農ギコ生きてるんだったらこっちにも来てくれよ・・

だめだめだな…

笑えない

釈明ｷﾎﾞﾝﾇage

これって有罪？

> Hikoboshi Archiver Framework
>
> 20030912 - Memo (EINOU-GIKO)
>
> 　・ ほんと密かに進行中。詳しくはソースを見るとか。
> 　・ Wikiは改竄されるのが当り前。なんとかしないとねぇ。ま荒しても無駄だね。
>
> 　・ 、、、というか、またsf.netのデータベース飛んだ？
> 　・ 飛んでも作りなおせばいいんだけどね。ちょうど１から考え直していたし。
>
> 　・ その他御連絡などあれば[email protected]へ。某所で愚痴っても届きません。
>
> 　・ 復活してよかった。(^^ -- m@unzoo? 2003-09-11 (木) 20:54:32

復活

>>580
自分で消しました。

誰か跡継ぎしたら。

ひさしぶりにこのスレ見にきますた。
どれどれ

なんつーのか・・・
3ヶ月ぶりなんだが、ますます糞スレ化が進み、
期待してた開発再開も行われてない・・・
>507以降登場してないし、
サイトは消えてる

このスレが立つ前から状況見てたけど、






　　　　　　　　　　　　　　最　　　　　　　　　　　　悪　　　　　　　　　　　　　　

移転したらしい
ttps://sourceforge.jp/projects/hikoboshi

死んでないからよしとしようや。

保守

　　　　　　　 ∧
　　　　　　　_|::::|＿_
　　　　 　／::|::::|　　＼
　　　　 /　　 |:::|　　　:＼
　　　　/　　　 ||　　　　:ヽ
　　 ┌|（⌒ヽ :||　..:⌒:　|┐　　 ／￣￣￣￣￣￣￣￣￣
　　　|::|::ヽ.__:）:||（___ノ　::|::|　　│　いつもソフトウェア板を応援してくれてありがとう。
　　　 |:|: ..　　 :||　　　 .. |:|　　│　このｽﾚは急に終了することになった。
　　　　:|: ..　　 ||　　　 ..||　＜　　いつまたみんなの前に姿を見せる事ができるようになるのか、
　　　　 :＼　［_￣］　/::|　　　│　私にもわからない……
::　　　　　|＼|_|_|_|_／:::|　 　　＼＿＿＿＿＿＿＿＿＿＿＿＿
　　 ＿＿|　|　　　/ /　:|＿＿＿
　 　＼　_| ＼ 　 /........ﾉ~ 　-r　　＼
　　＼....|:::＼:＼丿　/,　／,/...／._　＼
　 /....＼.レ...　／＼..|　/　　／　／￣ ｀＼
　 ﾚ.........|/....／ �R‐＼′

これ行きます？
http://hikoboshi.sourceforge.jp/20031004.html

　　　　　　　 ∧
　　　　　　　_|::::|＿_
　　　　 　／::|::::|　　＼
　　　　 /　　 |:::|　　　:＼
　　　　/　　　 ||　　　　:ヽ
　　 ┌|（⌒ヽ :||　..:⌒:　|┐　　 ／￣￣￣￣￣￣￣￣￣
　　　|::|::ヽ.__:）:||（___ノ　::|::|　　│　いつもhikoboshiを応援してくれてありがとう。
　　　 |:|: ..　　 :||　　　 .. |:|　　│　hikoboshiは急に終了することになった。
　　　　:|: ..　　 ||　　　 ..||　＜　　いつまたみんなの前に姿を見せる事ができるようになるのか、
　　　　 :＼　［_￣］　/::|　　　│　私にもわからない……
::　　　　　|＼|_|_|_|_／:::|　 　　＼＿＿＿＿＿＿＿＿＿＿＿＿
　　 ＿＿|　|　　　/ /　:|＿＿＿
　 　＼　_| ＼ 　 /........ﾉ~ 　-r　　＼
　　＼....|:::＼:＼丿　/,　／,/...／._　＼
　 /....＼.レ...　／＼..|　/　　／　／￣ ｀＼
　 ﾚ.........|/....／ �R‐＼′

さ　が　り　す　ぎ

↑
　　　　　　　 ∧
　　　　　　　_|::::|＿_
　　　　 　／::|::::|　　＼
　　　　 /　　 |:::|　　　:＼
　　　　/　　　 ||　　　　:ヽ
　　 ┌|（⌒ヽ :||　..:⌒:　|┐　　 ／￣￣￣￣￣￣￣￣￣
　　　|::|::ヽ.__:）:||（___ノ　::|::|　　│　いつもhikoboshiを応援してくれてありがとう。
　　　 |:|: ..　　 :||　　　 .. |:|　　│　hikoboshiは急に終了することになった。
　　　　:|: ..　　 ||　　　 ..||　＜　　いつまたみんなの前に姿を見せる事ができるようになるのか、
　　　　 :＼　［_￣］　/::|　　　│　私にもわからない……
::　　　　　|＼|_|_|_|_／:::|　 　　＼＿＿＿＿＿＿＿＿＿＿＿＿
　　 ＿＿|　|　　　/ /　:|＿＿＿
　 　＼　_| ＼ 　 /........ﾉ~ 　-r　　＼
　　＼....|:::＼:＼丿　/,　／,/...／._　＼
　 /....＼.レ...　／＼..|　/　　／　／￣ ｀＼
　 ﾚ.........|/....／ �R‐＼′

終わってないしｗ

hikocrtの仕様を考えませう

おお！いいですな。

まず, 対応形式を考えるべきかと。
1. 解凍ソース or 解凍DLLがあり,
2. ライセンスがかったるい(L)GPLではない
もので, 対応してほしい形式とかありますかおまいら?

安芸

とりあいず zip, lzh, cab, gca, rar くらいはほすぃと漏れは思っている
おまいらの意見ｷﾎﾞﾝﾇ

lzhとgcaは和製なので期待してます。
zipとcabはMSも使っているので大切だと思います。
rarは有名なので大切だと思います。

ただしcabは規格がいっぱいあるので扱いを厳密にした方がいいと思います。

相変わらず要望の段階ですか

形になれないから仕方ないんじゃないかな。

>>613
tar、gzip、bzip2は必須かと。マルチプラットフォームで、フリーだし。

yz1とか微妙だよな。

とりあえず、関数とか構造体の規格を作らないと。
解凍専用・圧縮解凍両用の２種類のDLLが必要になるのかな？

対応形式なんかDLL作れる人がやればいいんだから、今は暫定的な仕様を考えないと。

統合アーカイバdllの
API名統一だけでいい気がする。

>>620
コマンドライン形式も統一しないと無意味。

ああ、そんなAPIもあったねぇ。
使ってるアプリってあったんだ
OpenArchive系だけでいい気が。

基本的にプラグインを置くだけで自動で読めるようなものにしないと使い物にならないね。

とりあえず、統合アーカイバを参考に誰かAPI・コマンドラインを統一した仕様を書いて見せてください。

>>619
その辺は「何ができるか」を取得する関数を作っておけば済むかと。

>>623
むしろSusieプラグインのAx系のほうが参考になるような。

いつになったらできるのか知りたい

>>625
そんな速くできたらLonghornももう出てる(w

7z, Kty, Zpr, Dgcaとかどうなるのかな

Kty,Zpr辺りはさすがに需要が少ないのではないかと…
ご当人の前で言うのも心苦しいのですが。

出たぁピンポイント爆撃

白河の関より北は東北。

…誤爆

漏れはご当人ではございませんでつ。
過去の形式リストで相談次第になっていたので疑問に思っただけでつ。

とりあいず

本日リリース予定hikocrt0.0.2期待age

＼|／
/⌒ヽ　　　／￣￣￣￣￣￣￣￣￣￣￣
| ゜Θ゜）＜　そうでもないよ。
|　∵　つ　＼＿＿＿＿＿＿＿＿＿＿＿
|　∵　|
＼＿／

黄鉛age

アージュ

ほっしゅ

ほしゅ

StarBookｶｺ(・∀・)ｲｲ!

Ratbetaって14歳だったのか（今更

w

年末掘り起こし。

age失敗

これ、どうなったのかなあ？
はなから期待はしてないけど。

俺1さんと一緒にこのプロジェクト盛り上げていきたいんですが、もう遅いですかね？

>　お聞きいただきまして、ありがとうございましたにゅー。
これじゃダメだｗ

>>644
遅くない独自にやってくれ。１を当てにしても無断だ。

>>644に期待age

新しいアーカイバプラグイン、考えれば考えるほど
COMやXPCOM、もしくはもどき で設計したくなってくるからなぁ

なんか復活しそうな予感。
ttp://hikoboshi.sf.jp

開発どうなった？

チョコあげたよ

純C#で、.NETのアセンブリDLLになってるアーカイバライブラリを作ってみよう、
とか大それたことを考えているんですが、どんなもんでしょう？

完全に.NETの枠の中で完結できる圧縮展開ライブラリは、これから需要が出てくると
見てるんですけど。

>652
とりあえず作ってから言おうな
ネタと勘違いされると困るだろ

まあ、面白そうではあるね。
個人的にはjavaとかでも良いけど。

ただ、速度面が重要視されがちな分野でVMはどうかというのが疑問なんだけど。

大学受験合格した？

復活してた？

age

タコが仕切るから、このプロジェクトもあぼーんした。

このスレはアーカイバ作者>>389の正体をさぐるスレになりました

誰か引き継げよ。

>>660
SYNに決まってるじゃん

>>662
違います。それに私は、>>389ほど状況にも詳しくありません。

どうしてそういう発想になったのでしょうか。
どうも私に恨みがある人の匂いがしますが、もしそうなら覚悟しておいた方が
いいかもしれません。そろそろ何もかもしゃべってしまいますので。
違うなら、気にせず勝手に妄想していてください。

>>663
SYNﾀﾝ下の段は余計な気が・・・・・・・
ファルコムとか姦酷とかのデジャブは正直勘弁願いたい。

>>664
申し訳ない。ここでその話をするわけではないので、気にしないでください。
あと、どういうわけか、ファルコムのアンチと思われているかもしれませんが、
私は株を持っているほどのファンですので。一応。

>>663
過剰反応しすぎだと思うぞ。

age

>>665
あんた暇だなｗ
プログラマじゃないんだ

389がGCA作者とはとても思えんがなｗ
アーカイバ作者ねー(´･∀･`)

>>668 低レベルですが一応プログラマ(平日15時からと土日)です。

休み無いんですか。大変ですね。
在宅ですか？会社行ってるんですか？

>>671
どちらかというと、休みに趣味でプログラマをやっているという感じですね…。
在宅にもできますが、引篭りにならないように行っています。

1は逃げたしSYNﾀﾝが新しいアーカイバプラグイン作ってよ。
SYNﾀﾝもやる気あったんだよね？

>>670
なんだ、やっぱプログラマなんだ
高レベルな方は誰でもできるからね（笑）
新アーカイバの方、頑張ってね

新アーカイバプラグインは >>1 は逃亡したみたいだし、
後継者が名乗り出ないなら終了でよいのでは？

今現在プロジェクト(?)を抱えてる人にやれって言うのはどうかと思うぞ。
SYN氏には DGCA を頑張ってもらった方がよさげ。

終了するのはもったいない気が。
このプロジェクト完成したらいい物が出来ると思うし。
>>1は力量不足。

是非このプロジェクトを誰かに引き継いでもらいたい。

>>676
完成って統合アーカイバの主要なDLLをすべて移植したら？
それとも、優れたAPIの仕様を規定してドキュメント化したら？

>>677
後者。
まずAPI仕様書を作成しないと。

SYNさんも仰有る通り世界標準になって欲しい。
なったらすごいことに・・・なると思う。

>>676
終了でいいじゃん。
引き継ぐに値するような成果物は一切ないし、
やりたい奴は新しいプロジェクトなりを立ち上げれば良いと思うが。

っつか、>>676 が引き継ぐか？

だれもやらないなら引き継ぎたいが。

>>680
是非

>>1 の逃亡先らしい。
http://hikoboshi.sourceforge.jp/pukiwiki.php

>>676 と >>1 で競争してみれば？
どっちがより早く、より良いものを作れるか。

では引き継ごうかと。

>>1とは違った物になると思いますが、その辺は勘弁してください。
あくまで目的はこのスレのタイトルなんで。

ｷﾀ━━━━━━(ﾟ∀ﾟ)━━━━━━ !!
>>676に期待!!

とりあえず専用のページ作りました。
http://memai.s58.xrea.com/

まだプロジェクト名が決まっていません。
何か良いプロジェクト名があれば教えてください。

まずは>>1の言うhikocrtの作成から始めます。
その中でまず必要な関数のリストアップから始めます。
こんな関数必要だろうと思う物なんでも教えてください。

>>685
すんごい興味あるけど、基本コンセプトくらい無いと
「関数」なんて具体的な提案出しようが無いと思いまつ。

>>686
申し訳ない。
まずこちらが何か示さないといけませんでした。

ひとつだけお願いしたいのは、「ファイル」APIを基本仕様に入れないこと。
ファイルの圧縮展開はIO用のオブジェクトを経由して行うようにして欲しい。
展開を自由に制御できないアーカイバは、テンポラリファイルを経由する
プロクシオブジェクトなどを使うようにして、極力ファイルシステムに依存させないほうがいいと思う。
こいつがあると、API仕様が肥大化もしくは曖昧化しやすいから。

イメージ的には、Javaとかのストリームリーダーみたいな奴かな。

FDIやFCIもファイル入出力とかメモリ割り当てとか
OSとやりとりが必要なものは全部外出しにしてますね

>>689
ActiveACE、FDI、FCIのやりかたはコード書くのが大変かもしれませんがコールバック関数でOSとやりとりする関数を登録しておけば
やりやすくなるかも(>>1のいうhikocrtあたりが)。

>>1の代理です。とりあえず>>1の現状を。
(以下はメールからの引用です。)

===================================
Hikoboshiですが、なるべく早く再開しようと努力はしているのですが、未だ
きちんとした形で示せず、2chの方々やその他関係者の皆さんにご迷惑を
かけているかと思います。

それは、個人的な環境が変わってしばらくプログラムを書くことができなかった
というのが直接の理由なのですが・・・。

現在、Hikoboshi や Arcdll の関連ページを見ることだけでも、恐怖心が
あります。いつこうなってしまったのかは分かりません。

本当は手を引くべきだと思います。
ただ、それでも Hikoboshi をやってみたいと思うと内心思うのです。
昨年 Hikoboshi の提案をして作業した際、自分の技術力の未熟さが
分かり、以来色々と勉強してきています。前よりは良いかもしれません。


こんな事情ですが、そんな自分を許してもらえればと2chの方々に
お伝え頂ければ幸いです。(この内容をそのまま載せてもらっても構いません)


動いて頂いている方には、よろしければこちらに連絡いただければ
嬉しいです。自分も復帰するよう努力するつもりです。
===================================

>>1さん頑張ってください!

せっかく676氏が名乗り出て今やってくれてるのに
いまさら>>1がでてきてさ、また>>1待ちしろって言ってるのかい？

保守

今こんなもの作ってる。100% .NET マネージドコードで、入出力は Stream のみ、なるべくシンプルに、って感じで。
http://up.isp.2ch.net/up/d57ea732d96e.zip

約１年ぶりぐらいにこのスレ発見して、まだあったのかとおもったことと、
でも開発はすすんでないんだねと最新のレス２つでわかったことと、
相変わらず>>691みたいな「再開します」みたいなうだうだ言い訳文が１年以上たってる今もかかれてて、
こりゃ壮大な釣りだなぁとおもったりしました。
いや一年前ここ無視して自力でアーカイバ作る判断は正しかったんだなぁともしみじみおもった。

>>695
.NET なら SharpZipLib とか使えば？

またも代理です(汗

http://hikoboshi.sourceforge.jp/pukiwiki.php の方でちょっとしたアンケートを
やっていますので、よろしければお願いします。

…とのこと。

>>696のアーカイバ教えてほしいな。公開してんの？
自力でアーカイバ作る、って統合アーカイバDLL使ってないってこと？

なんか>>1が復活しそうなんで、私も>>1の支援という形で協力しようかと。

hikoboshiってどういう意味なんだろう

いつかサイカイするってことでどうだろう

http://hikoboshi.sourceforge.jp/pukiwiki.php?libhikoboshi
を見たけど、手を広げすぎだと思われ。

構想を実現しようとするとドキュメント含めて最低数万行程度必要と推測。
富士通のプログラマが5万行/年とか聞いたので、
とんとん拍子で進んでも実装するのに半年とか1年とか必要ではないかと思われ。

というかこの構想ってアーカイバじゃなくて、
OS間エミュレータみたいなものになりつつあるような気が。

それならCygwinでいいんじゃないかと思わなくもない…。