China DOS Union

Source code download: http://www.cn-dos.net/forum/attachment.php?aid=3573&checkid=01076&download=1
Note: The C_code.rar file corrects the problem that the callback function cannot use floating-point operations...
Demo download: http://zhenlove.com.cn/cndos/fileup/files/gui_demo.rar


The complete functions are described as follows:

rtCell Real-Time Microkernel - has the following functions:

1. Completely preemptive real-time microkernel structure, independent kernel stack, interrupts and system calls are all switched to the kernel stack for execution;

2. 256 (64, 32) priorities, 0 is the highest priority (reserved by the system), and 256 (64, 32) is the idle priority;

3. Tasks of different priorities are completely preempted, and tasks of the same priority can be executed in first-in-first-out or time-slicing round-robin manner;

4. Implement a kernel timer in a system (timer service) task, which is used for timeout waiting for kernel objects, periodic timers, task delays, and one-time timing (at this time, a process to be executed after timeout needs to be defined); the priority of this service task is driven by the highest priority of its client tasks and changes dynamically to eliminate the implicit priority inversion phenomenon;

5. Provide kernel objects such as tasks (Task), mutexes (Mutex), semaphores (Semaphore), bit-field flags (Flag timers (Timer), priority messages (Message), and ring buffers (Ring buffer);

6. Any kernel object is identified by an integer ID, not a pointer, so as to avoid the side effects of wild pointers in user tasks. The total number of kernel objects does not exceed 61440 (that is, 60K);

7. Mutexes support priority inheritance and priority ceiling protocols, which are set when created, and always wait according to priority. Only nested calls to the same mutex are supported in the priority inheritance protocol, and multiple nested calls to different mutexes are also supported in the priority ceiling protocol;

8. The waiting methods of other objects are priority waiting and first-in-first-out (saving memory) waiting, which are set when created;

9. For the synchronization of kernel data, except for temporarily disabling interrupts during task switching and stack switching between tasks and the kernel, other places all execute in the form of deferred procedure calls (DPC);

10. The task object supports asynchronous procedure calls (APC in Windows terminology, equivalent to the signal mechanism in UNIX), so as to guide the task to execute a procedure asynchronously (provided that the task stack is not less than 1024 bytes). This procedure will be executed when the task is scheduled next time;

11. Deletion avoidance mechanism: Tasks that own mutexes and mutexes in the occupied state both have a mechanism to prevent deletion. To delete a task that owns a mutex, it must terminate by itself or call the task termination function. To delete any mutex, it must first make it in an idle state, that is, no task occupies this mutex, otherwise deletion is prohibited;

12. Object naming mechanism: Kernel objects of the same type can be identified by a unique name to obtain its ID for reference.

13. The entry and exit interfaces of interrupts are implemented in the kernel, so user interrupt processing only needs to write standard C functions without having to care about the details of the underlying interrupt processing;

14. System calls are implemented by trap instructions (int instruction in x86), which is easy to expand to the process mode of "memory protection";

15. A simple heap memory allocation mechanism is provided outside the kernel library for calling when dynamically allocating kernel objects;

16. Supports millisecond-level timers, and the kernel timer period is one millisecond;

17. Supports the task state protection of the X387/287 hardware floating-point coprocessor, and the task floating-point state switching in passive mode (executed with interrupts enabled. Since it is implemented using privileged instructions, it can only be executed in pure DOS real mode or virtual machines X386/X387 and subsequent models, and cannot run in the DOS window of Windows).



giCell Viewport Clipping and Hiding Processing Engine - functions are as follows:

1. A perfect and delicate multi-viewport clipping and hiding processing engine, tightly integrated with the microkernel rtCell;

2. Truly event (or message) driven multi-window (viewport) technology, supporting the display and clipping processing of top-level windows and transparent windows;

3. Currently supports Label, Edit, Botton, Slider, Listbox, TreeView and Checkbox controls. Among them, the Edit control supports cut, copy and paste (ctrl+x, ctrl+c, ctrl+v);

4. Supports window panning, zooming, cursor switching and window system buttons, as well as process callbacks of windows and controls;

5. Based on transparent viewport (or window) clipping and hiding processing, any non-rectangular (polymorphic) window can be generated. The triangular window in this example is implemented based on the transparent viewport;

7. Supports graphic memory device (GDC), effectively avoiding flicker when the window is redrawn, and easy to implement video and animation processing;

6. Small memory requirement, the default states of windows and controls do not use GDC (but use direct screen technology), and the memory consumption is small, so it is practical. The library files including the rtCell scheduler, mouse, keyboard and graphics driver are only 77K under DOS.



About the available files Engine.lib and mcOutLib.obj:

1. Considering the memory limitations of DOS, the rtCell kernel in the library file Engine.lib only supports 32 task priorities (because the priority queue occupies too much memory). In this way, even in 640K memory, hundreds of kernel and GUI objects can be created, which can meet the requirements of application programs of a certain scale;

2. The library file mcOutLib.obj is the compilation result of the files in the directory giCell\mcOSLib, which is used to handle the task floating-point coprocessor (hardware) state switching, task floating-point state initialization, memory allocation, information display and other operations (mainly for the kernel). Users can also compile the files in the giCell\mcOSLib directory by themselves. Note: Borland C/C++ 3.1 may not recognize some of the floating-point operation instructions in it;

3. The file MAIN.C is a specific example of using Engine.lib. When compiling in Borland C/C++ 3.1, the X387/287 option and C function parameter passing convention must be turned on. This file also demonstrates how to use transparent windows to generate non-rectangular windows and how to use GDC to generate animations;

4. Pay attention to some execution orders: floating-point operations cannot be placed in callback functions, but can only be executed in other tasks (can be realized by sending messages from callback functions to other tasks), otherwise the program will enter an infinite loop;

5. Because the task state switching mechanism of the floating-point coprocessor uses privileged instructions, the generated executable file can only be executed in pure DOS real mode or virtual machines X386/X387 and subsequent models, and cannot run in the DOS window of Windows;

6. The executable file generated by MAIN.C runs well under AMD machine DOS real mode, X86 virtual machine qemu-0.9.0-windows and Bochs-2.1.1. Note: The generated executable file is still in 16-bit real mode.


The compressed file C_lib.rar contains the source code of windows and their sub-controls, the demonstration files MAIN.C and DateTime.c, and an engineering file specially for Borland C/C++ 3.1.

Note: When using floating-point operations, it is best to set the stack of the relevant task to more than 2K.


Contact email: taowentao_twt@163.com, taowentao_twt@sohu.com

Source code download:


The Chinese character font is the standard 9-point SimSun in Windows XP (http://www.cn-dos.net/forum/attachment.php?aid=3840&checkid=6c12e&download=1).

Note: DOS is not reentrant. Before calling DOS functions outside the GUI task, a GUI lock should be added, and after calling, it should be unlocked. Moreover, the priority of the task calling DOS functions should be lower than 16:
void _cdecl_ GUILock(void); /* Lock GUI to protect the security of shared data */
void _cdecl_ GUIUnLock(void); /* Unlock GUI, locking and unlocking should appear in pairs */

In addition, the vector font file KTDOT.PS is also required in this demonstration. Please download this file from "Vector Chinese Character Display Example - happybasic" (http://www.cn-dos.net/forum/viewthread.php?tid=27441&fpage=3)

[ Last edited by taowentao on 2007-8-23 at 10:06 PM ]

Why are there two download addresses? I tried them, and they are the same!

But it seems almost the same

Basically objective and comprehensive

Mainly afraid that the uploaded file cannot be unzipped, so two different compression formats are prepared. Please forgive all netizens.

Also, please guide netizens about the improper places in the software, thank you!

[ Last edited by taowentao on 2007-1-3 at 03:17 AM ]

Come on, those who are hanging out here should all have compression software. Otherwise, make it into a self-extracting one.

Latest demonstration: https://gro.clinux.org/frs/download.php/2000/giCell.rar

Comes with mouse and keyboard drivers.

Demonstration method: Unzip giCell.rar, execute my_gui.bat under Windows (double-click), or execute my_gui.exe directly under pure DOS (no mouse in the DOS window of Windows).

New features of the rtCell kernel:

1. 256 (64, 32) priorities, 0 is the highest priority (reserved by the system), and 256 (64, 32) is the idle priority;

2. One-time timing (at this time, a procedure to be executed after the timeout needs to be defined);

3. Mutex support for priority inheritance and priority ceiling protocols. Set this protocol when creating, and always wait according to priority. The priority inheritance protocol only supports nested calls of the same mutex, and the priority ceiling protocol can also support multiple nested calls of different mutexes;

4. Task objects support asynchronous procedure calls (APC in Windows terms, equivalent to the signal mechanism in UNIX), so that a task can be guided to execute a procedure asynchronously (provided that the task stack is not less than 1024 bytes). This procedure will be executed when the task is scheduled next time;

5. Deletion avoidance mechanism. Both the task that owns the mutex and the mutex in the occupied state have a mechanism to prevent deletion. To delete the task that owns the mutex, it must terminate by itself or call the task termination function, and to delete any mutex, it must first make it in an idle state, that is, no task occupies this mutex, otherwise deletion is prohibited;

6. Object naming mechanism. Kernel objects of the same type can be identified by a unique name to obtain its ID for reference purposes.

New features of the giCell graphical multi-window:

1. Mouse function improvement, closer to the mouse events of Windows;

2. Clipping and hiding processing based on transparent viewports (or windows), which can generate any non-rectangular window. The triangular window in this example is realized through the function of transparent viewports.

[ Last edited by taowentao on 2007-5-2 at 04:53 PM ]

Source code download: http://zhenlove.com.cn/cndos/fileup/files/C_lib.rar
http://www.cn-dos.net/forum/attachment.php?aid=3573&checkid=01076&download=1
Demonstration download: http://zhenlove.com.cn/cndos/fileup/files/gui_demo.rar
Latest virtual machine (qemu-0.9.0-windows) demonstration: http://zhenlove.com.cn/cndos/fileup/files/qemu-0.9.0-windows.rar


The complete functions are described as follows:

rtCell Real-Time Microkernel - with the following functions:

1. Completely preemptive real-time microkernel structure, independent kernel stack, interrupts and system calls are all switched to the kernel stack for execution;

2. 256 (64, 32) priorities, 0 is the highest priority (reserved by the system), 256 (64, 32) is the idle priority;

3. Tasks of different priorities are completely preempted, and tasks of the same priority can be executed in first-in-first-out or time-slice round-robin manner;

4. A kernel timer is implemented in a system (timer service) task, which is used for timeout waiting for kernel objects, periodic timers, task delays, and one-time timing (at this time, a procedure to be executed after timeout needs to be defined); the priority of this service task is driven by the highest priority of its client tasks and changes dynamically to eliminate the implicit priority inversion phenomenon;

5. Provides kernel objects such as task (Task), mutex (Mutex), semaphore (Semaphore), bit-field flag (Flag timer (Timer), priority message (Message), and ring buffer (Ring buffer);

6. Any kernel object is identified by an integer ID instead of a pointer, thereby avoiding the side effects of wild pointers in user tasks, and the total number of kernel objects does not exceed 61440 (that is, 60K);

7. The mutex supports priority inheritance and priority ceiling protocols, which are set when created, and always wait by priority. Only nested calls to the same mutex are supported in the priority inheritance protocol, and multiple nested calls to different mutexes can also be supported in the priority ceiling protocol;

8. The waiting methods of other objects are: priority waiting and first-in-first-out (saves memory) waiting, which are set when created;

9. For the synchronization of kernel data, except for temporarily disabling interrupts during task switching and when switching stacks between tasks and the kernel, other places all execute in the form of deferred procedure calls (DPC);

10. The task object supports asynchronous procedure calls (APC in Windows terminology, equivalent to the signal mechanism in UNIX), so that a task can asynchronously execute a procedure (provided that the task stack is not less than 1024 bytes), and this procedure will be executed when the task is scheduled next time;

11. Deletion avoidance mechanism: tasks that own mutexes and mutexes in the occupied state both have a mechanism to prevent deletion. To delete a task that owns a mutex, it must terminate by itself or call the task termination function, and to delete any mutex, it must first make it in an idle state, that is, no task occupies this mutex, otherwise deletion is prohibited;

12. Object naming mechanism: kernel objects of the same type can be referenced by using a unique name identifier to obtain its ID.

13. The entry and exit interfaces of interrupts are implemented in the kernel, so user interrupt processing only needs to write standard C functions without having to care about the details of the underlying interrupt processing;

14. System calls are implemented by trap instructions (int instruction in x86), which is easy to expand to the process mode of "memory protection";

15. A simple heap memory allocation mechanism is provided outside the kernel library, which is called when the kernel object dynamically allocates memory;

16. Supports millisecond-level timers, and the kernel timer period is one millisecond;

17. Supports the task state protection of the X387/287 hardware floating-point coprocessor, and the task floating-point state switching in passive mode (executed with interrupts enabled, because it is implemented using privileged instructions, so it can only be executed in pure DOS real mode or virtual machines X386/X387 and subsequent models, and cannot run in the DOS window of Windows).



giCell Viewport Clipping and Hiding Processing Engine - functions are as follows:

1. A perfect and delicate multi-viewport clipping and hiding processing engine, tightly combined with the microkernel rtCell;

2. Truly event (or message) driven multi-window (viewport) technology, supporting the display and clipping processing of top-level windows and transparent windows;

3. Currently supports Label, Edit, Botton, Slider, Listbox, TreeView and Checkbox controls, among which the Edit control supports cut, copy and paste (ctrl+x, ctrl+c, ctrl+v);

4. Supports window panning, zooming, cursor switching and window system buttons, as well as process callbacks for windows and controls;

5. Based on transparent viewport (or window) clipping and hiding processing, any non-rectangular (polymorphic) window can be generated. The triangular window in this example is implemented based on the transparent viewport;

7. Supports graphics memory device (GDC), effectively avoiding flicker when the window is redrawn, and easy to implement video and animation processing;

6. Small memory requirement, the default states of windows and controls do not use GDC (but use direct screen technology), and the memory consumption is small, so it is practical. The library files including the rtCell scheduler, mouse, keyboard and graphics driver are only 77K under DOS.



About the files Engine.lib and mcOutLib.obj:

1. Considering the memory limit of DOS, the rtCell kernel in the library file Engine.lib only supports 32 task priorities (because the priority queue occupies too much memory). In this way, even in 640K memory, hundreds of kernel and GUI objects can be created, which can meet the requirements of application programs of a certain scale;

2. The library file mcOutLib.obj is the compilation result of the files in the directory giCell\mcOSLib, which is used to handle the task floating-point coprocessor (hardware) state switching, task floating-point state initialization, memory allocation, information display and other operations (mainly used for the kernel). Users can also compile the files in the directory giCell\mcOSLib by themselves. Note: Borland C/C++ 3.1 may not recognize some of the floating-point operation instructions in it;

3. The file MAIN.C is a specific example of using Engine.lib. When compiling in Borland C/C++ 3.1, the X387/287 option and the C function parameter passing convention must be turned on. This file also demonstrates how to use transparent windows to generate non-rectangular windows and how to use GDC to generate animations;

4. Pay attention to some execution orders: floating-point operations should not be placed in the callback function, but can only be executed in other tasks (can be realized by sending messages from the callback function to other tasks), otherwise the program will enter an infinite loop;

5. Because the task state switching mechanism of the floating-point coprocessor uses privileged instructions, the generated executable file can only be executed in pure DOS real mode or virtual machines X386/X387 and subsequent models, and cannot run in the DOS window of Windows;

6. The executable file generated by MAIN.C runs well under AMD machine DOS real mode, X86 virtual machine qemu-0.9.0-windows and Bochs-2.1.1. Note: The generated executable file is still in 16-bit real mode.


The compressed file C_lib.rar contains the source code of windows and their sub-controls, the demonstration files MAIN.C and DateTime.c, and an engineering file specially for Borland C/C++ 3.1.

Note: It is best to set the stack of the relevant task to more than 2K when using floating-point operations.




Contact email: taowentao_twt@163.com, taowentao_twt@sohu.com

[ Last edited by taowentao on 2007-6-21 at 10:03 PM ]

I didn't pay attention to the points issue originally, but it has now been changed to not requiring points.

Amazing! Support the expert

Bump

TreeView and ListView Demo:
http://zhenlove.com.cn/cndos/fileup/files/giCell_demo.rar

Virtual Machine Run Screenshot:


[ Last edited by taowentao on 2007-7-1 at 01:19 PM ]

First, top then watch

Release the SDK and take a look

[ Last edited by AlexZhang on 2007-6-30 at 12:56 PM ]