China DOS Union

Make a mark, come back to see later

Support

Failure occurs when executing with QEMU 8.0 or above

Please try this one:

http://zhenlove.com.cn/cndos/fileup/files/bc_gui(qemu-0.9.0-windows).rar
It works fine in qemu-0.9.0-windows.

http://zhenlove.com.cn/cndos/fileup/files/bc_gui_exe.rar

[ Last edited by taowentao on 2007-4-22 at 10:46 AM ]

Hehe, it's a good thing, I've always liked things in graphic mode. I wanted to download it to study. But I didn't expect it to require points, so depressed

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 functions of the rtCell kernel:

1. 256 (64, 32) priorities, 0 is the highest priority (reserved by the system), 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), and this procedure will be executed when the task is scheduled next time;

5. Deletion avoidance mechanism. Tasks with mutexes and mutexes in the occupied state both have a mechanism to prevent deletion. To delete a task with a mutex, you must terminate it yourself or call the task termination function, and to delete any mutex, you must first make it idle, that is, no task occupies this mutex, otherwise deletion is prohibited;

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


New functions of giCell graphics multi-window:

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

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

3. Dynamic mouse cursor change function.

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

Is there any latest download?

Source code download:
http://www.cn-dos.net/forum/attachment.php?aid=3573&checkid=01076&download=1
https://gro.clinux.org/frs/download.php/2009/C_code.rar

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
Latest virtual machine (qemu-0.9.0-windows) demo:
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 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. Different priority tasks are completely preempted, and tasks of the same priority can be executed in first-in-first-out or time-slice round-robin manner;

4. Implement the kernel timer in a system (timer service) task, which is used for waiting for kernel objects with timeouts, periodic timers, task delays, and one-time timing (at this time, a process to be executed after the 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 timer (Timer), priority messages (Message), and ring buffers (Ring buffer);

6. Any kernel object is identified by an integer ID, not a pointer, thereby avoiding the side effects of wild pointers of 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 priorities. 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 for 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 are executed in the form of deferred procedure calls (DPC);

10. The task object supports asynchronous procedure calls (APC in Windows terms, equivalent to the signal mechanism in UNIX), thereby guiding the task to execute a procedure asynchronously (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 their ID.

13. The interrupt entry and exit interfaces 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 memory for 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, 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, closely 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 translation, zooming, cursor switching and window system buttons, as well as process callbacks for windows and controls;

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

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

6. Small memory requirements. 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.



Regarding the 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 under 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, etc. operations (mainly 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 must not 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 the AMD machine DOS real mode, the 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

"Attachment 2" is the latest demo under pure DOS.

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

Not bad, the original poster is amazing.

Supports 12-dot matrix Chinese characters (requires file hz12.bin), can call DOS file functions (but affects real-time performance). Press the key "SHIFT + ESC" to exit rtCell and return to the DOS system.

Virtual machine demonstration (download: http://zhenlove.com.cn/cndos/fileup/files/hz_demo.rar).

Pure DOS demonstration (download: http://zhenlove.com.cn/cndos/fileup/files/GUI_DOS.rar).

C_lib.rar is the latest source code (http://www.cn-dos.net/forum/attachment.php?aid=3809&checkid=cd567&download=1).

[ Last edited by taowentao on 2007-8-19 at 10:07 AM ]