Board.KolibriOS.org

Чё то я не совсем понял - бОльшая половина общается на этом форуме, остальные на форум.меос.ру
вот и дублирую тему..

1) надо добавить ф-ю возвращающую полный путь к запущеной программе.
2) можно было бы добавить функцию для создания виртуального диска (типа subst в досе/винде)
3) и создания рамдиска с изменяемым размером. видел такую прогу под винды - позволяет работать с рамдиском как с обычным носителем.
даж проги устанавливать на него.

на счёт первого. по идее ядро должно где-то хранить эти пути. если не хранит, то придётся как то выделять память.. а это кстати, если в Меос можно запускать только 255 процессов, а путь к каждому должен составлять не более 255 байт, то 65 килов... а нужно это для того чтобы не прописывать в проге полный путь к, например, конфигурационным файлам. а так - проверил откуда запущенна прога, сохранил путь, там и ищи... я, если смогу, попробую полазить в ядре, но если кто в этом больше разбирается, плз ответьте!

второе и третье это конечно просто понты, но в некоторых случаях очень полезные весЧи.

DoomEd Archangel

1) Вообще то ядро в себе не хранит путь, оно хранит только ссылку на путь и то только во время запуска приложения. Придется реализовывать стек, в котором будут, хранится пути к запущенным процессам. Но, пожалуй, лучше делать это после внедрения менеджера памяти, так как в текущей карте памяти ядра очень мало места, а оно может, понадобится и для более важных дел. Примеров приводить не буду, но имхо лучше делать так.
2) Не актуально, так как большинство пользователей склоняют нас к отходу от концепции РАМ диска. Это актуально только для компьютеров с большой РАМ и отсутствием винчестера. А где ты такие видишь в массовом порядке?
3) То же самое.

ок. булдем ждать
я ж написал что это просто понты

Видимо, пункт 1 неизбежно придется реализовать для поддержки длл'ек.

a prichem zdes' subst i mnogo RAM? subst ved' pozvolyaet videt' papku na fizicheskom nositele kak sam fizicheskiy nositel'...

Chugumoto
он имел вииду пункт 3

я немного отошёл от дел, но теперь постараюсь вернуться
щас для разминки пара бестолковых программок, доделаю выложу =)
а вобщем вопрос в следующем - что на счёт реализации ф-ии упомянутой в п.1?
то есть менеджер памяти готов (ну почти готов), а эта ф-я оказалась бы полезной (учитывая то, что места на рамдиске нету). в ядре я нифига не понял, но т.к. Марио объяснил что ядро хранит ссылку на путь к приложению, соответственно, надо либо реализовать это как
>Придется реализовывать стек, в котором будут, хранится пути к запущенным процессам.
либо отдельным приложением, но это будет жрать больше прц времени и памяти... незнаю =)

DoomEd Archangel
Мы с Андреем Халявиным это уже обсуждали.
В принципе в заголовке MENUET01 последние 4 байта зарезервированы, вот их и можно использовать в качестве указателя на область памяти внутри приложения. Механизм как при передаче параметров при запуске.
Есть, конечно, ряд не корректно написанных программ, которые игнорируют эти 4 байта, то есть в них они не зарезервированы и забиты чем угодно, но не нулями.
И, к сожалению, в Колибри 0.5.0.0 эта возможность не будет реализована по причинам:
1) Отсутствие времени.
2) Отсутствие свободных челов.
3) Банальная лень.
4) Че ни будь, сам придумай...

Вот такие пироги с котятами.

P.S. Если все пойдет успешно, то после публикации исходников ядра дальнейшая разработка будет, производиться при помощи SVN (SUB VERSION) сервера. И я надеюсь, эта вещь будет реализована одной из первых. А так как на чтение доступ будет открыт для всех, то можно будет сразу скачать ядро.

не совсем понял про эти 4 байта.
Если их использовать, то соответственно надо будет определять их, а из этого следует что одна и та же программа запущенная из разных мест, может вызвать непредвиденные результаты. А если ориентироваться по PID? ведь он задаётся во время запуска программы, я предполагаю тогда, когда ещё сохранён указатель на путь к файлу.
???

DoomEd Archangel
При чем здесь PID?
Ты определяешь эти байты как указатель на область памяти в теле программы, куда ядро скопирует путь. Причем для каждого запущенного приложения область памяти индивидуальна, так как выделяется внутри области приложения. Если в заголовке стоят нули, то ядро ничего записывать не будет. Механизм такой же, как при передаче параметров при запуске. Ты же можешь запустить кучу тинипадов с ASM кодом, и каждый из них компилирует приложение куда нужно! Чего тут сложного!?
Единственное ограничение - потоки будут иметь путь запустившего их приложения, но они и должны пользоваться именно этим путем!
Никто тебе не мешает запускать хоть 100 копий программы из разных мест. При этом каждая из них будет знать именно свой путь. Так как пути при запуске будет записан в тело каждой программы. А дальше ядро вообще не отвечает - программа может и затереть область, где прописан этот путь, так как это область в теле программы - в сегментах отведенных для данной программы. Все зависит от программиста.
Ну, если и час ты не понял, я тогда не знаю, как тебе объяснять...

ясна, теперь понял, просто я себе это представил так, что будет выделяться память в которой _ядро_ будет писать пути. сорри.
теперь ясно.

>Ну, если и час ты не понял, я тогда не знаю, как тебе объяснять...
ну тупой я, тупой (с)

DELETED.

А почему нельзя это сделать через clipboard?

Кажется это таки работает между приложениями.
Сейчас буду дальше смотреть. Идея с clipboard хорошая, но там код довольно большой чтобы его включать в каждую программу.

Так. Нет, все НЕ нормально.

Объясните почему происходит следующее:

Eolite:
MENU:
=> E_ACCESS т.е. я никак не могу записать данные. Что это блин такое?
Я не хочу использовать буфер обмена, почему я не могу записывать данные из МЕNU в область открытую EOLITE?