dosemu2 / fdpp Goto Github PK
View Code? Open in Web Editor NEWFreeDOS plus-plus, 64bit DOS
License: GNU General Public License v3.0
FreeDOS plus-plus, 64bit DOS
License: GNU General Public License v3.0
Describe the bug
dosemu2
crashes when I try to run the installer for DataRescue IDA 3.7 freeware.
ERROR: Fault in dosemu code, in_dpmi=0
ERROR: cpu exception in dosemu code outside of VM86()!
sig: 8 trapno: 0x00 errorcode: 0x00000000 cr2: 0x00000000
eip: 0x7fd3dde9db61 esp: 0x7fd3c48a6c10 eflags: 0x00010246
cs: 0x0033 ds: 0x0000 es: 0x0000 ss: 0x0000
fs: 0x0000 gs: 0x0000
fsbase: 0x7fd3dfc37700 gsbase: (nil)
ERROR: Please install gdb, update dosemu from git, compile it with debug
info and make a bug report with the content of ~/.dosemu/boot.log at
https://github.com/stsp/dosemu2/issues
Please provide any additional info you can, like the test-cases,
URLs and all the rest that fits.
To Reproduce
ida37fw.zip
(below).install.exe
under dosemu2
like so: dosemu -D9+D -t -quiet -K install.exe
.install.exe
, select "Install Program".Attach the binaries
ida37fw.zip
(also available at textfiles.com
).Attach the log
Some ubsan errors seems to be false-positives.
Filled this ticket:
https://bugzilla.redhat.com/show_bug.cgi?id=1643318
Lets see.
Currently plt.asm has no idea whether the
call is near or far. This of course leads to
early crash.
Needs to extend plt generator.
Just as currently done for SHELL=
,
we need to allow setting a default
drive for DEVICE=
to allow the
relocation of the system drives.
https://github.com/stsp/fdpp/blob/master/fdpp/farptr.hpp#L98
This placement new can trigger DSE:
https://gcc.gnu.org/gcc-6/porting_to.html#flifetime-dse
The problem was caused by a21427f.
Clang doesn't seem to support -fno-lifetime-dse
option.
I wonder if the patch should be reverted.
But the revert will likely cause strict aliasing violation.
Can be un-hanged by any key press.
VOID ASMPASCAL WriteATClock(BYTE *, BYTE, BYTE, BYTE);
Currently thunk generator thinks the first
arg is a string, which it is not.
As a quick hack, this can be converted to
the farobj machinery. But the real fix would
be to extend parser, write converter for arrays
and/or do some manual conversion of all such cases.
Another possibility is to use the "void converter"
that understands the things like:
VOID ASMPASCAL WriteATClock(VOID *, int len, BYTE, BYTE, BYTE);
Hmm. Perhaps as a first step I should make
the parser to reject any near pointers other
than char *
and void *
(for which the converters
already exist), but even this is not too easy as
currently lexer aliases BYTE
and char
.
I'm thinking about adding FDPP to my dosemu test suit.
One boot test checks the version string, but I want to know what part of fdpp that relates to: the DOS boot code or the libfdpp.so?
C:\>ver /r
FreeCom version 0.84-pre2 XMS_Swap [Aug 28 2006 00:29:00]
DOS version 7.10
FDPP kernel - GIT (build 0001) [compiled Oct 14 2018]
C:\>
With other DOSes my test suite unpacks a tar file that contains everything for the tests on that OS such as IO.SYS MSDOS.SYS COMMAND.COM etc. But on FDPP there's an additional complication in that there's libfdpp.so to consider.
init_call_p_0() is a noreturn function.
It pops the return addr from stack, which
is not where it expects it to be.
Fortunately it doesn't use that addr, so
no crash happens.
If the parser is extended to understand
noreturn attribute, then the proper stack
adjustment will be done, plus releasing
of resources (in case of dosemu2 -
coopth thread can be released).
freedos (and fdpp) takes fdconfig.sys from
C:
even when boots from other drive.
Same is for command.com
, unless altered
with shell=
.
In the source code I don't see C:
being
hard-coded, so I think this is a bug, not a
decision.
Whatever it is, we need to properly support
the boot drive.
Andrew, do you want to take a look at that?
Currently dosemu2 boots fdpp automatically
w/o any extra setup, so this is very easy to
reproduce.
15 seconds if built with -O0, and 3 seconds
if built with -O2. Neither is very good.
And CPU load is 100%.
inputptr
is a symbol defined as word,
but is used as a near ptr to char.
Currently glob_asm.h
defines it as
char *
, which doesn't work.
Clearly it requires a new symbol type
that resolves to NearPtr template.
But NearPtr template currently only
works with dosobj.
So either apply some macro hackery
to inputptr
, or generalize NearPtr
template to parse more pointer types...
It looks like inputptr
is the only offender,
so whether generalizing NearPtr worth
the trouble, is unclear.
This blocks #7.
I'm wondering if a method of getting the current fdppkrnl.sys from FDPP itself might be possible? I know that you put some effort into getting install etc to install the current version if it's missing and that you check versions on startup etc, which is great.
Is this possible?
Native hdimage
Normal dosemu FATFS startup
fdppkrnl.sys
file exists(could be empty) in the current directory only its presence is used to select an fdpp boot.If it is I think it could alleviate a lot of the potential for fdppkrnl.sys
to become out of sync with the installed FDPP, could allow portable hdimages between FDPP aware systems (dosemu2, nightkernel? etc), and remove the need to install any meaningful fdppkrnl.sys on a new install.
Hi there, I thought time I tried this out but I'm having a problem building it
ajb@polly:/clients/common/fdpp.git$ cd kernel/
ajb@polly:/clients/common/fdpp.git/kernel$ make
cat thunk_calls.tmp | ../utils/thunk_gen >thunk_calls.h || (rm -f thunk_calls.h ; false)
/bin/sh: 1: ../utils/thunk_gen: not found
makefile:165: recipe for target 'thunk_calls.h' failed
make: *** [thunk_calls.h] Error 1
ajb@polly:/clients/common/fdpp.git/kernel$ cd ../utils/
ajb@polly:/clients/common/fdpp.git/utils$ make
clang -I../hdr -o patchobj.com patchobj.c
In file included from patchobj.c:22:
In file included from /usr/include/stdlib.h:314:
In file included from /usr/include/i386-linux-gnu/sys/types.h:132:
../hdr/time.h:42:9: error: unknown type name 'UWORD'
typedef UWORD _time;
^
1 error generated.
makefile:10: recipe for target 'patchobj.com' failed
make: *** [patchobj.com] Error 1
Do I have some build prerequisites missing?
When relocating the int handler, we need to update
IVT entry so that it always points to the handler, not
to PLT. This is needed so that the shared headers
can be added.
But first, it must be checked if its not the case already.
https://sourceforge.net/p/dosbox/code-0/HEAD/tree/dosbox/trunk/src/dos/
http://freedos-32.sourceforge.net/
http://freedos.10956.n7.nabble.com/DOS-Development-Idea-td16159.html
https://sourceforge.net/projects/dos64/
Study what these guys are up to, and write a
readme chapter.
valgrind reports hundreds of
==162323== Conditional jump or move depends on uninitialised value(s)
==162323== at 0x66DF6B2: InitPrinters() (main.cc:681)
==162323== by 0x66DE192: init_kernel() (main.cc:306)
==162323== by 0x66DD63C: FreeDOSmain() (main.cc:127)
==162323== by 0x66F032C: FdppThunkCall(int, unsigned char*, unsigned char*) (thunk_calls.h:19)
==162323== by 0x66EFDA3: FdppCall (thunks.cc:305)
==162323== by 0x186027: dos_helper (int.c:723)
==162323== by 0x186066: inte6 (int.c:209)
==162323== by 0x186066: _inte6_ (int.c:2641)
==162323== by 0x180EDE: run_caller_func (int.c:1744)
==162323== by 0x1810A5: do_int_from_thr (int.c:2349)
==162323== by 0x1A5C4A: coopth_thread (coopth.c:479)
==162323== by 0x1A72CF: co_runner (pcl.c:49)
==162323== Uninitialised value was created by a stack allocation
==162323== at 0x66DF670: InitPrinters() (main.cc:673)
error all around the code base.
I think they all are false and opened a bug to valgrind:
https://bugs.kde.org/show_bug.cgi?id=398445
I wonder if I should please valgrind and add an extra
initializers.
I see there's a kernel map file, are the addresses contained within absolute DOS addresses or do they need to be offset by some value? I want to find the CDS so before I start chasing for it, I thought I'd look for something simple and obvious like the OS version. The MAP file has this
0079:0090 _os_setver_minor
0079:0091 _os_setver_major
0079:0092 _os_minor
0079:0093 _os_major
0079:0095 _version_flags
0079:0096* os_release
But if I d
that in dosdebug I don't see any recognisable values
0079:0090 6C F6 0F 08 FF FF 00 D9 00 00 10 31 C0 8E D8 A0 [email protected]
gcc-ia16 has -mfar-function-if-far-return-type
switch
to work around bugs. Namely, when parsing int __far foo(void);
it assumes __far
applies to int
and ignores it, but with
-mfar-function-if-far-return-type
it applies it to the function too.
It appears my parser works as if -mfar-function-if-far-return-type
is specified, applying FAR
to both function and return val.
void FAR *DetectXMSDriver(VOID);
is a near function with
far return type, which is handled wrongly.
Plus, it seems when pointer is returned, its "farness" is lost
in a parser, and the thunk assumes to be always far.
If UMB at A0 is enabled and EMS disabled,
command.com cannot be started.
Similar bug was fixed by a21e02f, but for
some reason it appears to fix the problem
only if EMS is enabled...
The good news first:
PC/GEOS starts up with "fdppkrnl.sys" and works fine as far I've tested it. That's really great!
But when I leave / exit PC/GEOS for returning to DOS, I get a crash of FDPP / DOSEMU2.
boot-fdpp.log
(boot.log has been renamed and shortened due to lots of dispatch lines)
My manual setup of drive_c use the current "fdppkrnl.sys" from GIT (20181102) and the "command.com" from FreeDOS (0.84-pre2).
I'd liked to try comcom32 too, but I'm still unable to compile it. Maybe someone has a short hint which Debian packet has the right compiler or where can I get a precompiled one.
Happy to chase this one down myself, but perhaps you can indicate what I might be looking for
ERROR: fdpp booting, this is very experimental!
ERROR: fdpp: abort at ./farptr.hpp:191
The hacks like this:
ff9a805
are not too evil by themselves, but their need is
undetectable w/o lots of manual debugging.
We need to track object relationships so that we can:
C++ gurus laughs at my coding.
They say I shouldn't be using the Cish
type-casts to create the C++ objects
directly from DOS pointers. They suggest
using "placement new" instead.
Listening to gurus always helps, so I need
to investigate this possibility.
Currently fdpp reserves ~1K of conv memory
and doesn't know how to relocate it.
Conv memory is expensive.
Tracking bug.
dosemu2/dosemu2#50
https://github.com/stsp/dosemu2/blob/devel/src/dosext/misc/xms.c#L128
dosemu2/dosemu2#478
@andrewbird I've seen you were reporting some
bugs to the original freedos kernel, and even with
patches. How about moving them here and testing
your patches? Redirector works long ago, everything
is set and ready for a try.
Study how Bart did that for FreeDOS and do the same here.
In dosemu's dumb terminal mode, neither the
typing, nor cmd line are visible. Fine with freedos.
Not sure if its a dosemu or fdpp bug.
fdpp files should be separated.
Build should happen in a different dir.
Before this patch: b59a716
freecom was getting 256 bytes for env
by default, unless you use shell=
.
Under fdpp that crashes if UMB is
not available.
So if fdconfig.sys has:
DOS=UMB,HIGH
device=e:\dosemu\umb.sys
shellhigh=c:\command.com /e:256 /k e:\autoexec.bat
(now with the patch, 256 should be explicitly
forced), then no crash. But remove line 1 or 2
and it crashes.
Reading from stdin always returns error.
Currently they are put into a map, and never
removed (until reboot).
Would be nice if the proper life-time rules can
be established. This will speed up the look-ups
even more.
Needs to investigate that possibility and either
implement, or explain why not possible.
I tried to revert the change to the rfcb structure introduced in e8196ab and pack to match the DOS definition as per
diff --git a/hdr/fcb.h b/hdr/fcb.h
index 252af47..ad2ae07 100644
--- a/hdr/fcb.h
+++ b/hdr/fcb.h
@@ -113,8 +113,8 @@ typedef struct _rfcb {
BYTE renOldName[8]; /* Old Filename */
BYTE renOldExtent[3]; /* Old File Extension */
BYTE renReserved1[5];
- AR_MEMB(struct _rfcb, BYTE, renNewName, 8); /* New Filename */
+ BYTE renNewName[8]; /* New Filename */
BYTE renNewExtent[3]; /* New FileExtension */
BYTE renReserved2[9];
-} rfcb;
+} PACKED rfcb;
but now I get an FDPP compilation error what's the fix here, please?
clang++ -std=c++11 -iquote /clients/common/fdpp.git/fdpp/../hdr -Wall -c -fno-threadsafe-statics -fno-rtti -fpic -Wno-format-invalid-specifier -Wmissing-prototypes -ggdb3 -fdebug-macro -O0 -DI386 -DWITHFAT32 -I . -I /clients/common/fdpp.git/fdpp/../kernel/ -I /clients/common/fdpp.git/fdpp -DDATADIR=/usr/local/share/fdpp -DKRNL_NAME=fdppkrnl.sys -DCURDIR=/clients/common/fdpp.git/fdpp -o fcbfns.o fcbfns.cc
fcbfns.cc:557:20: error: no viable overloaded '='
pFromPattern = lpRenameFcb->renNewName;
~~~~~~~~~~~~ ^ ~~~~~~~~~~~~~~~~~~~~~~~
./farptr.hpp:139:7: note: candidate function (the implicit copy assignment operator) not viable: no known conversion from 'BYTE [8]' to 'const FarPtr<const char>' for 1st argument
class FarPtr : public FarPtrBase<T>
^
1 error generated.
makefile:139: recipe for target 'fcbfns.o' failed
make[1]: *** [fcbfns.o] Error 1
make[1]: Leaving directory '/clients/common/fdpp.git/fdpp'
makefile:105: recipe for target 'all' failed
make: *** [all] Error 2
Previously(with PACKing) the structure seen in gdb was
(gdb) p *(struct _rfcb *) &lowmem_base[(6588<<4)+286]
$19 = {renDriveID = 0 '\000', renOldName = "testa ", renOldExtent = "bat", renReserved1 = "\000\000\000\000", renNewName = {<MembBase<char, &_rfcb::off_renNewName>> = {<No data fields>},
sym = "testb ", static len = 8}, renNewExtent = "bal", renReserved2 = "\000\000\000\000\000\000\000\000"}
7b43711#diff-a42557ec73b3bb8176e23e5c47dc0659R417
This disables the previous speed-up hack.
Now the reliable optimization is needed, and
that should be an STL map.
So rewrite farhlp.c to C++ must be done.
Commit 23a04f8 fixed #48 and many
other problems, so it is good and needed.
But this MK_FAR_CHLD()
is basically a
reincarnation of the static object tracker -
something I'd like to keep removed.
Needs to find the fix on freedos level,
rather than on fdpp level. If freedos can't
work w/o static object trackers, then it needs
to be fixed (and already was when I got rid
of MK_FAR_ST()
stuff). These days I
prefer to adapt freedos to the fdpp model,
rather than to extend fdpp to cover all freedos
quirks.
I created the branch ddt
where I tried to
address this on freedos level, but it doesn't
boot yet. Also it is adding another variation
of struct ddtstruct
, and I wonder if it is good
to have 2 slightly different versions of the
same struct...
Currently fdpp (and freedos) hooks the
interrupts and does not call the previous
handlers (set by BIOS).
Make it so that it does.
It seems the relocation scheme is intentionally
obfuscated.
struct RelocationTable {
UBYTE jmpFar;
UWORD jmpOffset;
UWORD jmpSegment;
UBYTE callNear;
UWORD callOffset;
} PACKED;
struct RelocatedEntry {
UBYTE callNear;
UWORD callOffset;
UBYTE jmpFar;
UWORD jmpOffset;
UWORD jmpSegment;
} PACKED;
These 2 defs just swap places of call and jump,
and indeed, there is a code like this:
struct RelocatedEntry FAR *rel = (struct RelocatedEntry FAR *)rp;
fmemcpy_n(&rtemp, rp, sizeof(rtemp));
rel->jmpFar = rtemp.jmpFar;
rel->jmpSegment = NewKernelSegment;
rel->jmpOffset = rtemp.jmpOffset;
rel->callNear = rtemp.callNear;
rel->callOffset = rtemp.callOffset + 5; /* near calls are relative */
... that casts between these two, and swaps
places of call and jump.
We need to de-obfuscate this and only have
one relocation struct, preferably the one not
containing any call at all, only long jump.
Crashes on Ctrl-Alt-Del.
After getting tn_printf()
in truename to print to dosemu I find that dosemu crashes. I find it's when a debug statement tries to print %P
with GET_FP32(cdsEntry)
as its arg. Strangely commenting it out also makes the DOS prompt look correct too.
What should the correct fix be, add %P
to dosemu, or something else?
As pointed in #34 (comment),
FcbNameInit()
didn't work properly with this macro.
Another wrong use is newstuff.c:339.
The rest seems safe.
I wonder if those can be added to the
plain makefiles, w/o adding an autoconf.
Presumably if they can pass us PREFIX,
all should be well.
VOID ASMPASCAL WriteATClock(BYTE *, BYTE, BYTE, BYTE);
plt only sees 2 arguments here, as the
argpack size here is 5 instead of 8.
The problem:
I want to be able to run Dosemu/FDPP without any global installation on the system, but when I do I see messages about there being no bootable drive.
The old solution:
I know we spoke about this a while ago (Nov 2018) and I did have a working solution back then by setting FDPP_KERNEL_DIR, but that no longer seems to be enough to get the FDPP plugin to recognise a bootable drive.
To replicate:
pwd
/pkgconfig ./default-configure -d && makeprefix=/usr/local
fdpplibdir=/clients/common/fdpp.git/fdpp
fdppincdir=/clients/common/fdpp.git
Name: fdpp
Description: DOS compatibility layer
Version: 0.1
Libs: -Wl,-rpath,${fdpplibdir} -L${fdpplibdir} -lfdpp
Cflags: -I${fdppincdir}
./runstandalonetest.sh
GDB=""
+ GDB=
GDB_DOSEMU_ARGS=""
+ GDB_DOSEMU_ARGS=
if [ x${1} = "x-gdb" ] ; then
GDB="gdb --args"
GDB_DOSEMU_ARGS="-I 'cpuemu fullsim'"
fi
+ [ x = x-gdb ]
env FDPP_KERNEL_DIR=../fdpp.git/fdpp ${GDB} bin/dosemu.bin \
-n -f test-imagedir/dosemu.conf -D+dRW -o test.log \
--Fimagedir test-imagedir \
${GDB_DOSEMU_ARGS}
+ env FDPP_KERNEL_DIR=../fdpp.git/fdpp bin/dosemu.bin -n -f test-imagedir/dosemu.conf -D+dRW -o test.log --Fimagedir test-imagedir
ERROR: Neither FreeDOS nor comcom32 installation found.
Use DOSEMU2_FREEDOS_DIR env var to specify alternative location.
ERROR: No system files found at /usr/local/share/dosemu/fdboot
ERROR: dosemu2 commands not found at /usr/local/share/dosemu/dosemu2-cmds-0.2
CONF aborted with: DOSEMU_LIB_DIR does not exist /usr/local/share/dosemu
./runstandalonetest.sh
GDB=""
+ GDB=
GDB_DOSEMU_ARGS=""
+ GDB_DOSEMU_ARGS=
if [ x${1} = "x-gdb" ] ; then
GDB="gdb --args"
GDB_DOSEMU_ARGS="-I 'cpuemu fullsim'"
fi
+ [ x = x-gdb ]
env FDPP_KERNEL_DIR=../fdpp.git/fdpp ${GDB} bin/dosemu.bin \
-n -f test-imagedir/dosemu.conf -D+dRW -o test.log \
--Fimagedir test-imagedir \
--Flibdir test-libdir \
${GDB_DOSEMU_ARGS}
+ env FDPP_KERNEL_DIR=../fdpp.git/fdpp bin/dosemu.bin -n -f test-imagedir/dosemu.conf -D+dRW -o test.log --Fimagedir test-imagedir --Flibdir test-libdir
ERROR: Neither FreeDOS nor comcom32 installation found.
Use DOSEMU2_FREEDOS_DIR env var to specify alternative location.
ERROR: dosemu2 commands not found at /clients/common/dosemu2.git/test-libdir/dosemu2-cmds-0.2
ERROR: Your fluidsynth is too old and soundfonts not found
ERROR: alsa_midi (ALSA lib): rawmidi_hw.c:233:(snd_rawmidi_hw_open) : No such file or directory open /dev/snd/midiC0D0 failed
ERROR: Bootable drive not found, exiting
dosemu.conf
$_lpt1 = ""
$_hdimage = "dXXXXs/c:hdtype1"
$_debug = "-D+d"
ajb@polly:/clients/common/dosemu2.git$ find test-imagedir
test-imagedir
test-imagedir/drives
test-imagedir/dXXXXs
test-imagedir/dXXXXs/c
test-imagedir/dXXXXs/c/autoexec.bat
test-imagedir/dXXXXs/c/version.bat
test-imagedir/dXXXXs/c/config.sys
test-imagedir/dXXXXs/c/command.com
test-imagedir/dXXXXs/c/dosemu
test-imagedir/dXXXXs/c/dosemu/exitemu.com
test-imagedir/dXXXXs/c/dosemu/speed.com
test-imagedir/dXXXXs/c/dosemu/emumouse.com
test-imagedir/dXXXXs/c/dosemu/unix.com
test-imagedir/dXXXXs/c/dosemu/dosdbg.com
test-imagedir/dXXXXs/c/dosemu/eject.com
test-imagedir/dXXXXs/c/dosemu/system.com
test-imagedir/dXXXXs/c/dosemu/blaster.com
test-imagedir/dXXXXs/c/dosemu/sound.com
test-imagedir/dXXXXs/c/dosemu/isemu.com
test-imagedir/dXXXXs/c/dosemu/cdrom.sys
test-imagedir/dXXXXs/c/dosemu/generic.com
test-imagedir/dXXXXs/c/dosemu/umb.sys
test-imagedir/dXXXXs/c/dosemu/emufs.sys
test-imagedir/dXXXXs/c/dosemu/xmode.com
test-imagedir/dXXXXs/c/dosemu/aspi.sys
test-imagedir/dXXXXs/c/dosemu/dpmi.com
test-imagedir/dXXXXs/c/dosemu/lredir2.com
test-imagedir/dXXXXs/c/dosemu/fossil.com
test-imagedir/dXXXXs/c/dosemu/ems.sys
test-imagedir/dXXXXs/c/dosemu/lredir.com
test-imagedir/dosemu.conf
Note: Dosemu itself creates test-imagedir/drives
, I don't know why.
It seems to me that my adding --Flibdir is wrong and I only did it to get further, but without it a missing /usr/local/share/dosemu is fatal, even though I have a valid FDPP_KERNEL_DIR.
With the last efforts, the memory pool after
boot looks like this:
Total size: 300
Available space: 33
Largest free area: 33
Memory pool dump:
area: 12 bytes, used
area: 13 bytes, used
area: 67 bytes, used
area: 67 bytes, used
area: 24 bytes, used
area: 31 bytes, used
area: 22 bytes, used
area: 15 bytes, used
area: 16 bytes, used
area: 33 bytes, free
Which is much better than what was before,
but still far from the gloriously wonderful zero.
Who eats this memory? I suppose some leaks
are produced by the NORETURN calls that
can't clean up after themselves. Maybe I should
stop using longjmp()
for NORETURN, as it
is an UB according to the standard, and use C++
exceptions?
Anyway, there seems to be a leak somewhere,
and probably an UB in NORETURN impl.
As per PR #42, for which I've lost interest in fixing, here are the test binaries.fcb_rename.zip
ASMFUNC/ASMPASCAL funcs use inexact
types like int
, unsigned
, long
.
Should be replaced with exact types.
DiskTransferBuffer gets frequently assigned
to __DOSFAR() - the casual far pointers that
don't carry an object ownership. This OOMs
dosobj quickly.
Buffer needs to be moved to asm.
Booting the same disk configuration under FreeDOS and FDPP gives different results. On FreeDOS the boot proceeds as expected, on FDPP it can't find the files referenced in config.sys or autoexec.bat itself.
I've attached the installation files
test-imagedir.tar.gz
Run from dosemu build directory as
bin/dosemu.bin -n -f test-imagedir/dosemu.conf -D+dRW -o test.log --Fimagedir test-imagedir
Firstly with your fdppkrnl.sys
in test-imagedir/dXXXXs/c
then replace that with kernel.sys
from FreeDOS 1.20
A declarative, efficient, and flexible JavaScript library for building user interfaces.
๐ Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. ๐๐๐
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google โค๏ธ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.