Родилась как-то идея создать виртуальную машину

Ну или сервер приложений.

стал кодить....

ЭТО ОЧЕНЬ ДОЛГО!

Может кто что предложит?

 

а нафига это нужно?

 

Свой формат исполняемых файлов (не PE), причём более совершенный

Свои команды

Своя организация передачи данных

... и всё это в режиме эмуляции под win32

 

а нафига это нужно? не вижу смысла. изобретаем велосипед значит...

 

for=PE386

На первый взгляд может показаться, что это вилисипед, однако:

1. Это не значит, что мы должны разработать свою ОС
2. Я создаю некоторый обработчик команд (препроцессор), работающий с запросами системы в пределах ОДНОГО адресного пространства, что позволит значительно сократить затраты памяти и, соответственно, увеличить скорость работы приложений.
3. Сейчас разработка находится на стадии описания среды препроцессора. Есть кое-какие наработки в описании команд.

 

Сокращать затраты памяти совершенно неактуально.
1) По этой части система и так достаточно хорошо оптимизирована.
2) Если памяти не хватает, ее можно поставить больше. Гораздо более актуальна проблема адресного пространтва (решение которой - переход на 64)
3) Оптимизация требуется у такой части ос, как GDI. Имхо это единственная часть ос, где мы имеем реально дерьмовую производительность (хотя в практическом применеии обычно этой производительности оказывается достаточно)

Плохо представляю, с какими именно запросами и как должен работать твой обработчик. И как именно это должно поднять производительность. Приведи конкретный пример.

 

ПРИМЕР

сайт wasm.ru написан на PHP.

Для того, чтобы выполнить один php скрипт требуется запустить один процесс, если это в win32, то "php.exe" или "rundll32.exe php4ts.dll c script_name.php".

Каждый процесс занимает место в памяти.

Пользователей много, и поэтому коротких обращений к модулям PHP будет тоже не мало. PHP, как и любое приложение, оставляет после себя "мусор".

Естесственно, что время отклика от приложений сокращается...
------------------------------


ПРИМЕР2

СИСТЕМА ЗАЩИТЫ H A S P.

Этот пример для тех, кто работал с сетевой версией 1С

ПРИ ЗАШКАЛИВАНИИ ЧИСЛА ЗАПРОСОВ К СЕРВЕРУ, ОН ПРОСТО ВИСНЕТ!!!

Я собираюсь решить эти проблемы

 

А про модули апача ты что-нибудь слышал? Просто php надо ставить не кривыми руками, и не нужны будут никакае процессы.

Интересно, какой мусор может остаться после завершения процесса?

А в чем причина этого зависания? Имхо только в кривых руках разработчиков. Но тут ты врядли делу поможешь.

 

т.е. у тебя он будет однозначно совершенным? и в чем несовершенство существующего?

ага, формат РЕ виноват и дух билли гейтса, кто ж еще

 

Я как-нибудь опубликую первичную версию...

 

dev.xadmin

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

Хочешь поднять этим производительность?

PE386

В никсах гуя работает быстрее? Есть идеи по повышению производительности GDI?

 

Наоборот в разы медленее Но там это уже неизлечимая болзнь (т.к. гуи изначално задуман как сетевой), а вот в винде могли бы сделать и побыстрее. Надеюсь в висте эта часть уже будет оптимизирована.

 

Это ты про эмуляцию... У меня нет ресурсов времени на разработку чего-то большего, чем WinEMU.

 

)) Шутник. Оптимизировать сейчас никто не будет. Будут добавлять фичи, фенечки - но оптимизация? Какая оптимизация? На дворе 21 век, 4хядерные процессоры. Взгляни на системные требования висты.

 

Код (Text):

1. 144C:0090 52            PUSH    DX
2. 144C:0091 69            DB      69
3. 144C:0092 63            DB      63
4. 144C:0093 68            DB      68
5. 144C:0094 7174          JNO     010A
6. 144C:0096 58            POP     AX
7. 144C:0097 DA00                  FIADD   DWORD PTR [BX+SI]
8. 144C:0099 0000          ADD     [BX+SI],AL
9. 144C:009B 0000          ADD     [BX+SI],AL
10. 144C:009D 0000          ADD     [BX+SI],AL
11. 144C:009F 0000          ADD     [BX+SI],AL
12. 144C:00A1 0000          ADD     [BX+SI],AL
13. 144C:00A3 0000          ADD     [BX+SI],AL
14. 144C:00A5 0000          ADD     [BX+SI],AL
15. 144C:00A7 005045        ADD     [BX+SI+45],DL
16. 144C:00AA 0000          ADD     [BX+SI],AL
17. 144C:00AC 4C            DEC     SP
18. 144C:00AD 0104          ADD     [SI],AX
19. 144C:00AF 00D2          ADD     DL,DL

Это я про мусор, после выполнения PHP

 

IceStudent
Вроде как собирались сделать основным gdi-клиентом gdiplus, который, в свою очередь, реализовать через directx.

 

green
Это давно собирались, ещё когда gdiplus продвигать начали. Но затихло что-то.

dev.xadmin
Это ты откуда взял? В чём мусор?

 

Объясняю:

Если

1. создать некоторый сервис на Delphi (Извините, но на нём быстрее) с таймером, который через 300 секунд подключался бы к
HTTP://LOCALHOST:PORT/SCRIPT.PHP?KEY=value&KEY2=value2

2. Закрыть рабочий стол, панель задач, графику,

3. Отловить изменения в RAM в реальном времени

4. Записать лог

5. Перезагрузиться

6. Прочитать лог

то можно увидеть, что с 0090 по 0097 до запуска процесса было 0000, а через 300 сек. после этого - 52 69 63 68 и т.д

Это я к тому, что НЕЛЬЗЯ ИЗБАВИТЬСЯ ОТ СОДЕРЖИМОГО ПРОЦЕССА ПОЛНОСТЬЮ

Цитирую:

 

По этому адресу хранился дескриптор файла, который так и не был уничтожен полностью

 

что за бред? почитай сначала про процессы и потоки у того же рихтера

мда, тут, имхо, бесполезно что-то доказывать...