Board.KolibriOS.org

Official KolibriOS board
It is currently Mon Sep 28, 2020 6:11 pm

All times are UTC+03:00




Post new topic  Reply to topic  [ 32 posts ]  Go to page Previous 1 2 3 Next
Author Message
PostPosted: Mon Feb 04, 2013 5:45 pm 
Offline

Joined: Mon Sep 24, 2007 11:11 am
Posts: 2814
http://wiki.kolibrios.org/wiki/%D0%9A%D ... libriOS/ru
Я не ведущий разработчик, но не против иметь стандартные средства для stdin/stdout, а не эмулируемые в клиентском приложении. Однако, реализация должна быть "прозрачной" для желающих использовать стандартные потоки.


Top
   
PostPosted: Mon Feb 04, 2013 5:57 pm 
Offline

Joined: Fri Feb 18, 2011 3:13 pm
Posts: 201
SoUrcerer wrote:
Однако, реализация должна быть "прозрачной" для желающих использовать стандартные потоки.


Я этого не понял...


Top
   
PostPosted: Mon Feb 04, 2013 6:05 pm 
Offline

Joined: Mon Sep 24, 2007 11:11 am
Posts: 2814
Не должно быть много "магического" кода. Инициализация и работа с потоками должна быть логичной и простой.


Top
   
PostPosted: Mon Feb 04, 2013 6:11 pm 
Offline

Joined: Fri Feb 18, 2011 3:13 pm
Posts: 201
Ну, потоков это совершенно не касается. Реализация будет на уровень процессов - в рамках одного процесса, будет только одного набора консольных сокетов. Потоки будут создаваться и пользоваться как всегда.


Top
   
PostPosted: Mon Feb 04, 2013 7:23 pm 
Offline

Joined: Mon Sep 24, 2007 11:11 am
Posts: 2814
Я имею в виду потоки ввода-вывода - stdin, stdout


Top
   
PostPosted: Mon Feb 04, 2013 8:45 pm 
Offline

Joined: Fri Feb 18, 2011 3:13 pm
Posts: 201
Теперь понял. Работа с ввод/выводом будет весьма простая - через fn.75.6 (SocketSend) и через fn.75.7 (SockerReceive). Номера сокетов будут находится в заголовке приложения:
Новый заголовок будет вот такой:
Code:
      db 'MENUET01'
      dd $02                 ; New header version
      dd START
      dd I_END
      dd RESERVED
      dd STACK_PTR
pArg  dd 0
pPath dd 0
      ; IO socket numbers.
STDIO dd 0
ERRIO dd 0

Приложение будет запускаться через ф.70.7, а в файловой информационной структурой будут использоваться поля на смещения 12 и 16, которые теперь не используются.
То есть, структура будет:
Code:
struct __TFileOp7
  .subfunc     dd 7
  .flags       dd ?    ; 1 = start in debug mode
  .pArguments  dd ?
  .hSTDIO      dd ?     ; now it is reserved/not used
  .hSTDERR     dd ?     ; now it is reserved/not used
               db 0
  .pFileName   dd 0     ; pointer to the filename
ends


Last edited by johnfound on Mon Feb 04, 2013 11:08 pm, edited 1 time in total.

Top
   
PostPosted: Mon Feb 04, 2013 11:07 pm 
Offline

Joined: Fri Feb 18, 2011 3:13 pm
Posts: 201
А hidnplayr, придумал даже вариант проще - использовать последние две dword вот так:

Code:
      db 'MENUET01'
      dd $01
      dd START
      dd I_END
      dd RESERVED
      dd STACK_PTR
STDIO  dd ptrArgBuffer
STDERR dd ptrPathName


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


Top
   
PostPosted: Tue Feb 05, 2013 12:09 am 
Offline

Joined: Mon Sep 24, 2007 11:11 am
Posts: 2814
Не понял со вторым случаем. Как тогда можно понять, что программе кроме параметров передают что-то через stdin?


Top
   
PostPosted: Tue Feb 05, 2013 1:06 am 
Offline

Joined: Fri Feb 18, 2011 3:13 pm
Posts: 201
Параметры и вовсе не передаются через stdin. Ядро копирует эти параметры в буфере на ptrArgBuffer. Этот указатель нужен ядру только во время загрузки программы, а она и так знает где этот буфер находится. Поэтому, эта переменная не используется в программе. И поэтому, когда ядро скопирует параметры, то на самом месте, можно записать номер сокета для STDIN/OUT
То же самое относится и для ptrPathName.
А если процесс, который загружает программу не использует этот механизм (например старые программы), то в эти переменные загружаться нули. (это и единственный риск - если программа ожидает что там будут валидные адреса, а вдруг там появятся нули. Но вероятность для этого мала).


Top
   
PostPosted: Tue Feb 05, 2013 10:29 am 
Offline

Joined: Fri Feb 18, 2011 3:13 pm
Posts: 201
I will continue this discussion in English.

It seems we didn't guess one important issue, about the second approach. The dynamic libraries could use the fields pArg and pPath, because they can't know where these buffers are placed.


Top
   
PostPosted: Tue Feb 05, 2013 5:18 pm 
Offline
Mentor/Kernel Developer
User avatar

Joined: Fri Jun 30, 2006 9:01 am
Posts: 1276
I dont know of any library currently using those parameters, if they are needed the program can pass the path and arguments buffers easily.
There is also the option of using some of the other available bytes/dwords.

_________________
"Any intelligent fool can make things bigger, more complex, and more violent. It takes a touch of genius -- and a lot of courage -- to move in the opposite direction." Albert Einstein


Top
   
PostPosted: Tue Feb 05, 2013 6:17 pm 
Offline

Joined: Fri Feb 18, 2011 3:13 pm
Posts: 201
(+) So, no compatibility will be broken.
(-) But, some (hypothetical) features will be lost.
(+) A new entities header will not be introduced.

So, the balance is positive... I'll make it this way.

BTW: How I should work on this task? I already checked out the kernel sources and I probably must work on network branch... Or maybe I have to fork another branch...
Should I send a patches to someone or the workflow is different...
Sorry, but I have experience only with DVCS, where these things are more liberal.


Top
   
PostPosted: Tue Feb 05, 2013 7:16 pm 
Offline
Mentor/Kernel Developer
User avatar

Joined: Fri Jun 30, 2006 9:01 am
Posts: 1276
johnfound wrote:
BTW: How I should work on this task? I already checked out the kernel sources and I probably must work on network branch... Or maybe I have to fork another branch...
Should I send a patches to someone or the workflow is different...
Sorry, but I have experience only with DVCS, where these things are more liberal.


Applying the proposed patch to network branch makes sense to me.
You just need write access to SVN and then you theroretically can do what you want ;)

_________________
"Any intelligent fool can make things bigger, more complex, and more violent. It takes a touch of genius -- and a lot of courage -- to move in the opposite direction." Albert Einstein


Top
   
PostPosted: Tue Feb 05, 2013 8:25 pm 
Offline
Mentor/Kernel Developer
User avatar

Joined: Fri Jun 30, 2006 9:01 am
Posts: 1276
I have added the socketpair function to the net kernel.
The code however is untested because I dont feel like writing the application for it right now.

I am however, pretty confident that nothing will explode.

_________________
"Any intelligent fool can make things bigger, more complex, and more violent. It takes a touch of genius -- and a lot of courage -- to move in the opposite direction." Albert Einstein


Top
   
PostPosted: Sun Feb 10, 2013 12:00 am 
Offline
Mentor
User avatar

Joined: Tue Jan 15, 2008 11:27 am
Posts: 756
I didn't understand about compability with old programs. May be it is advisable to use some magic constant.

Code:
      db 'MENUET01'
      dd $02                 ; New header version
      dd START
      dd I_END
      dd RESERVED
      dd STACK_PTR
pArg  dd 0
pPath dd 0
  MAGIC dd 0x12345; <---- Some magic constant
      ; IO socket numbers.
STDIO dd 0
ERRIO dd 0


Top
   
Display posts from previous:  Sort by  
Post new topic  Reply to topic  [ 32 posts ]  Go to page Previous 1 2 3 Next

All times are UTC+03:00


Who is online

Users browsing this forum: No registered users and 4 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
Powered by phpBB® Forum Software © phpBB Limited