stormdos-develop Mailing List for SD (StormDos) (Page 2)
Status: Planning
Brought to you by:
exhu
Menu
▾
▴
stormdos-develop — Developers' quick discussion mailing list
You can subscribe to this list here.
| 2004 |
Jan
(1) |
Feb
|
Mar
|
Apr
(10) |
May
(7) |
Jun
|
Jul
(5) |
Aug
|
Sep
(6) |
Oct
(2) |
Nov
(2) |
Dec
(1) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2005 |
Jan
|
Feb
(1) |
Mar
(1) |
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|
From: Juras <yb...@tu...> - 2004-04-28 16:04:11
|
Hello stormdos-develop, syscalls list and sdapi.pas changed, device engine significantly changed... and commited to CVS -- Best regards, Juras mailto:yb...@tu... |
|
From: Juras <yb...@tu...> - 2004-04-23 17:55:44
|
Hello Kohut,
Friday, April 23, 2004, 2:29:30 PM, you wrote:
KI> I have translated your ideas to HTML. See attachment. Send comments.
Good job!!! Thanks! Especially the LOGO!!!
As for the rest of design, I'll think it over and menu highlighting is a bit buggy in Mozilla...
I think it's early to publish any sophisticated WWW site now, because
nothing user-interesting is implemented yet. But the logo is very
good, i'll try to experiment on it, if you don't mind. (all copyright
I'll address to you, of course ;) And it's a good useable sketch now I
see it clear.
Do you experience any problems with the stormdos-develop mailing-list?
I've commited some more changes to device engine through the CVS. Try to
use anonymous CVS access and download the module sd32_fpc . Pay
attention to modules.txt in doc subdir and kcontext.pas.
Please, send any feedback on whether you've succeeded in downloading
through CVS and whether you looked thorough kcontext.pas unit's interface
part.
And, I think it'll be more consistent to commit all changes to the CVS
through me.
Think over PE image-manipulation unit - no FILE I/O but
manipulation via CALLBACK functions for FILE I/O
i.e.
const
// file operation number
PE_FO_OPEN=1;
PE_FO_CLOSE=2;
PE_FO_READ=3;
...
type
TFOREADPARAMS=record
dest_ptr:pointer;
bytes_to_read:DWORD;
end;
TFILEIOPROC=function(opcode:DWORD;params:pointer):INT;
PPEIMAGE=^TPEIMAGE;
TPEIMAGE=record
imagep:pointer;
fileproc:TFILEIOPROC;
...
end;
function initimage(fileproc:TFILEIOPROC;peimg:PPEIMAGE):INT;
function loadheaders_and_sections_info(peimg:PPEIMAGE):INT;
function map_at(peimg:PPEIMAGE;base_addr:DWORD):INT; // provides
FIXING-UP, relocation etc.
...
Be aware that NO CLASS/OBJECTS, no standard memory
allocation/deallocation functions are available!!!
--
Best regards,
Juras mailto:yb...@tu...
|
|
From: Juras <yb...@tu...> - 2004-04-18 18:30:38
|
Hello stormdos-develop, kdrvdev.pas and todo.txt now modified. kdrvdev's CONST part is modified to provide new driver model... -- Best regards, Juras mailto:yb...@tu... |
|
From: Juras <yb...@tu...> - 2004-04-16 20:03:41
|
Hello Stephane, Friday, April 16, 2004, 7:58:54 PM, you wrote: SR> a bit of research as I don't fully know what I'm doing on that side, but I'd SR> be happy to find the info and make it happen :-). look at www.osdever.net - they have enough stuff there. And, please, answer - have you managed to download via CVS client the recent sources of SD ? I think there's no need to put sources via individual CVS connection, but you may send your corrections or units to me and I may commit them to CVS. Or you may post your SSH key (see SF.NET docs etc.) and use CVS... -- Best regards, Juras mailto:yb...@tu... |
|
From: Juras <yb...@tu...> - 2004-04-16 16:18:24
|
Hello Stephane, Friday, April 16, 2004, 6:05:05 PM, you wrote: SR> probably do need somekind of garbage collection model. it's rather simple with separate address spaces etc. so no model needs implementing, I think. -- Best regards, Juras mailto:yb...@tu... |
|
From: Juras <yb...@tu...> - 2004-04-16 13:48:32
|
Hello stormdos-develop,
EXECUTABLES AND DLLs HANDLING SKETCH:
[THREAD]
fs_current_dir
next_sibling_thread (the threads of one app are called "siblings" here)
app_handle ("parent" application)
[APPLICATION]
fs_opened_files_list
page_directory_object
threads_count
main_thread
module_handle
should we need heap_support here?
[MODULE] (a lot of modules for every application)
image_handle
dll_modules (MODULEs used as DLLs and needed by this module i.e. dependencies)
[IMAGE] (usually only one, at least for system DLLs)
reference_counter (how many MODULES use this image)
file_path
image_filename
template_ptr (if it's cached then it won't be loaded from a file but from memory instead)
dlls_needed (names of DLLs)
------------------
Execution process:
#find allocated image with that name:
if no then load and register, enumerate needed DLLs;
else increment image.reference_counter
#allocate module
- load image
- call #allocate module(module.image_handle.next_dll)
-------------------
Shutdown process:
#freemodule(module)
decrement image reference
free memory used by module using specified PAGEDIR
call #freemodule(next_dll)
--
Best regards,
Juras mailto:yb...@tu...
|
|
From: Juras <yb...@tu...> - 2004-04-15 16:42:24
|
Hello Stephane, Thursday, April 15, 2004, 7:24:33 PM, you wrote: SR> This is a test reply :-)....make sure all works good. SR> I like what I've read in there Juras, I like that device model...I think it SR> can make a good basis for everything else that might need a driver as well. Good! I'll start implementing it. BTW, will you implement a FAT12 filesystem driver? I can do it as I have some kind of practice in FAT driver development but I'm going to write a Floppy driver. But the second thing we need now is module handling, image relocation and other stuff with executables. I plan the model, then send it here and Ivan Kohut agreed to develop a part of kernel responsible for PE Images manipulation. BTW, ARE YOU ABLE TO DOWNLOAD THE RECENT CVS ? (using anonymous) -- Best regards, Juras mailto:yb...@tu... |
|
From: Stephane R. <sri...@to...> - 2004-04-15 16:26:32
|
This is a test reply :-)....make sure all works good. I like what I've read in there Juras, I like that device model...I think = it can make a good basis for everything else that might need a driver as wel= l. St=E9phane Richard Software Developer ----- Original Message -----=20 From: "Juras" <yb...@tu...> To: "stormdos-develop" <sto...@li...> Sent: Wednesday, April 14, 2004 8:20 AM Subject: [Stormdos-develop] NEW DRIVERS/DEVICES MODEL and test > Hello stormdos-develop, > > Post to this mail list for test purpose. > > New: DRIVERS/DEVICES model > > Drivers register virtual devices. > > a device may be of various types (and are handled as separate arrays to maximize search speed): > > - character and block > - volume (which can be mapped as disk c:, d: etc. i.e. it may be referenced in the path, has FS) > - special (no file i/o, invisible to user FS functions) > - file system (invisible to user file functions) > * aliases and substitutes - respect to every category > > An alias is a device which really refers to the same functionality devi= ce > but with another name. e.g. C: is a real volume and c: refers to C: and= is an alias. > > A substitute is a device which doesn't directly correspond to another o= ne but > sends modified requests to a linked device. e.g. G: is a substituted volume, it > modifies requests' path name to be C:\myrefdir\sss\... > > A volume is a device which accepts file IO operations and serves as a basis, > e.g. C:\mypath\myfile.txt > It has a block and file system devices attached. > > A file system device has nothing downward attached, it is used by volum= es. > > A block device has nothing downward attached, it is used by volumes and supports > I/O operations. > > A character device is almost the same as a block device but can't conta= in a file system. > > > A FS layer may operate on volumes and character/block devices only. > If a path contains a colon or slahes then only volumes are operated. > > > 1) initialize FS drivers (they simply register devices) > 2) initialize block/char drivers > 3) automount all block devices which can contain a FS > > > ---------------------- > > All devices could be sent a FLUSH request when closing the kernel etc. > > > Character device requests: > > 1) handle=3Dopen() > 2) close() > 3) eof() > 4) filelength > 5) read > 6) write > 7) flush > 8) seek > > Block device requests: > > 1) handle=3Dopen() > 2) close() > 3) eof > 4) blocks_count > 5) readblock > 6) writeblock > 7) readblocks > 8) writeblocks > 9) seek_block > 10) eof > 11) [format] > 12) block_dev_info > > Volume device requests (mainly resends them to FS device, serves as a named filter/router): > > 1) fhandle=3Dfile_open > 2) file_close > 3) file_seek > 4) file_read > 5) file_write > 6) file_eof > 7) file_findfirst > 8) file_findnext > 9) file_rename > 10) file_move > 11) file_delete > 12) file_info > 13) volume_info > 14) volume_changed > 15) volume_remount > > File system device requests: > > 0) handle=3Dmount(blockdev) > 1) fhandle=3Dfile_open > 2) file_close > 3) file_seek > 4) file_read > 5) file_write > 6) file_eof > 7) file_findfirst > 8) file_findnext > 9) file_rename > 10) file_move > 11) file_delete > 12) file_info > 13) volume_info > 14) unmount(handle) > > --=20 > Best regards, > Juras mailto:yb...@tu... > > > > ------------------------------------------------------- > This SF.Net email is sponsored by: IBM Linux Tutorials > Free Linux tutorial presented by Daniel Robbins, President and CEO of > GenToo technologies. Learn everything from fundamentals to system > administration.http://ads.osdn.com/?ad_id=3D1470&alloc_id=3D3638&op=3Dc= lick > _______________________________________________ > Stormdos-develop mailing list > Sto...@li... > https://lists.sourceforge.net/lists/listinfo/stormdos-develop |
|
From: Juras <yb...@tu...> - 2004-04-14 12:19:29
|
Hello stormdos-develop, Post to this mail list for test purpose. New: DRIVERS/DEVICES model Drivers register virtual devices. a device may be of various types (and are handled as separate arrays to maximize search speed): - character and block - volume (which can be mapped as disk c:, d: etc. i.e. it may be referenced in the path, has FS) - special (no file i/o, invisible to user FS functions) - file system (invisible to user file functions) * aliases and substitutes - respect to every category An alias is a device which really refers to the same functionality device but with another name. e.g. C: is a real volume and c: refers to C: and is an alias. A substitute is a device which doesn't directly correspond to another one but sends modified requests to a linked device. e.g. G: is a substituted volume, it modifies requests' path name to be C:\myrefdir\sss\... A volume is a device which accepts file IO operations and serves as a basis, e.g. C:\mypath\myfile.txt It has a block and file system devices attached. A file system device has nothing downward attached, it is used by volumes. A block device has nothing downward attached, it is used by volumes and supports I/O operations. A character device is almost the same as a block device but can't contain a file system. A FS layer may operate on volumes and character/block devices only. If a path contains a colon or slahes then only volumes are operated. 1) initialize FS drivers (they simply register devices) 2) initialize block/char drivers 3) automount all block devices which can contain a FS ---------------------- All devices could be sent a FLUSH request when closing the kernel etc. Character device requests: 1) handle=open() 2) close() 3) eof() 4) filelength 5) read 6) write 7) flush 8) seek Block device requests: 1) handle=open() 2) close() 3) eof 4) blocks_count 5) readblock 6) writeblock 7) readblocks 8) writeblocks 9) seek_block 10) eof 11) [format] 12) block_dev_info Volume device requests (mainly resends them to FS device, serves as a named filter/router): 1) fhandle=file_open 2) file_close 3) file_seek 4) file_read 5) file_write 6) file_eof 7) file_findfirst 8) file_findnext 9) file_rename 10) file_move 11) file_delete 12) file_info 13) volume_info 14) volume_changed 15) volume_remount File system device requests: 0) handle=mount(blockdev) 1) fhandle=file_open 2) file_close 3) file_seek 4) file_read 5) file_write 6) file_eof 7) file_findfirst 8) file_findnext 9) file_rename 10) file_move 11) file_delete 12) file_info 13) volume_info 14) unmount(handle) -- Best regards, Juras mailto:yb...@tu... |
|
From: Juras <yb...@tu...> - 2004-04-10 15:23:53
|
Hello stormdos-develop, I'm happy to announce that CVS repository is filled in today!!!!!!!! Try checking out "sd32_fpc" module. Also, please everyone whom I sent this letter - visit https://lists.sourceforge.net/lists/listinfo/stormdos-develop -- Best regards, Juras mailto:yb...@tu... |
|
From: Mamoru a. C. <ma...@bi...> - 2004-01-19 06:36:37
|
_______________________________________________________________ =CF=EE=F1=EC=EE=F2=F0=E8 =EA=E0=EA=E8=EC =ED=EE=E2=EE=E3=EE=E4=ED=E8=EC =F1= =F2=E0=EB www.bigmir.net :) |
