[Freedos-kernel] EBDA movement FUD
Hi, I would like to spread some fear, uncertainity and distrust about EBDA movement! For explanation, in 2032+ kernels, this is enabled by default. You can suppress it with SWITCHES=/E in your config sys file. Some time ago, I noticed that UPX would sometimes create broken, truncated, cross-linked... files, but could never reproduce it. That was with kernel 2032a as far as I remember. Today I had the same with kernel 2034 when trying to compile MODE. In DOSEMU, things worked fine, but not in plain FreeDOS. The UPXed file would crash or would even cross-link to cluster 0 (good that the kernel now shows a warning when it hits such a broken cluster chain). Removing LBAcache would not change the situation. But guess what, adding SWITCHES=/E to my config apparently fixed the problem! Interesting: My 2032a troubles a while ago and 2034 troubles now happened on different computers with different BIOS brands (the 2034 test was done on a PC with a BIOS in Windows style design with a mouse pointer which wiggles its tail all the time X-)). If you take my problems on 2 different computers and the problems described for a third computer in Bugzilla on: http://www.freedos.org/bugs/bugzilla/show_bug.cgi?id=1771 Then you can conclude that EBDA movement can be generally dangerous. Maybe NOT moving EBDA could be made the default? If the EBDA is not moved, there are less than 640k of DOS memory. Some programs might fail to notice that and accidentally overwrite the EBDA at the end of the last 640k. On the other hand, moving the EBDA can be missed by some instances in BIOS(es) which means that when FreeDOS thinks that the last part of the first 640k can be used by DOS again SOME other software still writes EBDA data there. In bug 1771, the effect was overwriting the MCB at 9fff:0 which broke UMB operation whenever EBDA was moved. I think it is somehow hard to decide what is more dangerous - NOT moving the EBDA (less than 640k DOS RAM) or MOVING the EBDA (into some low memory location allocated by DOS). For now, I think it is safer to leave the EBDA unmoved. Eric. --- This SF.net email is sponsored by: The Robotic Monkeys at ThinkGeek For a limited time only, get FREE Ground shipping on all orders of $35 or more. Hurry up and shop folks, this offer expires April 30th! http://www.thinkgeek.com/freeshipping/?cpg=12297 ___ Freedos-kernel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] EBDA movement FUD
Hello Michael, Hi, I would like to spread some fear, uncertainity and distrust about EBDA movement! MD Can you give the exact syntax on using that in CONFIG.SYS. MD Is it a bare SWITCHES=/E line on its own? Yes, it's a bare switches=/E I had to discover this this morning, too, as running device=S-ice.exe /EMM 4000 also nukes the PC. It seems, Softice is moving the EBDA by itself and in addition to the kernel, to the PC ends up with 641KB, which would only be nice if it worked. tom --- This SF.net email is sponsored by: The Robotic Monkeys at ThinkGeek For a limited time only, get FREE Ground shipping on all orders of $35 or more. Hurry up and shop folks, this offer expires April 30th! http://www.thinkgeek.com/freeshipping/?cpg=12297 ___ Freedos-kernel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-kernel
[Freedos-kernel] patch: batch and make files (2/2)
---BeginMessage--- diff -ruNp old/kernel/kernel.cfg new/kernel/kernel.cfg --- old/kernel/kernel.cfg 2001-07-10 00:19:32.0 + +++ new/kernel/kernel.cfg 1970-01-01 00:00:00.0 + @@ -1,14 +0,0 @@ --1- --f- --ff- --O --Z --d --k- --vi- --w --wpro --weas --wpre --I..\hdr --v -X- -I. -D__STDC__=0 -DTSC -DDEBUG -DKERNEL -DI86 -DPROTO -DSHWR -DASMSUPT diff -ruNp old/kernel/makefile new/kernel/makefile --- old/kernel/makefile 2004-04-12 11:36:06.0 + +++ new/kernel/makefile 2004-04-22 11:30:48.0 + @@ -29,7 +29,7 @@ OBJS=$(OBJS1) $(OBJS2) $(OBJS3) $(OBJS4) # *Explicit Rules* -production: ..\bin\$(TARGET).sys +production:..\bin\$(TARGET).sys ..\bin\$(TARGET).sys: kernel.sys copy kernel.sys ..\bin @@ -43,7 +43,7 @@ kernel.sys: kernel.exe ..\utils\exeflat. kernel.exe:$(TARGET).lnk $(OBJS) $(LIBS) $(LINK) @$(TARGET).lnk; -clobber:clean +clobber: clean -$(RM) kernel.exe kernel.sys status.me clean: @@ -54,8 +54,8 @@ clean: ECHOTO=..\utils\echoto -$(TARGET).lnk: turboc.cfg makefile ..\mkfiles\generic.mak ..\mkfiles\$(COMPILER).mak - -$(RM) *.lnk +$(TARGET).lnk: turboc.cfg makefile ..\mkfiles\generic.mak ..\mkfiles\$(COMPILER).mak + -$(RM) *.lnk *.obj $(ECHOTO) $(TARGET).lnk $(OBJS1)+ $(ECHOTO) $(TARGET).lnk $(OBJS2)+ $(ECHOTO) $(TARGET).lnk $(OBJS3)+ @@ -68,57 +68,52 @@ $(TARGET).lnk: turboc.cfg makefile ..\mk $(ECHOTO) $(TARGET).lnk $(LIBS) # *Individual File Dependencies* -apisupt.obj: apisupt.asm segs.inc$(TARGET).lnk -asmsupt.obj: asmsupt.asm segs.inc$(TARGET).lnk -console.obj: console.asm io.inc $(TARGET).lnk -dosidle.obj: dosidle.asm segs.inc$(TARGET).lnk -entry.obj: entry.asm segs.inc $(HDR)stacks.inc $(TARGET).lnk -execrh.obj:execrh.asm segs.inc$(TARGET).lnk -int2f.obj: int2f.asm segs.inc $(HDR)stacks.inc $(TARGET).lnk -intr.obj: intr.asmsegs.inc$(TARGET).lnk -io.obj:io.asm segs.inc$(TARGET).lnk -irqstack.obj: irqstack.asm segs.inc $(TARGET).lnk -kernel.obj:kernel.asm segs.inc ludivmul.inc $(TARGET).lnk -nls_hc.obj:nls_hc.asm segs.inc$(TARGET).lnk -nlssupt.obj: nlssupt.asm segs.inc$(TARGET).lnk -printer.obj: printer.asm io.inc $(TARGET).lnk -procsupt.obj: procsupt.asm segs.inc $(HDR)stacks.inc $(TARGET).lnk -serial.obj:serial.asm io.inc $(TARGET).lnk - -HDRS=\ -$(HDR)portab.h $(HDR)device.h $(HDR)mcb.h $(HDR)pcb.h \ -$(HDR)fat.h $(HDR)fcb.h $(HDR)tail.h $(HDR)time.h $(HDR)process.h \ -$(HDR)dcb.h $(HDR)sft.h $(HDR)cds.h $(HDR)exe.h $(HDR)fnode.h \ -$(HDR)dirmatch.h $(HDR)file.h $(HDR)clock.h $(HDR)kbd.h $(HDR)error.h \ -$(HDR)version.h dyndata.h -HEADERS=$(HDRS) globals.h proto.h -INITHEADERS=$(HDRS) init-mod.h init-dat.h - -blockio.obj: blockio.c$(HEADERS) $(TARGET).lnk -break.obj: break.c$(HEADERS) $(TARGET).lnk -chario.obj: chario.c $(HEADERS) $(TARGET).lnk -dosfns.obj: dosfns.c $(HEADERS) $(TARGET).lnk -dosnames.obj: dosnames.c $(HEADERS) $(TARGET).lnk -dsk.obj: dsk.c$(HEADERS) $(TARGET).lnk -error.obj: error.c$(HEADERS) $(TARGET).lnk -fatdir.obj: fatdir.c $(HEADERS) $(TARGET).lnk -fatfs.obj: fatfs.c$(HEADERS) $(TARGET).lnk -fattab.obj: fattab.c $(HEADERS) $(TARGET).lnk -fcbfns.obj: fcbfns.c $(HEADERS) $(TARGET).lnk -inthndlr.obj: inthndlr.c $(HEADERS) $(TARGET).lnk -ioctl.obj: ioctl.c$(HEADERS) $(TARGET).lnk -memmgr.obj: memmgr.c $(HEADERS) $(TARGET).lnk -misc.obj: misc.c $(HEADERS) $(TARGET).lnk -lfnapi.obj: lfnapi.c $(HEADERS) $(TARGET).lnk -newstuff.obj: newstuff.c $(HEADERS) $(TARGET).lnk -network.obj: network.c$(HEADERS) $(TARGET).lnk -nls.obj: nls.c$(HEADERS) $(TARGET).lnk -prf.obj: prf.c $(HDR)portab.h $(TARGET).lnk -strings.obj: strings.c $(TARGET).lnk -sysclk.obj: sysclk.c$(HEADERS) $(TARGET).lnk -syspack.obj: syspack.c $(HEADERS) $(TARGET).lnk -systime.obj: systime.c $(HEADERS) $(TARGET).lnk -task.obj: task.c$(HEADERS) $(TARGET).lnk + +apisupt.obj: apisupt.asm segs.inc +asmsupt.obj: asmsupt.asm segs.inc +console.obj: console.asm io.inc +dosidle.obj: dosidle.asm segs.inc +entry.obj: entry.asmsegs.inc $(HDR)stacks.inc +execrh.obj:execrh.asm segs.inc +int2f.obj: int2f.asmsegs.inc $(HDR)stacks.inc +intr.obj: intr.asm segs.inc +io.obj:io.asm segs.inc +irqstack.obj: irqstack.asm segs.inc +kernel.obj:kernel.asm segs.inc ludivmul.inc +nls_hc.obj:nls_hc.asm
[Freedos-kernel] mscl8.mak: bug?
Hi! __O\_/_\_/O__ /* MSC places uninitialized data into COMDEF records, that end up in DATA segment. this can't be tolerated in INIT code. _ O/~\ /~\O INITPATCH=..\utils\patchobj _DATA=IDATA DATA=ID BSS=ID DGROUP=I_GROUP CONST=IC ^^^-^^ May be, trouble with MSC in these namings? --- This SF.net email is sponsored by: The Robotic Monkeys at ThinkGeek For a limited time only, get FREE Ground shipping on all orders of $35 or more. Hurry up and shop folks, this offer expires April 30th! http://www.thinkgeek.com/freeshipping/?cpg=12297 ___ Freedos-kernel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-kernel
[Freedos-kernel] ioctl.c: bug
Hi! __O\_/_\_/O__ case 0x0b: /* skip, it's a special case. */ NetDelay = r-CX; if (!r-DX) NetRetry = r-DX; _ O/~\ /~\O Should be: if (r-DX) - see INT 21/440B description (if DX=h on entry, the retry count is left unchanged). --- This SF.net email is sponsored by: The Robotic Monkeys at ThinkGeek For a limited time only, get FREE Ground shipping on all orders of $35 or more. Hurry up and shop folks, this offer expires April 30th! http://www.thinkgeek.com/freeshipping/?cpg=12297 ___ Freedos-kernel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-kernel