Операционная система

[CHRV]

Около 4-5 месяцев.

Оптимист

Речь идёт о ПРИЛОЖЕНИЯХ операционной системы!

Посмотри заголовок сабжа или я по руски не бум-бум

Ксати кто нить пробовал лазерник к спринтеру подключать?

[cr0acker]

Около 4-5 месяцев.

Оптимист

Речь идёт о ПРИЛОЖЕНИЯХ операционной системы!

Посмотри заголовок сабжа или я по руски не бум-бум

Ксати кто нить пробовал лазерник к спринтеру подключать?

Я пробовал. Греет..........

[Mac Buster]

Оптимист

Напротив - реалист, самый настоящий. На 110%

Посмотри заголовок сабжа или я по руски не бум-бум

Я уже уточнял это вопрос

[Vasil Ivanov]

Оптимист

Напротив - реалист, самый настоящий. На 110%

Посмотри заголовок сабжа или я по руски не бум-бум

Я уже уточнял это вопрос

А программы под ОС на первое время самые что ни-на есть простые:

- асм, желательно с дебаггером, но не обязательно
- текстовый редактор
- графический редактор
- документация на ОС для девелоперов.

Этим софтом уже можно будет писать прикладной софт и игрушки
с картинками под самой ОСью. Ограничься этим и ради Бога, давай начинай кодить, за одними разговорами - может и жизнь пролететь,
не заметишь как .


P.S. Как у тебя на счет совместимости ОС-и с биосными процедурами
Спринтера ?. Или свой Биос будешь писать ?.
Это я к тому, что может быть, когда-нить, придется что-то предпринять,
чтобы отвязаться от софтового ПП-копирайта, когда они окончательно
"забьют" на Спринтер. Ессно имею ввиду Биос/ДОС ПП, кто не понял.
Кто/что думает ?.

[Mac Buster]

Ограничься этим и ради Бога, давай начинай кодить, за одними разговорами - может и жизнь пролететь, не заметишь как

Ну, кто сказал что ничего нет ?

P.S. Как у тебя на счет совместимости ОС-и с биосными процедурами Спринтера ?. Или свой Биос будешь писать ?.

Хочу "обмотать" оригинальный БИОС своими процедурами с перспективой замены кода Петерсовского БИОС на свой собственный.

Это я к тому, что может быть, когда-нить, придется что-то предпринять, чтобы отвязаться от софтового ПП-копирайта, когда они окончательно "забьют" на Спринтер.

Я думал примерно в том же направлении

[Vasil Ivanov]

Ограничься этим и ради Бога, давай начинай кодить, за одними разговорами - может и жизнь пролететь, не заметишь как

Ну, кто сказал что ничего нет ?

P.S. Как у тебя на счет совместимости ОС-и с биосными процедурами Спринтера ?. Или свой Биос будешь писать ?.

Хочу "обмотать" оригинальный БИОС своими процедурами с перспективой замены кода Петерсовского БИОС на свой собственный.

Это я к тому, что может быть, когда-нить, придется что-то предпринять, чтобы отвязаться от софтового ПП-копирайта, когда они окончательно "забьют" на Спринтер.

Я думал примерно в том же направлении

Одобрям! . Давай не теряй время зря . И когда можно будет твою ОС пощупать ? .

[Vasil Ivanov]

Не помню бросал ли тебе ниже-идущую инфу... ну вобщем смотри сам.

=== Cut ===
WingsOS - 16-ти битная многозадачная операционка Unix-подобная
(QNX-подобная) для C64 и Scpu.

http://www.king.igs.net/~billnacu/wings/
=== Cut ===



=== Cut ===
Subj : семафоpы

> Кто нибудь использовал сабж на пpактике?. Хотелось бы пpимеpчик
> c коментаpиями пpостенький.


В OS/2 имеется 3 вида семафоpов:

1. Mutual Exclusion (Mutex) semaphores. Использyются для yпоpядочивания
достyпа к pазделяемым pесypсам. Т.е. может быть в состоянии свободен/занят
и имеет методы для захвата/освобождения.

2. Event semaphores. Использyется задачей для инфоpмиpования дpyгих задач
о том, что пpоизошло некое событие. Т.е. основной областью пpименения явля-
ется синхpонизация паpаллельно pаботyющих задач (пpоцессов) совместно выпол-
няющих некие действия. Имеет методы Пpоизошло_Событие, Ждать_События,
Сбpосить_Событие.

3. Multiple Wait (Muxwait) semaphores. Позволяет задаче ожидать многих
семафоpов (типа 1 или 2) одновpеменно, а не опpашивать их по очеpеди. Ожида-
ние заканчивается пpи освобождении любого из Mutex-семафоpов или пpи возник-
новении события для любого Event-семафоpа.

Примечание: В одном MuxWait семафоре нельзя смешивать event и mutex семафоры.
В MuxWait семафор нельзя включать другой MuxWait семафор.


P.S. Фyнкции для pаботы со всеми 3 типами семафоpов описаны, напpимеp
в Control Program Reference.

Вот работа со вторым видом. Все на C. Но тут больше API вызовов, чем C кода.

Code: Select all

#define INCL_DOSSEMAPHORES   /* Semaphore values */
#define INCL_DOSDATETIME     /* Timer support    */
#define INCL_DOSERRORS       /* DOS error values */
#include <os2.h>
#include <stdio.h>

int main(VOID)
{
   PSZ     szSemName = "\\SEM32\\TIMER\\THREAD1\\EVENT1"; /* Semaphore name */
   HEV     hevEvent1    = 0;                   /* Event semaphore handle    */
   HTIMER  htimerEvent1 = 0;                   /* Timer handle              */
   APIRET  rc           = NO_ERROR;            /* Return code               */

   rc = DosCreateEventSem(szSemName,      /* Name of semaphore to create  */
                          &hevEvent1,     /* Handle of semaphore returned */
                          DC_SEM_SHARED,  /* Shared semaphore             */
                          FALSE);         /* Semaphore is in RESET state  */
   if(rc != NO_ERROR)
     {
       printf("DosCreateEventSem error: return code = %u\n", rc);
       return 1;
     }

   rc = DosAsyncTimer(7000L,              /* 7 second interval        */
                      (HSEM) hevEvent1,   /* Semaphore to post        */
                      &htimerEvent1);     /* Timer handler (returned) */
   if(rc != NO_ERROR)
     {
       printf("DosAsyncTimer error: return code = %u\n", rc);
       return 1;
     }
   else
      printf("Timer will expire in about 7 seconds...\n");

          /* ... add your other processing here... */

   rc = DosWaitEventSem(hevEvent1,             /* Wait for AsyncTimer event */
                (ULONG) SEM_INDEFINITE_WAIT);  /* As long as it takes */
   if(rc != NO_ERROR)
     {
       printf("DosWaitEventSem error: return code = %u\n", rc);
       return 1;
     }

   rc = DosCloseEventSem(hevEvent1);           /* Get rid of semaphore */
   if(rc != NO_ERROR)
     {
       printf("DosCloseEventSem error: return code = %u", rc);
       return 1;
     }

  return NO_ERROR;
}

Остальное смотри в тулките, можешь еще на edm2.com поискать или
на hobbes.nmsu.edu. Так же есть хорошая эха su.os2.prog
=== Cut ===

[Shaos]

Ограничься этим и ради Бога, давай начинай кодить, за одними разговорами - может и жизнь пролететь, не заметишь как

Ну, кто сказал что ничего нет ?

P.S. Как у тебя на счет совместимости ОС-и с биосными процедурами Спринтера ?. Или свой Биос будешь писать ?.

Хочу "обмотать" оригинальный БИОС своими процедурами с перспективой замены кода Петерсовского БИОС на свой собственный.

Это я к тому, что может быть, когда-нить, придется что-то предпринять, чтобы отвязаться от софтового ПП-копирайта, когда они окончательно "забьют" на Спринтер.

Я думал примерно в том же направлении

Одобрям! . Давай не теряй время зря . И когда можно будет твою ОС пощупать ? .

А мне последнее время все больше кажется, что хорошая ОС должна быть скорее переносимой и независимой от платформы, чем привязанной к конкретному железу. Иначе умирает платформа - умирает и система, оставляя поле для ностальгии лишь среди эмуляторов. ОС (вместе с поддерживаемым программным обеспечением) должна перешагивать через поколения процессоров и железа и двигаться в будущее. Писать ОС только чтобы запуститься на менее чем сотне существующих экземпляров экзотической железяки - тупик и пустая трата времени. Небольшие программы еще можно писать под единичные экземпляры аппаратуры, а операционные системы - нет.

[Vasil Ivanov]

Ограничься этим и ради Бога, давай начинай кодить, за одними разговорами - может и жизнь пролететь, не заметишь как

Ну, кто сказал что ничего нет ?

P.S. Как у тебя на счет совместимости ОС-и с биосными процедурами Спринтера ?. Или свой Биос будешь писать ?.

Хочу "обмотать" оригинальный БИОС своими процедурами с перспективой замены кода Петерсовского БИОС на свой собственный.

Это я к тому, что может быть, когда-нить, придется что-то предпринять, чтобы отвязаться от софтового ПП-копирайта, когда они окончательно "забьют" на Спринтер.

Я думал примерно в том же направлении

Одобрям! . Давай не теряй время зря . И когда можно будет твою ОС пощупать ? .

А мне последнее время все больше кажется, что хорошая ОС должна быть скорее переносимой и независимой от платформы, чем привязанной к конкретному железу. Иначе умирает платформа - умирает и система, оставляя поле для ностальгии лишь среди эмуляторов. ОС (вместе с поддерживаемым программным обеспечением) должна перешагивать через поколения процессоров и железа и двигаться в будущее. Писать ОС только чтобы запуститься на менее чем сотне существующих экземпляров экзотической железяки - тупик и пустая трата времени. Небольшие программы еще можно писать под единичные экземпляры аппаратуры, а операционные системы - нет.

Все правильно, но все это в большей степени относится к прикладному обеспечению, чем к ОСи.
Все-равно останется часть ОСи, привязанная к конкретному железу.
И производительность 8-ми биток несравнима с 32-х битками (и более),
поэтому из железа потребуется "выжать" максимум возможностей.
Иначе ОС будет не эффективной.

[Shaos]

Все правильно, но все это в большей степени относится к прикладному обеспечению, чем к ОСи.
Все-равно останется часть ОСи, привязанная к конкретному железу.

Угу - ядро, микроядро, нанодяро. Вокруг него все равно будет крутиться куча сервисов и программ системного и пользовательского уровня, которое не должно быть привязано к конкретному железу.

[Mac Buster]

Угу - ядро, микроядро, нанодяро.

Несколько не по теме, но всё равно выскажу мнение - я пришёл к выводу, что использование настоящего микро-ядра в случае восьмиразрядного процессора приведёт скорее к неоправданному усложнению кода, чем к его упрощению. То же относится и к пико-ядру. Скорее ориентироваться следует на монолитное модульное ядро, которое может быть изменено пользователем с административными полномочиями простой перекомпиляцией исходника ядра с предварительным выбором необходимых служб, записью полученного кода в специально отведенное для этого пространство носителя, и последующей перезагрузкой. Конечно предусмотрена возможность отказа от загрузки нового кода ядра и возврата к предыдущему (всякое бывает).

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

Совершенно верно. Так оно и есть на самом деле. Машинно-ориентированная часть кода обычно составляет от 2 до 10 процентов от общего объема кода ядра и служб. Другое дело что эти проценты пожалуй и есть самые сложные в системе

[Vasil Ivanov]

Угу - ядро, микроядро, нанодяро.

Несколько не по теме, но всё равно выскажу мнение - я пришёл к выводу, что использование настоящего микро-ядра в случае восьмиразрядного процессора приведёт скорее к неоправданному усложнению кода, чем к его упрощению. То же относится и к пико-ядру. Скорее ориентироваться следует на монолитное модульное ядро, которое может быть изменено пользователем с административными полномочиями простой перекомпиляцией исходника ядра с предварительным выбором необходимых служб, записью полученного кода в специально отведенное для этого пространство носителя, и последующей перезагрузкой. Конечно предусмотрена возможность отказа от загрузки нового кода ядра и возврата к предыдущему (всякое бывает).

Согласен на 100%. Сделать типа как в линуксе, прописал в lilo стабильное ядро, чтобы при необходимости загрузиться с ним и компили сколько хочешь свои девелоп-ядра .

P.S. Может оставить все эти термины - микро, нано, пико... ? .
Для 8-ми битки указывать размерность ядра вобщем-то не актуально . Все это можно назвать одним простым словом - ядро.

[Shaos]

Угу - ядро, микроядро, нанодяро.

Несколько не по теме, но всё равно выскажу мнение - я пришёл к выводу, что использование настоящего микро-ядра в случае восьмиразрядного процессора приведёт скорее к неоправданному усложнению кода, чем к его упрощению. То же относится и к пико-ядру. Скорее ориентироваться следует на монолитное модульное ядро, которое может быть изменено пользователем с административными полномочиями простой перекомпиляцией исходника ядра с предварительным выбором необходимых служб, записью полученного кода в специально отведенное для этого пространство носителя, и последующей перезагрузкой. Конечно предусмотрена возможность отказа от загрузки нового кода ядра и возврата к предыдущему (всякое бывает).

Видимо ты большой почитатель Торвальдса

Я кстати с ним по этому вопросу не согласен - для чистоты и логической ясности системы ядро должно быть минимальным. Никаких монолитных гигантов не должно существовать в природе!