Нужные функции ядра.

Internal structure and you change requests/suggestions
  • 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.
    Last edited by Leency on Sun Apr 12, 2020 1:34 am, edited 3 times in total.
    Из хаоса в космос
  • А почему нельзя это сделать через clipboard?
    The Glass is Always Half Full! :mrgreen:
  • Кажется это таки работает между приложениями.
    Сейчас буду дальше смотреть. Идея с clipboard хорошая, но там код довольно большой чтобы его включать в каждую программу.
    Из хаоса в космос
  • Так. Нет, все НЕ нормально.

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

    Eolite:

    Code: Select all

    $mov     eax, 68
    $mov     ebx, 22
    ECX = "LMENU"
    EDX = 20
    ESI = SHM_CREATE
    $int     0x40
    MENU:

    Code: Select all

    $mov     eax, 68
    $mov     ebx, 22
    ECX = "LMENU"
    EDX = 20
    ESI = SHM_WRITE
    $int     0x40
    => E_ACCESS т.е. я никак не могу записать данные. Что это блин такое?
    Я не хочу использовать буфер обмена, почему я не могу записывать данные из МЕNU в область открытую EOLITE?
    Из хаоса в космос
  • Who is online

    Users browsing this forum: Google [Bot] and 12 guests