WorkPlaceShell

Уж несколько лет как мною нежно любим бывший шароварный, а ныне опенсурсный шелл 4os2. Среди прочих приятностей в нём присутствует и запуск по расширению. Скажем если прописать в CONFIG.SYS «SET .pl=S:\OS2\APPS\perl5\bin\perl.exe» то при вводе в командную строку файла с расширением ».pl» он отправится на выполнение перлу. Всё хорошо, но прописывать кучу системных переменных на все расширения это засорять конфиг и плодить лишние сущности. Но это-же OS/2! Как оказалось, если прописать в CONFIG.SYS строчку вида «set .*=S:\Scripts\WPSOpen.cmd» где WPSOpen простенький до безобразия скрипт на REXX, то набрав в командной строке, например, [f:\music]«08. An eye for an eye.mp3», мы увидим окошко любимого плеера и услышим музыку. При этом если в конфиг сисе прописаны другие ассоциации (на тот-же перл или питон) то они как работали так и будут продолжать работать не через WPS-ассоциации.

[21:19:31] _yoda: I was thinking about creating the Installer as a GUI app. I have never really 
created such a thing before - but most of current code should work in Sibyl too
[21:26:54] valeriusN: _yoda GUI installer can be made as optional part, but it is not really 
needed. I think it must have a minimal UI. It must work as a standalone installer with user 
interface. It would be desirable if will have a DOS or win32 version, as several windows users 
asked me for an installer; it can be useful for other platforms users too, so they must also 
have a (portable) installer version. 
[21:26:58] valeriusN: Also, we would like to have an installer version as a DLL callable from 
our version of warpin, for integration into osFree installer

В ReactOS обещают поддержку журналируемого варианта файловой системы FAT, так называемый FastFAT:

FastFAT_new — это новая реализация файловой системы FAT для ReactOS, основанная на библиотеке
FullFAT. Она заменит старый FAT в ReactOS-е. В скором времени в FullFAT будет реализация 
журналирования, но это не повлияет на совместимость с обычным FAT-ом. Для примера можно привести 
ext3, которая отличается от ext2 только журналированием. Эти две файловые системы можно 
конвертировать между собой без форматирования и потери данных. Активно ведут разработку файловой 
системы Алексей Брагин (Fireball) и создатель FullFAT — Джеймс Уолмсли.

"FullFAT — это высокопроизводительная и поктоко-безопасная реализация файловой системы FAT 
(поддерживающая FAT12/16 и FAT32) для встраиваемых устройств. Также можно включить опциональную 
поддержку длинных имен файловов при помощи настроек компиляции. FullFAT очень хорошо 
оптимизирован, и может быть использован даже на устройствах с малым количеством оперативной 
памяти."

К сожалению FastFAT_new не будет готов к выходу ReactOS 0.3.11, так как не реализован необходимый 
функционал. Поэтому следует ожидать его в 0.4.

Полезные ссылки:

Исходники в дереве GIT ReactOS

Valerius, ау!

Только что, на канале… Валериус отловил багу в хедере линуксовых исходников.

Как показало расследование, это оказалась не бага, а этакая «фича» компилятора OpenWatcom…

[14:52:29] valeriusN: Moveton: а что, в gcc если unsigned short в структуре поделена на 
битовые поля, то можно писать просто unsigned? -- я взял hpfs.h от линукса, а там много раз 
unsigned char, unsigned short и unsigned long заменены на просто unsigned -- так и должно быть? 
-- ватком на таких местах выдает неправильные смещения
[14:52:58] Moveton: valeriusN известная багофича стандарта C
[14:53:28] valeriusN: Moveton стандарта C? -- а почему ватком такого не понимает?
[14:53:43] Moveton: valeriusN что ж ты раньше молчал, что у тебя не unsigned, а битовое поле? ;)
[14:54:33] valeriusN: Moveton я вообще-то думал, что просто unsigned это unsigned long ;)
[14:54:47] Moveton: valeriusN ууу
[14:54:51] [Pasha]: так помнится icc на unsigned битовое поле всегда лепит 32 бита... а на все 
остальное матерится
[14:56:49] valeriusN: [Pasha] ватком тоже молчаливо предполагает что unsigned это unsigned long 
(если 32-разрядный компилер)
[14:57:32] Moveton: valeriusN вообще-то ватком предполагает int, как и положено
[14:57:45] valeriusN: Moveton выходит, поведение icc или wcc386 это не стандарт, а gcc ведет себя 
по стандарту?
[14:58:07] valeriusN: ну да, unsigned int а не unsigned long т.е.
[14:58:30] valeriusN: Moveton т.е., для битовых полей исключение?
[14:58:53] Moveton: valeriusN ща допишу ответ :)
[15:00:21] Moveton: valeriusN По синтаксису там дурка такая: согласно стандарта на битовое поле 
можно ставить тип только int. А вот какого оно размера, не специфицируется. VAC и gcc делают в 
итоге размер в соответствии с количеством бит в поле. Ватком расширяет стандарт и позволяет 
указывать произвольный целочисленный тип. При этом размер поля будет равен размеру этого типа
[15:01:36] valeriusN: хм
[15:03:02] valeriusN: а тут понимаешь ли, бочку стали катить на линух, что они де-стырили 
16-битный хедер и unsigned как было, так и оставили (но тогда б, по идее, ничего у них бы не 
работало)
[15:05:45] Moveton: valeriusN а в ваткоме оно у них наверняка и не работает :)
[15:06:38] valeriusN: Moveton просто на ваткоме никто не пробовал линуксовую hpfs собирать ;)
[15:07:33] Moveton: valeriusN ну так бы и попробовал. Перед тем, как портировать

Вот такая вот загогулина! (C)

[6:30:37] *valeriusN заюзал хедер hpfs.h из линуксовой HPFS. Оказалось, не без ошибок -- в  
структуре Dir entry поле типа unsigned short разбито на битовые поля. А в хедере стояло просто 
unsigned, т.е., 32-разрядное, а не 16-разрядное. Я долго не мог понять, почему у меня смешение 
имени файла от начала dir entry ватком вычисляет неправильно. Оказалось, в хедере бага. ;) как 
оно работает в линуксе, непонятно...

Всем привет! Сайт, в минимальной конфигурации, поднят и более менее сконфигурирован, DokuWiki это тот ещё конструктор «Lego». Пока можете почитать парочку рабочих и не совсем рабочих материалов по операционной системе osFree, а я продолжу «играть в конструктор».