Re: [Freedos-kernel] Kernel 2040 released
>> License evilness. Better to have the EDR DOS style >> hack for files above 4 GB file size than "that". > > Than what "that" ??? Isn't it the same thing ??? I thought there was some discussion about exfat or whatever the MS thing for big files on embedded devices is, as that is not FAT in the DOS sense at all and highly proprietary... >> How about 64 kB? > > Heh ??? DOS can read or write full 64 KiB I was only talking about cluster sizes, not about the amount of data that you can read or write in a single int 21 call. The latter is indeed 65535 bytes, but I would prefer a multiple of the cluster size or 4096. Also, a cache can extend reads (read-ahead) or pool writes to larger chunks. Limits for that depend on the BIOS, e.g. 1 track or 127 sectors for floppy or older BIOSes but more when using LBA - at least the int 13.42 and 43 data block uses a WORD for number of to be read or written sectors, but I doubt that any BIOS would be happy to transfer 65535 sectors (almost 32 MB) in one call ;-) >> I think some hacks even support 128 kB > > I would highly nonrecommend hacks using 128 KiB clusters > (maybe that's what you meant ?). Yes, and I agree. Even 64 kB clusters are a bit evil. Eric -- BlackBerry® DevCon Americas, Oct. 18-20, San Francisco, CA The must-attend event for mobile developers. Connect with experts. Get tools for creating Super Apps. See the latest technologies. Sessions, hands-on labs, demos & much more. Register early & save! http://p.sf.net/sfu/rim-blackberry-1 ___ Freedos-kernel mailing list Freedos-kernel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] Kernel 2040 released
> License evilness. Better to have the EDR DOS style > hack for files above 4 GB file size than "that". Than what "that" ??? Isn't it the same thing ??? > How about 64 kB? Heh ??? DOS can read or write full 64 KiB (DX=0 ??? or is it only 64'000 Byte's ???). > I think some hacks even support 128 kB I would highly nonrecommend hacks using 128 KiB clusters (maybe that's what you meant ?). -- ~~~ wow ~~~ -- Got Input? Slashdot Needs You. Take our quick survey online. Come on, we don't ask for help often. Plus, you'll get a chance to win $100 to spend on ThinkGeek. http://p.sf.net/sfu/slashdot-survey ___ Freedos-kernel mailing list Freedos-kernel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] Kernel 2040 released
Hi! >>> My silly FATPLUS.EXE maybe ??? >> Was that the hack to go above 4 GB file size? > NO: http://www.fdos.org/kernel/#fatplus License evilness. Better to have the EDR DOS style hack for files above 4 GB file size than "that". Or of course turn LTOOLS into a drive letter driver to support EXT2 filesystems directly in DOS :-D >> Better use a multiple of cluster size and a power of 2. > > 64 KiB ??? FYI: DOS extenders give better performance with 63.xxx KiB > than 32 KiB. That sounds VERY evil. Is the performance diff that big? How about 64 kB? I think some hacks even support 128 kB and to be honest, I would prefer a cache which joins I/O to chunks of 64, 128, 256... kB over having huge cluster sizes, because the latter means wasting a lot of space if you have many small files. You can say space is cheap today but you still lose performance in the further seek unless of course you have a SSD instead of a harddisk. Eric -- Got Input? Slashdot Needs You. Take our quick survey online. Come on, we don't ask for help often. Plus, you'll get a chance to win $100 to spend on ThinkGeek. http://p.sf.net/sfu/slashdot-survey ___ Freedos-kernel mailing list Freedos-kernel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] Kernel 2040 released
SORRY for the repost:
Anyone can please upload the __correct__ "HISTORY.TXT" file for the
2040 kernel release on some place where it is easily discoverable ?
Both SF and fdos.org ?
http://sourceforge.net/projects/freedos/files/Kernel/2040/
http://www.fdos.org/kernel/
http://sourceforge.net/apps/mediawiki/freedos/index.php?title=Unstable_Kernel_Branch&action=history
<<<--- {{delete}}
http://freedos.svn.sourceforge.net/viewvc/freedos/kernel/trunk/docs/history.txt?revision=1640&view=markup&sortby=date&pathrev=1640
--
~~~ wow ~~~
--
Got Input? Slashdot Needs You.
Take our quick survey online. Come on, we don't ask for help often.
Plus, you'll get a chance to win $100 to spend on ThinkGeek.
http://p.sf.net/sfu/slashdot-survey
___
Freedos-kernel mailing list
Freedos-kernel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] Kernel 2040 released
> > My silly FATPLUS.EXE maybe ??? > Was that the hack to go above 4 GB file size? NO: http://www.fdos.org/kernel/#fatplus > Evil... Anything is good in this word ? > > Almost documented: ATA-33 and XDMA > UDMA, probably. NO, XDMA 3.1. > Better use a multiple of cluster size and a power of 2. 64 KiB ??? FYI: DOS extenders give better performance with 63.xxx KiB than 32 KiB. -- ~~~ wow ~~~ -- Got Input? Slashdot Needs You. Take our quick survey online. Come on, we don't ask for help often. Plus, you'll get a chance to win $100 to spend on ThinkGeek. http://p.sf.net/sfu/slashdot-survey ___ Freedos-kernel mailing list Freedos-kernel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] Kernel 2040 released
And Bart is too quick, he already adjusted the watcom.mak so it just works. :-) Thank you, Jeremy -- 5 Ways to Improve & Secure Unified Communications Unified Communications promises greater efficiencies for business. UC can improve internal communications as well as offer faster, more efficient ways to interact with customers and streamline customer service. Learn more! http://www.accelacomm.com/jaw/sfnl/114/51426253/ ___ Freedos-kernel mailing list Freedos-kernel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] Kernel 2040 released
On Jul 20, 2011 1:37 PM, "Bernd Blaauw" wrote: > > Op 20-7-2011 3:50, Bart Oldeman schreef: > > It's probably best to make things explicit (unless the goal is a true > > Win32->DOS cross-compile), using DOS16 utilities, by changing the last > > part of mkfiles\watcom.mak to: > > > > CFLAGS1 = -os-s-wx-bt=dos > > > > # *Implicit Rules* > > .obj.exe: > > $(BINPATH)\wlink sys dos f $< lib > > $(SUPPL_LIB_PATH)\SUPPL_$(SHELL_MMODEL).LIB op q > > .c.obj: > > $(CC) $< @$(CFG) > > > > But I haven't tested this! > > And now the fun part: compiling on Windows x64. No support for running > 16bit programs at all. > > Thanks, worked like a charm (see below). It shouldn't be too difficult if someone actually wanted to (I use virtual machines with DOS and WinXP instead of my native Win7x64 so have no desire). The utilities all [except LOAD_ICD.exe] compile and seem to work properly with a simple wcl name.c after removing (or modifying) the #ifdef memory model to ensure far data pointers to build win32 versions (assuming Win32 version of Watcom used). I tested and committed Bart's suggestion above as it makes the build work much better and should have minimal impact on anyone else who might be building -- the big gotcha is that config.std (after copying to config.mak) needs to be modified to change ..\scripts\echoto $(CFG) $(INCLUDEPATH) to ECHO $(CFLAGS1) > $(CFG) as echoto treats = as a separator character same as space i.e. the -bt=DOS into -bt DOS. Jeremy -- 5 Ways to Improve & Secure Unified Communications Unified Communications promises greater efficiencies for business. UC can improve internal communications as well as offer faster, more efficient ways to interact with customers and streamline customer service. Learn more! http://www.accelacomm.com/jaw/sfnl/114/51426253/___ Freedos-kernel mailing list Freedos-kernel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] Kernel 2040 released
On 20 July 2011 13:36, Bernd Blaauw wrote: > And now the fun part: compiling on Windows x64. No support for running > 16bit programs at all. Sure, for that you *need* a true cross-compilation. Just like on Linux. The FreeDOS-kernel build's utility programs (patchobj.exe) are also 16-bit DOS if you compile on Windows, so I don't think anybody has used Windows x64 to compile the kernel yet. Bart -- 10 Tips for Better Web Security Learn 10 ways to better secure your business today. Topics covered include: Web security, SSL, hacker attacks & Denial of Service (DoS), private keys, security Microsoft Exchange, secure Instant Messaging, and much more. http://www.accelacomm.com/jaw/sfnl/114/51426210/ ___ Freedos-kernel mailing list Freedos-kernel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] Kernel 2040 released
Op 20-7-2011 3:50, Bart Oldeman schreef: > It's probably best to make things explicit (unless the goal is a true > Win32->DOS cross-compile), using DOS16 utilities, by changing the last > part of mkfiles\watcom.mak to: > > CFLAGS1 = -os-s-wx-bt=dos > > # *Implicit Rules* > .obj.exe: > $(BINPATH)\wlink sys dos f $< lib > $(SUPPL_LIB_PATH)\SUPPL_$(SHELL_MMODEL).LIB op q > .c.obj: > $(CC) $< @$(CFG) > > But I haven't tested this! And now the fun part: compiling on Windows x64. No support for running 16bit programs at all. -- 10 Tips for Better Web Security Learn 10 ways to better secure your business today. Topics covered include: Web security, SSL, hacker attacks & Denial of Service (DoS), private keys, security Microsoft Exchange, secure Instant Messaging, and much more. http://www.accelacomm.com/jaw/sfnl/114/51426210/ ___ Freedos-kernel mailing list Freedos-kernel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-kernel
[Freedos-kernel] Kernel 2040 released
On 19 July 2011 13:27, Kenneth J. Davis wrote: > On Sat, Jun 25, 2011 at 4:40 PM, Bernd Blaauw wrote: >> Op 25-6-2011 16:06, Kenneth J. Davis schreef: >>> Hello all. >>> > ... >> Are there any verified/stable working compiled versions available of the >> following? >> * COMMAND (there's an openwatcom CVS/SVN version somewhere?) > I finally managed to built the OW version (had issues with the utility > programs being built as win16 executables, so modified the makefiles > to build them as win32 [native], and have yet to build the installable > command loading program - didn't even know it existed) so you can now > find OW builds of command.com on fdos.org Thanks for testing! I haven't had the time to properly finish the port myself so I've been careful not to promote it too much... Anyway, yes: the sequence such as d:\watcom\BINW\wcc -zq mktools.c @watcomc.cfg d:\watcom\BINW\wlink f mktools.obj lib ..\SUPPL\SUPPL_s.LIB op q gives a win16 executable instead of the intended dos16 if %WATCOM% is set to d:\watcom\binnt instead of d:\watcom\binw. It's probably best to make things explicit (unless the goal is a true Win32->DOS cross-compile), using DOS16 utilities, by changing the last part of mkfiles\watcom.mak to: CFLAGS1 = -os-s-wx-bt=dos # *Implicit Rules* .obj.exe: $(BINPATH)\wlink sys dos f $< lib $(SUPPL_LIB_PATH)\SUPPL_$(SHELL_MMODEL).LIB op q .c.obj: $(CC) $< @$(CFG) But I haven't tested this! Bart -- 10 Tips for Better Web Security Learn 10 ways to better secure your business today. Topics covered include: Web security, SSL, hacker attacks & Denial of Service (DoS), private keys, security Microsoft Exchange, secure Instant Messaging, and much more. http://www.accelacomm.com/jaw/sfnl/114/51426210/ ___ Freedos-kernel mailing list Freedos-kernel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] Kernel 2040 released
On Sat, Jun 25, 2011 at 4:40 PM, Bernd Blaauw wrote: > Op 25-6-2011 16:06, Kenneth J. Davis schreef: >> Hello all. >> ... > Are there any verified/stable working compiled versions available of the > following? > * COMMAND (there's an openwatcom CVS/SVN version somewhere?) I finally managed to built the OW version (had issues with the utility programs being built as win16 executables, so modified the makefiles to build them as win32 [native], and have yet to build the installable command loading program - didn't even know it existed) so you can now find OW builds of command.com on fdos.org http://www.fdos.org/kernel/command/FreeCom/command.com Note: this has not been very well tested, especially given my changes to the build. > * SHARE (thought there were 2 versions or so?) the most up to date version is with the kernel (no recent changes, just latest source floating around put into svn) (as soon as I upload a build, latest will also be found at http://www.fdos.org/kernel/share/ ) ... Jeremy -- Magic Quadrant for Content-Aware Data Loss Prevention Research study explores the data loss prevention market. Includes in-depth analysis on the changes within the DLP market, and the criteria used to evaluate the strengths and weaknesses of these DLP solutions. http://www.accelacomm.com/jaw/sfnl/114/51385063/ ___ Freedos-kernel mailing list Freedos-kernel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] Kernel 2040 released
Op 10-7-2011 13:11, Eric Auer schreef: > > Hi dos386, > Ninja-ing thread here slightly: Can kernel 2040 please be mirrored to Ibilio? Can't be found yet at http://www.ibiblio.org/pub/micro/pc-stuff/freedos/files/dos/kernel/ -- All of the data generated in your IT infrastructure is seriously valuable. Why? It contains a definitive record of application performance, security threats, fraudulent activity, and more. Splunk takes this data and makes sense of it. IT sense. And common sense. http://p.sf.net/sfu/splunk-d2d-c2 ___ Freedos-kernel mailing list Freedos-kernel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] Kernel 2040 released
Hi dos386, >> PS: You could also compare EDRDOS+UIDE with FreeDOS+UIDE. > > IIRC I tested some caches in the past. Result: NO SPEEDUP at all for a > single big file. Maybe only helps with the sparse hack ;-) >> unless dos386 describes what program(s) he used > > My silly FATPLUS.EXE maybe ??? Was that the hack to go above 4 GB file size? Evil... >> on what hardware to produce these results > > Almost documented: ATA-33 and XDMA UDMA, probably. >> does not specify which int21 functions > > Block size 56 KiB | AH=$3F AH=$40 ??? > http://www.ctyme.com/intr/rb-2783.htm Hadn't known there would be more ... Better use a multiple of cluster size and a power of 2. >> Shouldn't it be sufficient to seek to the desired size (as offset), then > > do a write with length zero there? (Writing with length zero extends or > > truncates the file to the current seek offset.) > > Not yet tested the sparse hack ... my bad :-( I hope it helps :-) Eric -- All of the data generated in your IT infrastructure is seriously valuable. Why? It contains a definitive record of application performance, security threats, fraudulent activity, and more. Splunk takes this data and makes sense of it. IT sense. And common sense. http://p.sf.net/sfu/splunk-d2d-c2 ___ Freedos-kernel mailing list Freedos-kernel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] Kernel 2040 released
> It's history.txt inside the doc directory, inside the zip archive. No, it's outdated: 2011-04-09 ... http://freedos.svn.sourceforge.net/viewvc/freedos/kernel/trunk/docs/history.txt?revision=1640&view=markup&sortby=date&pathrev=1640 -- ~~~ wow ~~~ -- All of the data generated in your IT infrastructure is seriously valuable. Why? It contains a definitive record of application performance, security threats, fraudulent activity, and more. Splunk takes this data and makes sense of it. IT sense. And common sense. http://p.sf.net/sfu/splunk-d2d-c2 ___ Freedos-kernel mailing list Freedos-kernel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] Kernel 2040 released
Op 10-7-2011 3:10, dos386 schreef:
> Anyone can please upload the __correct__ "HISTORY.TXT" file for
> the 2040 kernel release on some place where it is easily discoverable ?
> Both SF and fdos.org ?
>
> http://sourceforge.net/projects/freedos/files/Kernel/2040/
It's history.txt inside the doc directory, inside the zip archive.
I'm still to test if DEVICEHIGH/SHELLHIGH and DEVLOAD /H work as
expected, with various kernels and devload versions.
Changes Jeremy
* r1501 sys/sys.c: correct return value from NULL to FALSE -
fix compile with OW1.9
* r1500 docs/sys.txt, sys/sys.c:
handle case when source not specified but filename for boot
sector is given (sys X: bootfile.bin)
+ Changes Bart
* r1569 kernel/{config.c,kernel.asm,init-mod.h,globals.h}:
Allocate bigger chunk of memory for INSTALL for __WATCOMC__
because the memory layout is different from other compilers.
Fixes issues mentioned by Bret Johnson and Christian Masloch
in freedos-user/freedos-kernel.
* r1568 kernel/asmsupt.asm, mkfiles/owlinux.mak: Make sure the
DOS native and Linux cross-builds produce identical binaries.
* r1567 drivers/rdpcclk.asm,kernel/{asmsupt,entry,irqstack,kernel,
nls_hc}.asm, kernel/makefile:
Remove useless END from nls_hc.asm, add explicit byte
overrides for older versions of NASM for more compact code,
and adjust silent relocation segments.
* r1565 sys/sys.c: Change // to /* comments for Turbo C compatibility.
* r1564 kernel/dosfns.c: If handle valid, close file in PSP
table before the low-level close + (perhaps) critical error.
Avoids closing the file twice (and hitting the critical
error twice) on abort/program termination.
Also, close can only return error 6 (DE_INVLDHNDL), not 5
(DE_ACCESS), see RBIL.
* r1563 kernel/task.c: From Christian Masloch:
set flags to 0x200 (IF set) when transferring to int22
termination address.
* r1562 kernel/fatfs.c: Check errors for callers of dir_write
and shrink_file. Fixes: Bug: File creation does not check
whether buffers are written correctly
(http://www.bttr-software.de/forum/forum_entry.php?id=9783)
* r1561 kernel/blockio.c, kernel/fatdir.c:
No longer force flush1() and dir_write_update() to return
TRUE if there were disk write errors. Part 1 for fixing
http://www.bttr-software.de/forum/forum_entry.php?id=9783
Bug: File creation does not check whether buffers are
written correctly
* r1560 kernel/kernel.asm:
Enlarge clock and block driver stacks. Thanks to Damien Guibouret
.
* r1559 kernel/fatfs.c: Fix value that is used before being initialised.
This lead to a drive to not be considered as FAT32 despite it is
(or vice-versa).
Thanks to Damien Guibouret .
* r1499 kernel/makefile:
With the stack changes the DOS segment has moved to 0x79.
* r1498 kernel/irqstack.asm:
New irqstack.asm: irq 2, 3, 4, 5, 6, 10, 11, 12, 14, 15 now
use the IBM interrupt sharing protocol for STACKS. Affect
int 2 too, but not IRQ 7 (INT 0fh) and IRQ 9 (INT 71h)
--
All of the data generated in your IT infrastructure is seriously valuable.
Why? It contains a definitive record of application performance, security
threats, fraudulent activity, and more. Splunk takes this data and makes
sense of it. IT sense. And common sense.
http://p.sf.net/sfu/splunk-d2d-c2
___
Freedos-kernel mailing list
Freedos-kernel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] Kernel 2040 released
> I am working on updating my site as I move files to my new host.
> www.fdos.org/kernel is updated.
Anyone can please upload the __correct__ "HISTORY.TXT" file for
the 2040 kernel release on some place where it is easily discoverable ?
Both SF and fdos.org ?
http://sourceforge.net/projects/freedos/files/Kernel/2040/
http://www.fdos.org/kernel/
http://sourceforge.net/apps/mediawiki/freedos/index.php?title=Unstable_Kernel_Branch&action=history
<<<--- {{delete}}
--
~~~ wow ~~~
--
All of the data generated in your IT infrastructure is seriously valuable.
Why? It contains a definitive record of application performance, security
threats, fraudulent activity, and more. Splunk takes this data and makes
sense of it. IT sense. And common sense.
http://p.sf.net/sfu/splunk-d2d-c2
___
Freedos-kernel mailing list
Freedos-kernel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] Kernel 2040 released
> PS: You could also compare EDRDOS+UIDE with FreeDOS+UIDE. IIRC I tested some caches in the past. Result: NO SPEEDUP at all for a single big file. > the data are useless :( NOT that bad ... > unless dos386 describes what program(s) he used My silly FATPLUS.EXE maybe ??? > on what hardware to produce these results Almost documented: ATA-33 and XDMA > does not specify which int21 functions Block size 56 KiB | AH=$3F AH=$40 ??? http://www.ctyme.com/intr/rb-2783.htm Hadn't known there would be more ... > Shouldn't it be sufficient to seek to the desired size (as offset), then > do a write with length zero there? (Writing with length zero extends or > truncates the file to the current seek offset.) Not yet tested the sparse hack ... my bad :-( -- ~~~ wow ~~~ -- All of the data generated in your IT infrastructure is seriously valuable. Why? It contains a definitive record of application performance, security threats, fraudulent activity, and more. Splunk takes this data and makes sense of it. IT sense. And common sense. http://p.sf.net/sfu/splunk-d2d-c2 ___ Freedos-kernel mailing list Freedos-kernel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] Kernel 2040 released
More tests: http://jafile.com/uploads/dos386/perftest.txt
>> unless dos386 describes what program(s) he used on what hardware
>> to produce these results, the data are useless :(
>>
>>> ...you can try first writing some dummy data at where the file
>>> will end, then close it and re-open (without truncate of course)
>>> and do the actual copy. That should bundle the FAT updates and
>>> increase performance significantly :-)
>> just did exactly this (for command.com) COPY.
>> unfortunately performance remains the same.
>>
>> for a single drive (that is able to read ~43 MB/sec), using
>> a copy buffer of 60K (Freecom default), copy performs
>> roughly identical, even if the file is pre-created.
> Please explain. You compiled a modified version of the built-in
> COPY command of command.com?
I inserted
static int BIGcopy(FILE *fout, FILE *fin)
{
...
startTime = *(unsigned far *)MK_FP(0x40,0x6c);
/* allocate destination file at start
a) might make copy faster because fat entries
can be allocated once
b) if destination is full no need to copy
many megabyte
*/
currentPos = lseek(fdout, 0, SEEK_CUR);
if (currentPos == -1l)
{
// can't seek
dprintf(("can't seek errno %d\n",errno);)
}
else {
if ( currentPos > 0xl - toCopy) // currentPos +
toCopy > 0xl
{ // outfile
too large ( > 4GB )
retval = 2;
goto _exit;
}
dprintf(("change size %lu\n",currentPos + toCopy);)
if (lseek(fdout, currentPos + toCopy-1,SEEK_SET) == currentPos +
toCopy - 1)
{
if(DOSwrite(fdout, " ", 1) != 1)
{
retval = 2;
goto _exit;
}
}
lseek(fdout, currentPos, SEEK_SET);
}
// end of preallocation code
while((rd = DOSread(fdin, buffer, size)) != 0) {
into copy. c
> My suggestion was to pre-grow the
> file, not only pre-create it. Something like, ca 2 GB example:
I would prefer code to suggestions.
use your keyboard to write code, not emails ;)
Mit freundlichen Grüßen/Kind regards
Tom Ehlert
+49-241-79886
--
All of the data generated in your IT infrastructure is seriously valuable.
Why? It contains a definitive record of application performance, security
threats, fraudulent activity, and more. Splunk takes this data and makes
sense of it. IT sense. And common sense.
http://p.sf.net/sfu/splunk-d2d-c2
___
Freedos-kernel mailing list
Freedos-kernel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] Kernel 2040 released
Hi Christian, >> - write 1 byte of data at this place > > Shouldn't it be sufficient to seek to the desired size (as offset), then > do a write with length zero there? (Writing with length zero extends or > truncates the file to the current seek offset.) Possibly, but I wanted to keep things simple and foolproof. >> - close the file >> - open file for writing (no truncate) > > I would suggest not to close and re-open the file. If it does improve the > operation's performance, then just committing the file should improve it > in the same way. If performance isn't improved by it, the close and > re-open sequence can be removed without replacement. Same reason as above. Also, there is a small chance that some implementations of commit are weaker than a full close / open. So I went for the more explicit and possibly safer style here. In any case, the performance penalty of close and re-open in a situation where pre-growing fails to help is very neglible. Eric -- All of the data generated in your IT infrastructure is seriously valuable. Why? It contains a definitive record of application performance, security threats, fraudulent activity, and more. Splunk takes this data and makes sense of it. IT sense. And common sense. http://p.sf.net/sfu/splunk-d2d-c2 ___ Freedos-kernel mailing list Freedos-kernel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] Kernel 2040 released
> - write 1 byte of data at this place Shouldn't it be sufficient to seek to the desired size (as offset), then do a write with length zero there? (Writing with length zero extends or truncates the file to the current seek offset.) > - close the file > - open file for writing (no truncate) I would suggest not to close and re-open the file. If it does improve the operation's performance, then just committing the file should improve it in the same way. If performance isn't improved by it, the close and re-open sequence can be removed without replacement. Regards, Christian -- All of the data generated in your IT infrastructure is seriously valuable. Why? It contains a definitive record of application performance, security threats, fraudulent activity, and more. Splunk takes this data and makes sense of it. IT sense. And common sense. http://p.sf.net/sfu/splunk-d2d-c2 ___ Freedos-kernel mailing list Freedos-kernel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] Kernel 2040 released
Hi Tom, >>> More tests: http://jafile.com/uploads/dos386/perftest.txt > unless dos386 describes what program(s) he used on what hardware > to produce these results, the data are useless :( > >> ...you can try first writing some dummy data at where the file >> will end, then close it and re-open (without truncate of course) >> and do the actual copy. That should bundle the FAT updates and >> increase performance significantly :-) > just did exactly this (for command.com) COPY. > unfortunately performance remains the same. > > for a single drive (that is able to read ~43 MB/sec), using > a copy buffer of 60K (Freecom default), copy performs > roughly identical, even if the file is pre-created. Please explain. You compiled a modified version of the built-in COPY command of command.com? My suggestion was to pre-grow the file, not only pre-create it. Something like, ca 2 GB example: - open and create a new file for writing - seek to offset ca 2 GB (works even though file is still empty) - write 1 byte of data at this place - close the file (this should allocate all clusters for a full 2 GB file in FAT) - open file for writing (no truncate) - file is now 2 GB but data is "random" contents of whatever was in the before-unused clusters unless your kernel was compiled with WRITEZEROS (normally not the case) - write 2 GB of normal data to the file in big chunks, preferrably with a copy buffer not wrapping a linear 64 kB offset and with a size which is a multiple of 1 cluster. (should only have to write data, FAT unchanged, few seeks, in particular if FAT data can use BUFFERS or a read cache) Eric PS: http://jafile.com/uploads/dos386/perftest.txt says the test involves R/W of one file of 2'400'000'000 Bytes but it does not specify which int21 functions or tools were used. -- All of the data generated in your IT infrastructure is seriously valuable. Why? It contains a definitive record of application performance, security threats, fraudulent activity, and more. Splunk takes this data and makes sense of it. IT sense. And common sense. http://p.sf.net/sfu/splunk-d2d-c2 ___ Freedos-kernel mailing list Freedos-kernel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] Kernel 2040 released
>> More tests: http://jafile.com/uploads/dos386/perftest.txt unless dos386 describes what program(s) he used on what hardware to produce these results, the data are useless :( > ...you can try first writing some dummy data at where the file > will end, then close it and re-open (without truncate of course) > and do the actual copy. That should bundle the FAT updates and > increase performance significantly :-) just did exactly this (for command.com) COPY. unfortunately performance remains the same. for a single drive (that is able to read ~43 MB/sec), using a copy buffer of 60K (Freecom default), copy performs roughly identical, even if the filr is pre-created. Tom -- All of the data generated in your IT infrastructure is seriously valuable. Why? It contains a definitive record of application performance, security threats, fraudulent activity, and more. Splunk takes this data and makes sense of it. IT sense. And common sense. http://p.sf.net/sfu/splunk-d2d-c2 ___ Freedos-kernel mailing list Freedos-kernel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] Kernel 2040 released
Hi! You tested copying a 2.2 GB file... > More tests: http://jafile.com/uploads/dos386/perftest.txt ...you can try first writing some dummy data at where the file will end, then close it and re-open (without truncate of course) and do the actual copy. That should bundle the FAT updates and increase performance significantly :-) Eric PS: You could also compare EDRDOS+UIDE with FreeDOS+UIDE. -- All of the data generated in your IT infrastructure is seriously valuable. Why? It contains a definitive record of application performance, security threats, fraudulent activity, and more. Splunk takes this data and makes sense of it. IT sense. And common sense. http://p.sf.net/sfu/splunk-d2d-c2 ___ Freedos-kernel mailing list Freedos-kernel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] Kernel 2040 released
I am working on updating my site as I move files to my new host. www.fdos.org/kernel is updated. But I only have a little bit of time that I split among development & website updates. -- All of the data generated in your IT infrastructure is seriously valuable. Why? It contains a definitive record of application performance, security threats, fraudulent activity, and more. Splunk takes this data and makes sense of it. IT sense. And common sense. http://p.sf.net/sfu/splunk-d2d-c2___ Freedos-kernel mailing list Freedos-kernel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] Kernel 2040 released
> Also available for download at fdos.org http://www.fdos.org/ > Content has not yet been moved to this host - please visit > http://www.fdos.info (mirror) in the meantime http://www.fdos.info/ > This page last updated - July 17, 2006 http://www.fdos.info/obten.html.en > FreeDOS Beta8 (Nikita) information. > jeme...@computer.org > June 09, 2002 Someone please look into the outdated pages ;-) -- ~~~ wow ~~~ -- All of the data generated in your IT infrastructure is seriously valuable. Why? It contains a definitive record of application performance, security threats, fraudulent activity, and more. Splunk takes this data and makes sense of it. IT sense. And common sense. http://p.sf.net/sfu/splunk-d2d-c2 ___ Freedos-kernel mailing list Freedos-kernel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] Kernel 2040 released
More tests: http://jafile.com/uploads/dos386/perftest.txt -- ~~~ wow ~~~ -- All of the data generated in your IT infrastructure is seriously valuable. Why? It contains a definitive record of application performance, security threats, fraudulent activity, and more. Splunk takes this data and makes sense of it. IT sense. And common sense. http://p.sf.net/sfu/splunk-d2d-c2 ___ Freedos-kernel mailing list Freedos-kernel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] Kernel 2040 released
> Kernel 2040 has been tagged and should be made available on > Sourceforge file releases within next few days It is now: http://sourceforge.net/projects/freedos/ + it does boot (no further tests yet) - "history.txt" is lowercase and not updated: > 2011 Apr xx - Build 2040 > Jeremy Davis, Bart Oldeman > + Changes Jeremy > * r1501 sys/sys.c: correct return value from NULL to FALSE - > fix compile with OW1.9 - some packages have bumped file dates, some not Even more outdated: http://sourceforge.net/apps/mediawiki/freedos/index.php?title=Unstable_Kernel_Branch -- ~~~ wow ~~~ -- All of the data generated in your IT infrastructure is seriously valuable. Why? It contains a definitive record of application performance, security threats, fraudulent activity, and more. Splunk takes this data and makes sense of it. IT sense. And common sense. http://p.sf.net/sfu/splunk-d2d-c2 ___ Freedos-kernel mailing list Freedos-kernel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] Kernel 2040 released
Op 25-6-2011 16:06, Kenneth J. Davis schreef: > Hello all. > > Kernel 2040 has been tagged and should be made available on > Sourceforge file releases within next few days. Nice to have an official updated kernel. > Also available for download at fdos.org: > installer compatible form - http://www.fdos.org/kernel/package/ > same as sf releases - http://www.fdos.org/kernel/release/LATEST/ So this is a release with new official versions of: * KERNEL * SYS * COUNTRY.SYS ( same as http://eduardocasino.es/index.php?option=com_content&view=category&layout=blog&id=4&Itemid=9 ? ) Are there any verified/stable working compiled versions available of the following? * COMMAND (there's an openwatcom CVS/SVN version somewhere?) * SHARE (thought there were 2 versions or so?) * NLSFUNC > Note: these releases have not been compiled with the memdisk > configuration checking as these are 8086 compatible builds. I will > make available 386+ builds with it enabled within a 386 subdirectory. Good to know, so we don't end up with a 386 kernel on bootdisks. Ofcourse the preference is a 'universal' kernel supporting everything :) > Thank you, > Jeremy Davis Just for fun, try the following 2 statements in config.sys at same time, execute both and try executing a file in path. !SET PATH=C:\FDOS\BIN 1?SET PATH=C:\FDOS\BIN Also interesting is DEVICE=C:\FDOS\BIN\JEMMEX.EXE NOEMS X=TEST FASTBOOT when booting from C:, followed by DIR A: Bernd -- All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity and more. Splunk takes this data and makes sense of it. Business sense. IT sense. Common sense.. http://p.sf.net/sfu/splunk-d2d-c1 ___ Freedos-kernel mailing list Freedos-kernel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-kernel
[Freedos-kernel] Kernel 2040 released
Hello all. Kernel 2040 has been tagged and should be made available on Sourceforge file releases within next few days. Also available for download at fdos.org: installer compatible form - http://www.fdos.org/kernel/package/ same as sf releases - http://www.fdos.org/kernel/release/LATEST/ Note: these releases have not been compiled with the memdisk configuration checking as these are 8086 compatible builds. I will make available 386+ builds with it enabled within a 386 subdirectory. Thank you, Jeremy Davis -- All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity and more. Splunk takes this data and makes sense of it. Business sense. IT sense. Common sense.. http://p.sf.net/sfu/splunk-d2d-c1 ___ Freedos-kernel mailing list Freedos-kernel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-kernel
