stormdos-develop Mailing List for SD (StormDos)
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...> - 2005-03-28 18:14:58
|
It's in C now (OpenWatcom, www.openwatcom.org) and I keep site up-to-date for Russian-speaking community (exUSSR users who understand Russian) at http://www.stormdos.nm.ru . The work is suspended because I have extremely heavy schedule in the university and unable to devote my free time for amateur projects. You can download the latest published version (14 march, 2005) at http://www.stormdos.nm.ru/files/sd32/sd32_c3c_7D530E146CA.7z Use www.7-zip.org free archiver to unpack the sources. Don't worry, all docs, comments etc. provided in the archive are in English and they will be in English, for Russian is not my native language. The archive is not new. The most recent (27 march, 2005) sources and docs still reside on my home PC and will be published as soon as I have time. Just a few points from history.txt: 27 march 2005 - docs/msgport.txt - new drivers interface 18 march 2005 - started drivers and devices subsystems 17 march 2005 - fixed VM86, now it is developed to support all-ring-3 model, i.e. it cannot be used from ring0 !!! 16 march 2005 - fixed bug in sduser2.c - fixed bug in mutex.c - mutex is again working!!!!!!!!!!!! 15 march 2005 - new bug in mutex found, but not eliminated !!! - started writing API: sdu_*, sdu2_* |
|
From: Juras <yb...@tu...> - 2005-02-27 20:59:07
|
Hello! Зацените обновленную версию сайта. Выскажитесь, пожалуйста, в новом форуме. http://www.stormdos.nm.ru -- Best regards, Juras mailto:yb...@tu... |
|
From: Juras <yb...@tu...> - 2004-12-21 22:15:32
|
Hello stormdos-develop, Memory management in SD-32-C2 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Designed by Yury Benesh 22 December, 2004 Virtual memory addressing is used where each process uses 4 GiB address space which doesn't correspond to equal physical addresses. A part of PAGE DIRECTORY describing PAGE TABLES for the first 2 GiB are copied among all address spaces/processes/applications. Next 2 GiBs are private to all processes. While the first 1 GiB of it is for application addresses ( EXEcutable image, heap, dynamic memory etc. ) and higher 1 GiB is for DLLs. Memory addresses are controled via linked lists which can occupy more memory when the allocated block is insufficient for adding new free memory region structure. A memory block is allocated and measured by 4 KiB pages. There's one global linked list for describing lowest 2 GiB ( also called system/kernel memory region ) - through these addresses all system structures and page tables are accessed. It is also can be used by drivers. There is a linked lists for each process/application to control its private memory region. There is also one global linked list to control free addresses in the upper memory for DLLs. The hierarchy: THE LOWEST LAYER OF THE MEMORY MANAGER -------------------------------------- - get physical page ( DOS, DMA, HIGH, ANY ) - fill the page directory - reserve pages ( bit 11 of table entries is used to mark non-present but reserved pages ) - alloc table - add/remove free blocks ( adds memory addresses to the global list of free 0..2 GiB addresses ) - set pages addr, flags THE MIDDLE/DRIVER LAYER ----------------------- - allocate/free ( DOS, DMA, HIGH, ANY) block of pages - returns ready virtual address - reserve tables and/or directory entries in the range of the kernel memory region for storing page tables in adjacent addresses ( removes addresses from the global list of free 0..2 GiB addresses ) - map physical page to linear ( involves allocation of physical pages for the reserved tables if needed ) THE TOP/APP LAYER ----------------- - allocate/free heap ( in 4 KiB ) - allocate/free block of bytes in the heap -- Best regards, Juras mailto:yb...@tu... |
|
From: Juras <yb...@tu...> - 2004-11-07 12:55:16
|
Hello stormdos-develop, 7 nov update, sources, docs, specs at http://stormdos.sourceforge.net -- Best regards, Juras mailto:yb...@tu... |
|
From: Juras <yb...@tu...> - 2004-11-06 18:54:44
|
Hello stormdos-develop, Processes are: 1) kernel (starter, the first thread which loads shell etc. - it has limited address space, because it is then shared to all processes) 2) drivers 3) applications Processes are characterized by their own address space, but sharing kernel address space and having some addresses reserved by DLLs. Drivers are executed at 0 priviledge level. Each driver executes on its own address space and has at least one thread. Applications use drivers by sending messages. Memory sharing (for drivers to be able to write to it) is provided by the kernel in the following way: 1) application registers a memory handle with BASE and SIZE in the address space of the process. (the kernel translates it into physical BASE and SIZE) 2) drivers get this handle via a message and LOCK it, the kernel allocates pages mapped to the physical ones specified by the handle. 3) drivers unlock it. 4) application unregister the handle. ----------------------------------- 1) one TSS for kernel/app/drivers/vm86 and software multi-tasking (stack-based) 2) TSSes for exceptions -- Best regards, Juras mailto:yb...@tu... |
|
From: Juras <yb...@tu...> - 2004-10-27 19:41:20
|
Hello stormdos-develop,
== execs.txt ===
SD-32 Multitasking and modules
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
The main item used for multi-tasking is called a CONTEXT.
The context belongs to a PROCESS. A process can countain
a lot of contexts. A process also makes so that the contexts
of the same project have the same address space. A process
maintains a list of used DLLs.
CONTEXTs->PROCESS->MAIN_MODULE_IMAGE_ID
USED_DLLs_IDs
Executables and DLLs are managed alike by the same
module manager. It registers unique DLLs and EXEs.
Then returns IDs to that modules incrementing the
reference counter of each. The module manager
allocates memory, makes fix-up and automatically loads
needed dependent modules and also makes all the
necessary clean-up.
Algorithm: function load_module()
1) check whether that module has not been loaded
- check if it is already used by the process,
a) if so - exit.
b) no - allocate structure
2) increase ref. counter, allocate memory, fix-up
3) enumerate dependencies, launch load_module for each
store dependencies IDs in the stucture
4) use loaded dependencies to make imports and exports meet
--
Best regards,
Juras mailto:yb...@tu...
|
|
From: Juras <yb...@tu...> - 2004-10-25 16:00:59
|
Hello stormdos-develop,
== console.txt ==
Input/output, file IO uses UTF-8.
console works also with UTF-8 but displays symbols
according to the mode limitations, i.e. in 80x25 VGA text mode
only 256 symbols could be displayed, so it uses DOS code page.
The "undisplayable" symbols are shown as question marks or
as magic sequences like #u0123 however the system doesn't actually uses
question marks...
Console buffer is probably encoded by 32-bit DWORDs
80*25*4=8kB - text data
+ 80*25=2kB - text attributes
= 10 kB
== mem.txt ==
Memory management in SD-32
~~~~~~~~~~~~~~~~~~~~~~~~~~
Designed with the usage of page translation mode of IA-32.
1) one list of free physical memory blocks
- the lowest layer
2) one list
[0, 80000000h) (2GiB)- shared addresses, "global memory" which points
to the same physical addresses in address spaces of every
context. This memory is allocated by the kernel for the kernel and
drivers use (maps video memory, keep system structures and everything
which must be accessed by the kernel being run withing the address
space of a context...)
3) per application (application has threads which share the same address space)
list of free virtual addresses in the range of
[80000000h, C0000000) (1GiB)- memory used by process (application), i.e.
where the executable image is loaded and relocated.
4) one list of free virtual addresses in the range of
[C0000000, FFFFFFFF] (1GiB)- addresses for DLLs. We need this region separated
because when any application loads a DLL we must provide the ability
for the rest of applications running or which will be run later to
use the same addresses for the same DLL attached to a new process.
Memory maps for 3) and 4) map their SHARED and READ-ONLY sections to
the same physical addresses (like in MS Windows).
FUNCTIONS
~~~~~~~~~
AllocPhysical - allocates only continuous blocks
ReallocPhysical - reallocates only continuous blocks
FreePhysical
AllocVirtual - allocates only addresses (continuous)
ReallocVirtual
FreeVirtual
MapAddresses - uses allocated page dir to map addresses to physical
DisableAddresses - uses allocated page dir to mark pages as unpresent.
AllocVirtualPhys - allocates physical memory and virtual addresses
and modifies page directory.
underlying physical memory may be
fragmented.
ReallocVirtualPhys - underlying physical memory may be fragmented
FreeVirtualPhys
== sysint.txt ===
Kernel Syscalls
~~~~~~~~~~~~~~~
The system interrupt doesn't make a context switch - it executes
using PDBR of the caller. Hence it runs in the address space
of the caller. The kernel function is called with interrupts disabled
however another system call can be running in the context of
another thread. That is why the kernel must be
- thread-safe, provide locking mechanism
- interruptable
- share the same addresses for its memory inspite of the current
thread address space (see mem.txt point#2 )
--
Best regards,
Juras mailto:yb...@tu...
|
|
From: Juras <yb...@tu...> - 2004-09-12 11:13:10
|
Hello stormdos-develop,
New version:
Memory management in SD-32
~~~~~~~~~~~~~~~~~~~~~~~~~~
Designed with the usage of page translation mode of IA-32.
1) one list of free physical memory blocks
- the lowest layer
2) one list
[0, 80000000h) - shared addresses, "global memory" which points
to the same physical addresses in address spaces of every
context. This memory is allocated by the kernel for the kernel and
drivers use (maps video memory, keep system structures and everything
which must be accessed by the kernel being run withing the address
space of a context...)
3) per application (application has threads which share the same address space)
list of free virtual addresses in the range of
[80000000h, C0000000) - memory used by process (application), i.e.
where the executable image is loaded and relocated.
4) one list of free virtual addresses in the range of
[C0000000, FFFFFFFF] - addresses for DLLs. We need this region separated
because when any application loads a DLL we must provide the ability
for the rest of applications running or which will be run later to
use the same addresses for the same DLL attached to a new process.
Memory maps for 3) and 4) map their SHARED and READ-ONLY sections to
the same physical addresses (like in MS Windows).
FUNCTIONS
~~~~~~~~~
AllocPhysical - allocates only continuous blocks
ReallocPhysical - reallocates only continuous blocks
FreePhysical
AllocVirtual - allocates only addresses (continuous)
ReallocVirtual
FreeVirtual
MapAddresses - uses allocated page dir to map addresses to physical
DisableAddresses - uses allocated page dir to mark pages as unpresent.
AllocVirtualPhys - allocates physical memory and virtual addresses
and modifies page directory.
underlying physical memory may be
fragmented.
ReallocVirtualPhys - underlying physical memory may be fragmented
FreeVirtualPhys
--
Best regards,
Juras mailto:yb...@tu...
|
|
From: Juras <yb...@tu...> - 2004-09-12 09:29:59
|
Hello stormdos-develop, Kernel Syscalls ~~~~~~~~~~~~~~~ The system interrupt doesn't do context switch - it executes using PDBR of the caller. Hence it runs in the address space of the caller. The kernel function is called with interrupts disabled however another system call can be running in the context of another thread. That is why the kernel must be - thread-safe, provide locking mechanism - interruptable - share the same addresses for its memory inspite of the current thread address space (see mem.txt) -- Best regards, Juras mailto:yb...@tu... |
|
From: Juras <yb...@tu...> - 2004-09-12 09:29:58
|
Hello stormdos-develop, Memory management in SD-32 ~~~~~~~~~~~~~~~~~~~~~~~~~~ Designed with the usage of page translation mode of IA-32. 1) one list of free physical memory blocks - the lowest layer 2) one list [0, 80000000h) - shared addresses, "global memory" which points to the same physical addresses in address spaces of every context. This memory is allocated by the kernel for the kernel and drivers use (maps video memory, keep system structures and everything which must be accessed by the kernel being run withing the address space of a context...) 3) per application (application has threads which share the same address space) list of free virtual addresses in the range of [80000000h, C0000000) - memory used by process (application), i.e. where the executable image is loaded and relocated. 4) one list of free virtual addresses in the range of [C0000000, FFFFFFFF] - addresses for DLLs. We need this region separated because when any application loads a DLL we must provide the ability for the rest of applications running or which will be run later to use the same addresses for the same DLL attached to a new process. Memory maps for 3) and 4) map their SHARED and READ-ONLY sections to the same physical addresses (like in MS Windows). -- Best regards, Juras mailto:yb...@tu... |
|
From: stephane r. <sri...@to...> - 2004-09-09 13:04:52
|
See my comments preceded by a *** distributed amongst your post. ----- Original Message ----- From: "Juras" <yb...@tu...> To: "stormdos-develop" <sto...@li...> Sent: Thursday, September 09, 2004 7:41 AM Subject: [Stormdos-develop] OPM > Hello stormdos-develop, > > By now BIOS calling from 32-bit PM works. Now the problem point is > PAGIN MECHANISM which affects DLLs much... I don't want use > complicated memory management, especially on an OS which is planned to > be launched from a floppy... > > > Please, tell you point of view to the following: > > proposed: > > Object Provider Modules > ~~~~~~~~~~~~~~~~~~~~~~ > > Instead of DLLs a special means could be implemented. > OPM is a usual programme with the following exceptions: *** OPM? you mean Overlayed Program Modules ? if so, well To me overlays are there because of the classic conventional memory limitations, a limit we don't have in a 32 bit environment. So I would suggest simple flat memory addressing model would do the same thing probably much faster and smaller. If you don't mean Overlayed Program Modules then for the sake of my knowledge, let me know what OPM is? :-). > > - loaded only once > - doesn't have own threads > - registers virtual objects with methods (COM-like) (records with > pointers to functions/procedures) > > SD-32 uses the same address space for all threads and this way provides > reusable code via near 32-bit calls (like in good old DOS INTerrupts > were used). > > OPM file name 8.3 limitation. > OPM object name - 63 symbols limitation, > several limitations to character range. > *** Here I have an issue, a 32 bit (or 64 bit even on some systems today) should have NO limitations per se. Other than system resources of course (assuming there will be no disk swapping). Therefore if we could find perhaps a tad more complicated method, a bit bigger that can still fit on a floppy disk that would get rid of these limitations (or at least raise these limits to higher values) I would opt for that option. A bit longer to code, perhaps, but I would think well worth it. > > Page addressing may be used just to protect areas of memory > and could be easily switched off. No "shared" regions, i.e. > the same page directory is used for all processes. > *** That I'm all for it exactly as described here. > Page addressing (virtual memory) complicates the kernel much, so > I want to use usual programmes as interface providers (OPM) and with > a quite difference to call them OPMs rather than DLLs... > *** And how would that end up managing the memory? IE garbage collection, defragmentation of fragmented memory blocks (if any), and limits of installed RAM on a given system. Likewise if these don't manage the memory itself, then what happens? > Of course, DLLs are better but I don't want to get a headake implementing > them fully. > > With OPMs programmes can be highly modular and the memory being economized > as with the DLLs... > > Finally, OPMs are better than no dynamic linking at all ;) > *** well of course they are :-). I'm thinking however, if we do decide to go the DLL way, perhaps we could make use of existing DLL's hence make Storm DOS compatible with existing OS. That might be a big feature that just might get popular fast. > -- > Best regards, > Juras mailto:yb...@tu... > > > > ------------------------------------------------------- > This SF.Net email is sponsored by BEA Weblogic Workshop > FREE Java Enterprise J2EE developer tools! > Get your free copy of BEA WebLogic Workshop 8.1 today. > http://ads.osdn.com/?ad_id=5047&alloc_id=10808&op=click > _______________________________________________ > Stormdos-develop mailing list > Sto...@li... > https://lists.sourceforge.net/lists/listinfo/stormdos-develop |
|
From: Juras <yb...@tu...> - 2004-09-09 12:42:32
|
Hello stormdos-develop, By now BIOS calling from 32-bit PM works. Now the problem point is PAGIN MECHANISM which affects DLLs much... I don't want use complicated memory management, especially on an OS which is planned to be launched from a floppy... Please, tell you point of view to the following: proposed: Object Provider Modules ~~~~~~~~~~~~~~~~~~~~~~ Instead of DLLs a special means could be implemented. OPM is a usual programme with the following exceptions: - loaded only once - doesn't have own threads - registers virtual objects with methods (COM-like) (records with pointers to functions/procedures) SD-32 uses the same address space for all threads and this way provides reusable code via near 32-bit calls (like in good old DOS INTerrupts were used). OPM file name 8.3 limitation. OPM object name - 63 symbols limitation, several limitations to character range. Page addressing may be used just to protect areas of memory and could be easily switched off. No "shared" regions, i.e. the same page directory is used for all processes. Page addressing (virtual memory) complicates the kernel much, so I want to use usual programmes as interface providers (OPM) and with a quite difference to call them OPMs rather than DLLs... Of course, DLLs are better but I don't want to get a headake implementing them fully. With OPMs programmes can be highly modular and the memory being economized as with the DLLs... Finally, OPMs are better than no dynamic linking at all ;) -- Best regards, Juras mailto:yb...@tu... |
|
From: Juras <yb...@tu...> - 2004-09-01 05:27:39
|
Hello! I've managed to use VM86 task to call BIOS and redirecting IRQ into VM86 tasks... IT'S GREAT!!! Now it is not a problem to use BIOS services to access floppy, hard drives, VGA, VBE (for 1024x768x32bit etc. graphics), power management... Calling BIOS in protected mode is a very important and extremely useful feature! Now I'm cleaning the sources and adding comments. I also should say that this is not a main branch of SD-32 sources but an experimental and simple, hence I don't put it into the CVS. I'll put the sources as soon as I finish cleaning them ;) -- Best regards, Juras mailto:yb...@tu... |
|
From: Juras <yb...@tu...> - 2004-07-27 21:27:57
|
Hello Ivan, See new ver. of SD-32 specs, pretty much info added: http://stormdos.sourceforge.net/specification_alpha0_81.htm -- Best regards, Juras mailto:yb...@tu... |
|
From: Juras <yb...@tu...> - 2004-07-25 11:42:54
|
Hello stormdos-develop, I'm working now at genutils package, I found Fixed-length and Variable length Linked lists needed for SD-32 kernel... -- Best regards, Juras mailto:yb...@tu... |
|
From: Juras <yb...@tu...> - 2004-07-20 17:21:06
|
Hello stormdos-develop, StormDos has a good forum at: http://board.sysbin.com/viewforum.php?f=16 You're welcome!!! -- Best regards, Juras mailto:yb...@tu... |
|
From: Juras <yb...@tu...> - 2004-07-17 12:35:10
|
Hello stormdos-develop, New specification v0.8 was uploaded, see http://stromdos.sf.net -- Best regards, Juras mailto:yb...@tu... |
|
From: Juras <yb...@tu...> - 2004-07-06 21:02:55
|
Hello stormdos-develop,
I've succeeded in my summer examination session (6 exams, uhfff!)
and ready to continue work for SD community ;)
I'm eager to use basic OOP via Pascal Objects (I don't mean standard units like
"objects" and any part of *Vision or Delphi classes).
We should not use extensively OOP where it is needed and where not.
We'd better write not a very clean, understandable mixed code but provide
extensive comments...
Well, OOP is good to define abstract layers
(memory or file mappings, linked lists, modules, image executables
etc.).
Now I work at "genutils" units, then I want to write a nice PE-Image
manipulating library, which will be able to relocate/fix-up images,
join sections, report imports/exports.
Then I want to write a utility which will convert
our kernel compiled as PE-Image into a MultiBoot plain image with
the neccesary header, so that we shall not need ELF-tools and Linux
target any more...
In basic units (my genutils) I'll implement abstract classes
OBaseObject (actually only with a virtual destructor) and OGenStream
to map any IO-related stuff to memory/buffer/driver data/file etc.
I also selected a modificated code style, i.e. the way to name variables and
functions, which I practise in my C++ programmes,
see:
===codestyle.txt===
CODE STYLE SAMPLE
~~~~~~~~~~~~~~~~~
typename
GlobalFunctionName()
gGlobalVariableName
mMemberName
methodName
local_function_name (which is not declared in Interface)
local_variable_name
g_local_variable_name (not declared in Interface, but global for the implementation part)
argument_variable_name
TTypeName
CClassName
OObjectName
PPointerTypeName
CONSTANT_NAME
DEFINE_NAME
pPointerVariable
p_pointer_variable
rVariableReference
r_argument_reference
r_local_reference
MLCC_TTypeName
MLCC_Function
while (condition)
if (condition)
enum TMyEnum
{
tmeEnumOption, tmeEnumOption2
}
Global Functions names:
ObjectAction
e.g. CursorDraw, FileOpen, FileClose...
===EOF codestyle.txt===
We've got a rather rainy and cool summer in Belarus :( So I have to spend almost
every day at home... :(
--
Best regards,
Juras mailto:yb...@tu...
|
|
From: <ben...@id...> - 2004-05-25 08:20:26
|
Dear Open Source developer I am doing a research project on "Fun and Software Development" in which I kindly invite you to participate. You will find the online survey under http://fasd.ethz.ch/qsf/. The questionnaire consists of 53 questions and you will need about 15 minutes to complete it. With the FASD project (Fun and Software Development) we want to define the motivational significance of fun when software developers decide to engage in Open Source projects. What is special about our research project is that a similar survey is planned with software developers in commercial firms. This procedure allows the immediate comparison between the involved individuals and the conditions of production of these two development models. Thus we hope to obtain substantial new insights to the phenomenon of Open Source Development. With many thanks for your participation, Benno Luthiger PS: The results of the survey will be published under http://www.isu.unizh.ch/fuehrung/blprojects/FASD/. We have set up the mailing list fa...@we... for this study. Please see http://fasd.ethz.ch/qsf/mailinglist_en.html for registration to this mailing list. _______________________________________________________________________ Benno Luthiger Swiss Federal Institute of Technology Zurich 8092 Zurich Mail: benno.luthiger(at)id.ethz.ch _______________________________________________________________________ |
|
From: Juras <yb...@tu...> - 2004-05-16 14:03:59
|
Hello stormdos-develop, I'm very happy because today the following was implemented: - devices engine seems to be finished - system calls mechanism through INT instruction - more that 16 IRQs may be supported in the future (Advanced PIC) - SDK was revised... and many minor bug fixes and optimizations - CVS repository at sf.net was updated Now I'll test the devices engine and finish up some basic device drivers, write basic console driver etc. Then file system-related part will be the last thing to implement before we are able to load and start programmes. -- Best regards, Juras mailto:yb...@tu... |
|
From: Juras <yb...@tu...> - 2004-05-16 08:48:59
|
Hello stormdos-develop, well, I found some time ;) Now, devices engine (DRIVER API - kdrvdev.pas) has functions to provide thread-safety: a mutex - drv_wait_mutex(), drv_release_mutex() functions were implemented Thread-safety is needed in case a driver uses multithreading to handle all the requests - driver engine is not a shared resource, i.e. the functions are not reentrant! -- Best regards, Juras mailto:yb...@tu... |
|
From: Juras <yb...@tu...> - 2004-05-15 13:27:48
|
Hello stormdos-develop, I'm afraid I'll have no time for SD-32 during the rest of May, June and the beginning of July because I have a rather long examination session at the university. So feel free to manipulate with the sources, experiment etc. -- Best regards, Juras mailto:yb...@tu... |
|
From: Juras <yb...@tu...> - 2004-05-02 09:48:35
|
Hello stormdos-develop, http://ybx.narod.ru/sd/sd32_fpc_02may2004.tar.bz2 (~86 kb) -- Best regards, Juras mailto:yb...@tu... |
|
From: Stephane R. <sri...@to...> - 2004-05-02 09:14:07
|
I've tried CVS but it doesn't seem to want to work for me....not just you= r project either....anything I've tried to get through CVS doesn't seem to = let me. Is there a snapshot somewhere I can get instead? St=E9phane Richard ----- Original Message -----=20 From: "Juras" <yb...@tu...> To: "stormdos-develop" <sto...@li...> Sent: Saturday, May 01, 2004 4:09 PM Subject: [Stormdos-develop] CVS > Hello stormdos-develop, > > HAS ANYBODY TRIED CVS OUT THERE? > > --=20 > Best regards, > Juras mailto:yb...@tu... > > > > ------------------------------------------------------- > This SF.Net email is sponsored by: Oracle 10g > Get certified on the hottest thing ever to hit the market... Oracle 10g. > Take an Oracle 10g class now, and we'll give you the exam FREE. > http://ads.osdn.com/?ad_id=3D3149&alloc_id=3D8166&op=3Dclick > _______________________________________________ > Stormdos-develop mailing list > Sto...@li... > https://lists.sourceforge.net/lists/listinfo/stormdos-develop |
|
From: Juras <yb...@tu...> - 2004-05-01 20:10:43
|
Hello stormdos-develop, HAS ANYBODY TRIED CVS OUT THERE? -- Best regards, Juras mailto:yb...@tu... |
