Re: [Freedos-kernel] FreeDOS disk I/O is much slower then MSDOS
> the FreeDOS kernel is seriously slower then MSDOS when doing > larger copy/xcopy operations. > the cause: the disk I/O code avoids transfers that cross a 64K > boundary, and splits these transfers into 3 (smaller) transfers. > this was needed for floppy controllers in the 1980's, but is certainly > not necessary for harddisks after the IBM XT. > just skip > /* avoid overflowing 64K DMA boundary */ > count = DMA_max_transfer(buffer, totaltodo); > for harddisks, and everything should be *much* faster (at least on > rotating media in a non-emulated machine) investigating in this a bit more, the 64K boundary was/is a problem with ISA DMA, used only for floppies (and sometimes serial/parallel ports), but is no problem for UDMA. skipping this test for drives with 0x80 set should be save, and result in a significant speedup of large disk transfers. Tom ___ Freedos-kernel mailing list Freedos-kernel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-kernel
[Freedos-kernel] FreeDOS disk I/O is much slower then MSDOS
Hi everybody, the FreeDOS kernel is seriously slower then MSDOS when doing larger copy/xcopy operations. the cause: the disk I/O code avoids transfers that cross a 64K boundary, and splits these transfers into 3 (smaller) transfers. this was needed for floppy controllers in the 1980's, but is certainly not necessary for harddisks after the IBM XT. just skip /* avoid overflowing 64K DMA boundary */ count = DMA_max_transfer(buffer, totaltodo); for harddisks, and everything should be *much* faster (at least on rotating media in a non-emulated machine) Tom ___ Freedos-kernel mailing list Freedos-kernel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-kernel
[Freedos-kernel] Checking NUL directory/drive is broken in 2042
if exist K:\NUL echo K: is present
is broken in kernel 2042
the bug is caused by a change in TrueName(), where code was changed
from
cdsEntry = get_cds(result);
if (cdsEntry == NULL)
return DE_PATHNOTFND;
to
dhp = IsDevice(src);
cdsEntry = get_cds(result);
if (cdsEntry == NULL)
{
/* workaround for a device prefixed with invalid drive (e.g. "@:NUL") */
/* (MS-DOS always return drive P: for invalid drive. Why P:?) */
if (dhp)
{
result = default_drive;
cdsEntry = get_cds(result);
if (cdsEntry == NULL)
return DE_PATHNOTFND;
}
else
return DE_PATHNOTFND;
}
now truename("e:\NUL") returns not 'path not found', but 'isDevice'
probably by fixing one bug, another bug was introduced.
Unfortunately I don't know what bug the changed is supposed to fix...
who introduced this change and why?
comments?
Tom
___
Freedos-kernel mailing list
Freedos-kernel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] boot sector woes
am 1. Februar 2017 um 01:23 schrieben Sie: > this patch is a suggestion for the bootsector to boot on older (like my XT) > machines > where the drive requires a few retries before loading a sector. The > resulting binary > might be too big actually. that is a clear indication that you did not test this. why do you expect that we do YOUR work ? Tom > In this case I would like a bit of help fitting it in there. > yours, > - Mdasoh Kyaeppd > --- boot.ori/boot.asm 2017-01-30 02:08:55.835437500 -0700 > +++ boot/boot.asm 2017-01-31 13:06:37.742679500 -0700 > @@ -423,7 +423,7 @@ > ; setup LBA disk block > mov LBA_SECTOR_32,bx; bx is 0 if extended 13h > mode supported > mov LBA_SECTOR_48,bx > - > + mov si,1 > mov ah,042h > jmp shortdo_int13_read > @@ -472,12 +472,20 @@ > inc cx ; make sector 1-based (1-63) > les bx,[LBA_OFF] > + mov si,5 > +do_chs_read: > mov ax, 0x0201 > do_int13_read: > mov dl, [drive] > -int 0x13 > -jc boot_error ; exit on error > +int 0x13 ; read data from disk > + jnc did_int13_read > + xor ax,ax > + int 0x13 > + dec si > +jz boot_error ; exit on error > + jmp do_chs_read ; prod it a few times > +did_int13_read: > mov ax, word [bsBytesPerSec] > pushdi > -- > Check out the vibrant tech community on one of the world's most > engaging tech sites, SlashDot.org! http://sdm.link/slashdot > ___ > Freedos-kernel mailing list > Freedos-kernel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/freedos-kernel Mit freundlichen Grüßen/Kind regards Tom Ehlert +49-241-79886 -- Check out the vibrant tech community on one of the world's most engaging tech sites, SlashDot.org! http://sdm.link/slashdot ___ Freedos-kernel mailing list Freedos-kernel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] Checking NUL directory/drive is broken in 2042
Hi, > Was using FreeDOS 1.1 2040 kernel? previously and could check for > drive or directory existence with the NUL device: > If exist c:\nul echo C: exists > If exist c:\mydir\nul echo C:\mydir exists > This behavior is broken with 2042, no longer being able to identify if a > drive/dir exists anymore. I tried to reproduce this here, and I think that it behaves exactly as it should. can you be more specific how it fails ? Tom -- Check out the vibrant tech community on one of the world's most engaging tech sites, SlashDot.org! http://sdm.link/slashdot ___ Freedos-kernel mailing list Freedos-kernel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] Can the Kernel start my program instead of command.com?
>>From the point of view of protecting this system from counterfeiting & > unauthorised access, is it possible to interrupt processing config.sys? I > had read about pressing F5 to bypass config.sys and autoexec.bat. Also that > this can be disabled in config.sys. modify kernel.sys by using sys config kernel.sys SKIPCONFIGSECONDS=-1 to disable F5/F8 completely. OTOH, removing command.com will also completely disable tinkering with the system. > Another thought I have - what would the behaviour of the kernel be if my > program (as the command processor) does terminate? Does it reboot, restart > the command processor, or just hang? most likely just hang. test yourself. Tom -- Developer Access Program for Intel Xeon Phi Processors Access to Intel Xeon Phi processor-based developer platforms. With one year of Intel Parallel Studio XE. Training and support from Colfax. Order your platform today.http://sdm.link/xeonphi ___ Freedos-kernel mailing list Freedos-kernel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] UMB question
> Hi kernel experts, > I vaguely remember that there is a pending patch where the kernel > is using a memcopy-style function residing in memory that already > got "freed" at that moment during boot, to be precise: during INSTALL= > so I guess the gurus are awake at the moment... > QUESTION: Would it be possible to improve UMB handling such that > the kernel supports SEVERAL providers of UMB at the same time, for > example UMBPCI for hardware-UMB and in addition EMM386 to "map" a > few more UMB to areas where normally a memory gap would be, such > as the "monochrome video memory" area? UMBPCI is nice if you want to avoid EMM386 but have some UMB EMM386 is nice in all other circumstances. it just doesnt't make much sense to have both UMBPCI and EMM386 active at the same time. if only for the reason that UMBPCI UMBs are only *sometimes* able to support DMA, while EMM386 UMBs are always able to use DMA, *provided you use VDMA services* (important for network chips). > Might be interesting to have even more UMB flexibility :-) yes. wasting precious developer ours on useless suff and hear them swear. very interesting indead. definitively not worth the trouble. Tom -- Attend Shape: An AT&T Tech Expo July 15-16. Meet us at AT&T Park in San Francisco, CA to explore cutting-edge tech and listen to tech luminaries present their vision of the future. This family event has something for everyone, including kids. Get more information and register today. http://sdm.link/attshape ___ Freedos-kernel mailing list Freedos-kernel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] BUG: problems with INSTALL=, reported by Bret Johnson
the problem, brought up by Bret:
during config.sys processing,
INSTALL= \freedos\MEM.EXE /F
will report ~24 K used at 99f0:0
however the kernel will crash if memory below this is overwritten.
source for the bug:
CONFIG.C, DoInstall() sets up a memory arena, and releases memory
below the INIT CODE segment, based on the assumption that 'normal' code
is no longer needed. this is *almost* true.
unfortunately
STATIC void kernel()
{
CommandTail Cmd;
strcpy(master_env, "PATH=.");
fmemcpy(MK_FP(DOS_PSP + 8, 0), master_env, sizeof(master_env));
memset(Cmd.ctBuffer, 0, sizeof(Cmd.ctBuffer));
strcpy(Cmd.ctBuffer, Config.cfgInitTail);
will use strcpy() and memset(), located at CS:11ee and freed by
DoInstall, and potentially overwritten.
probably the easiest solution: write some quick
init_memcpy() ...
to be used at *this* location by Kernel().
I'm away for a week; will continue work when back.
Tom
--
What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic
patterns at an interface-level. Reveals which users, apps, and protocols are
consuming the most bandwidth. Provides multi-vendor support for NetFlow,
J-Flow, sFlow and other flows. Make informed decisions using capacity
planning reports. https://ad.doubleclick.net/ddm/clk/305295220;132659582;e
___
Freedos-kernel mailing list
Freedos-kernel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] Kernel 2042 release
> INTERLINK issue has not been resolved, and still requires > option to load low. Why not? crashing the kernel when a driver calls DosAlloc() is not so smart an idea. disabling dosalloc for drivers is possibly suboptimal, but at least prevents a crashing kernel. of course a better fix would be nice but I won't hold my breath. IMO planning a 'release' with a known problem AND fix is stupid. Tom -- Mobile security can be enabling, not merely restricting. Employees who bring their own devices (BYOD) to work are irked by the imposition of MDM restrictions. Mobile Device Manager Plus allows you to control only the apps on BYO-devices by containerizing them, leaving personal data untouched! https://ad.doubleclick.net/ddm/clk/304595813;131938128;j ___ Freedos-kernel mailing list Freedos-kernel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] [Freedos-user] INTERLINK
Hi, https://sourceforge.net/p/freedos/bugs/147/ located the bug in freedos kernel. this the first driver *at all* that uses dos_alloc (int 21 ah=48) INTERLNK.EXE does (pseudocode) is running at 426:2951 if (dos_version < 5)// try load high to UMB goto continue_load; 426:2965 seg = dos_alloc(driversize);// driversize ~= 2f0 para JC continue_load // // move driver up to UMB // relocate interrupt vectors, driver list, ... continue_load: unfortunately dos_alloc(driversize) succeeds, but returns 425 - the very segment the driver is currently running at. OUCH! MCB looks like 2D3:0 'M' --> 4d3:0 'Z' 2 problems: the space for the driver is not allocated while the driver is loaded INTERLNK does tries to get some UMB memory, but has not called INT21 AH=58. why would MSDOS return MCB memory? while this is a real bug, I'm not certain this should be fixed as rethinking the driver load and memory allocation at init time is far from trivial. Tom am 5. Februar 2016 um 18:05 schrieben Sie: > Have tried with latest* kernel, there is a fixed bug in int 25/26 that may > effect it. > You may want to try RIFS as well, it has source, but I don't > recall if it used serial, parallel, or either but did work with > FreeDOS kernel as well as it did with PCDOS. > * I'm releasing updated version this weekend if time permits after I commit > changes from git to svn. > On Feb 5, 2016 11:04 AM, "Tom Ehlert" wrote: > Bret, > >> Eric/Tom: > >> I used to use INTERxxx a lot many years ago using the special >> parallel cables designed for that purpose (I think I still have a >> couple of those cables in my "spare cable box"). Parallel is MUCH >> faster than serial (null modem) cables. > I also used it *A LOT*. in times when there were no network cards a > commodity. (the times they are a changing ...) > >> I believe Eric is correct when he says INTERxxx is sector-based >> rather than file-based as Tom states. I do know that the client >> (INTERLNK) must be capable of "understanding" the file system of the >> server (INTERSVR). For example, if the client is MS-DOS 6.2 (which >> doesn't understand FAT32) and the server is MS-DOS 7.x (which does >> understand FAT32) and you're trying to access a FAT32 disk on the >> server, it doesn't work. I know this for sure because I've tried >> it. If INTERxxx was file-based, it wouldn't matter which version of >> FAT was on either computer (and could even work on non-FAT drives >> the server had mounted, like CD's and network drives). > > you are right, my memory was plain wrong on this. > > and - while debugging the crashing problem - I also saw that it > installs itself as handler for INT 25/26 'DOS DISK READ/WRITE' > > Tom > > > > -- > Site24x7 APM Insight: Get Deep Visibility into Application Performance > APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month > Monitor end-to-end web transactions and take corrective actions now > Troubleshoot faster and improve end-user experience. Signup Now! > http://pubads.g.doubleclick.net/gampad/clk?id=272487151&iu=/4140 > ___ > Freedos-user mailing list > freedos-u...@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/freedos-user > Mit freundlichen Grüßen/Kind regards Tom Ehlert +49-241-79886 -- Site24x7 APM Insight: Get Deep Visibility into Application Performance APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month Monitor end-to-end web transactions and take corrective actions now Troubleshoot faster and improve end-user experience. Signup Now! http://pubads.g.doubleclick.net/gampad/clk?id=272487151&iu=/4140 ___ Freedos-kernel mailing list Freedos-kernel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] FreeDOS and redirectors
> I wanted to ask: to what degree does FreeDOS implement the redirector > interface? Are there any known incompatibilities? it should right work. all known redirectors CD/DVD drivers MS Lan Manager NTFSDOS NTFS4DOS VMSMOUNT (with source) for DOS work without (known) problems > This also requires that any protected mode memory manager (EMM386 etc) > implements the DOS VDS (Virtual DMA Service, INT 4Bh AH=81h) API. VDS is supported. Tom -- ___ Freedos-kernel mailing list Freedos-kernel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] hmmmm
> Sorry for the link I haven't used thus machine to send emails in a long > time. The antivirus tags it with it. I had suspected that I wouldn't > be able to kernel merge, but it's nice to have thoughts. The multiuser > will have to wait whilst I wait on the response from Caldera, They have > an open source codebase that is not gpl compatible. the Caldera DRDOS is not very open at all; they published the source for the kernel exactly once, with no source release before or after. > Maybe they would > change the licensing or discuss possibilities since I asked. extremely unlikely; other people tried this (~10 years ago) > I could > ask for the DOS 4.0 codebase instead. Seems reasonable. good luck, but don't hold your breath Tom -- ___ Freedos-kernel mailing list Freedos-kernel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] EXT3 support
> I am interested in writing a new driver, one that would allow you to > boot and run dos on a EXT3 partition. booting from EXT3 would require to make EXT3 part of the kernel. not going to happen. otoh there is virtually no disadvantage to have a loadable TSR to make EXT3 available as a redirector. > In your other message you said > that ETX3 was a multithreaded fs. In that case it would be wiser to > first add multithreaded support to the FreeDOS kernel. It will be > hard, but well worth the time I believe. don't wait for multithreading support from kernel. in the good old times, when DOS was still active, disk caching software implemented 'multithreading' by chaining into TIMER and IDLE interrupts. just because so far no FreeDOS disk cache supports write caching doesn't mean it doesn't exist Tom -- ___ Freedos-kernel mailing list Freedos-kernel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] EXT3 support
> Maybe, but ext3 was designed as a multithreading FS. The > multithreading becomes single threading so performance would far > worse, and possibly even worse than FAT16/32 or ext3 of course a multithreading FS (read ahead and write behind caching) has a huge number of advantages which aren't available in a DOS based kernel, be it FAT or EXT. > over redirector. I very much doubt that the influence redirector or not is relevant, for speed anyway. Tom -- ___ Freedos-kernel mailing list Freedos-kernel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] Questions about Kernel editions
> I am an E.E./Comp. Sci. student, but I want to contribute to the FreeDOS > Kernel. Would it be fine if I began setting up a multiuser/multitasking > system like Digital Research's DOS 5, and begin the work to get Forth > into the kernel? the kernel is definitively not the right place to integrate Forth into, be it multiuser or not. there is zero disadvantage to have FORTH.EXE doing all the magic of course feel free to experiment (thats one of the reasons open source exists), but the the probablity that this would ever get integrated into the FreeDOS kernel has 8 leading zero's > This email has been checked for viruses by Avast antivirus software. > https://www.avast.com/antivirus whenever I read emails like this, I wonder what prevents a virus from adding such a line to its malicious postings ;) Tom -- ___ Freedos-kernel mailing list Freedos-kernel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] removing functions?
> If I want to remove fdconfig.sys support, break, numlock, echo, switches, > country, HLT idle, and menus in CONFIG.SYS options, > and hardcoded NLS page, and all NLS stuff(replaced with stub) > How much I can shrink? a) how much of what? filesize of kernel.sys? resident memory used? b) take a look at kernel.map. *all* of NLS is ~500 byte probably 500 byte for menus etc., maybe 1K after compression, probably less then 1 K reduction in filesize. certainly not worth the trouble or even worth talking about Tom -- Dive into the World of Parallel Programming. The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials and more. Take a look and join the conversation now. http://goparallel.sourceforge.net/ ___ Freedos-kernel mailing list Freedos-kernel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] Regarding Issue with FreeDOS.
> We were working on PDOS development particularly interrupt number > Int 21/AH=0Eh(Select Default Drive). While testing the PDOS function > i came across a particular behaviour in FreeDOS, according to the > description given in the documentation > "http://www.ctyme.com/intr/rb-2570.htm"; > > "Return: AL = number of potentially valid drive letters". > > When tested using a function PDOS returns, > > Booting from Hard Disk... > welcome to PDOS-16 > welcome to pcomm > C:\>>functest > > The return value is x 4 x > C:\>> > > While testing the same behaviour in FreeDOS, > C:\DEVEL\PDOS\SRC>>functest > > The return value is x 5 x it would help if you would tell us what PDOS is. besides this, http://www.ctyme.com/intr/rb-2570.htm states 'the return value is the greatest of 5, the value of LASTDRIVE= in CONFIG.SYS, and the number of drives actually present' and max(5, x) can't be smaller then 5 > Is this expected? Please let me know if anybody needs more details. yes Tom -- Want excitement? Manually upgrade your production database. When you want reliability, choose Perforce Perforce version control. Predictably reliable. http://pubads.g.doubleclick.net/gampad/clk?id=157508191&iu=/4140/ostg.clktrk ___ Freedos-kernel mailing list Freedos-kernel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] [Freedos-user] Any interest in 486, 586, 686 kernels?
> I'm not sure how you can say the FreeDOS project isn't interested in a BC5 > kernel. because I was around when the kernel was ported to MSVC, BC5, OW (in that order) > The BC5 makefiles I found in the kernel sources I didn't write. > Bart last worked on them 9 years ago. right. an since OW became an *free* option, MSVC and BC were dropped >Bit rotten for sure the last time I checked bits don't rot >and OW became > usable in that time. So yes, priorities change, but I'm taking the posted > FreeDOS Roadmap, as goals and stretch goals for the project. I read > (paraphrasing): built-in networking, built-in USB, integrated DPMI, 32-bit > & 64-bit support, device driver imports, automated regression testing. all great - and so far off reality that is isn't even funny. is was never even discussed, let alone agreed upon. > I've > done a couple of simple tests and I am getting 32-bit register code from my > copy of BC5. of course this is a huge step towards 'built in USB, 64 bit, bla' > The Roadmap is reason enough for me, personally, to continue > to 'experiment' as you say. There's no way of getting 32-bit real mode > code from OW. OW outputs enough 32-bit real mode code to get the job done. is the BC5 code smaller/faster in a significant way ? > Again, I'm not doing any porting. And I do intend to work this issue. > However, software development, like many human endeavors, is best done > collaboratively & socially, IMO. If someone in the last 9 years has > compiled the kernel with BC5, they might have tips for me. Heck, I > remember when the kernel was TASM/BC only, and only a select few could > afford to contribute. I advocated back then (almost 15 years ago) for > porting to open tools. I'm glad the early FreeCOM/Kernel developers had > made the effort to port to open tools. it was a pleasure ;) tom -- Try New Relic Now & We'll Send You this Cool Shirt New Relic is the only SaaS-based application performance monitoring service that delivers powerful full stack analytics. Optimize and monitor your browser, app, & servers with just a few lines of code. Try New Relic and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_may ___ Freedos-kernel mailing list Freedos-kernel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] Any interest in 486, 586, 686 kernels?
> What's the difference between wcc & wcc386? code generation for 16 bit (DOS) or 32 bit (windows) > Does wcc386 generate code that could be used in the kernel? no >> Big wins could be had on 586 with FPU memcpy 64-bit versus the 16-bit asm >> in the kernel now and possibly the string functions. But just an idea >> right now. the kernel doesn't copy (much). nothing to be gained. tom -- Get 100% visibility into Java/.NET code with AppDynamics Lite It's a free troubleshooting tool designed for production Get down to code-level detail for bottlenecks, with <2% overhead. Download for free and get started troubleshooting in minutes. http://p.sf.net/sfu/appdyn_d2d_ap2 ___ Freedos-kernel mailing list Freedos-kernel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] Any interest in 486, 586, 686 kernels?
> Kernels with FAT32: > 086: 68358 bytes > 186: 67180 bytes (286 same) > 386: 66044 bytes > 486: 65948 bytes (586 and 686 same) > It is interesting that even 186 instructions do make a > quite big difference and that there is a difference at > all between 386 and 486. With 186, you get pusha and > popa, shift/rotate by fixed numbers of bits. ENTER LEAVE > In the past, we compiled kernels for 8086, 186 and > 386 separately afair. I guess we got lazy and have > dropped 186 because very few users have 186/286 as > their CPU? They either have modern or REALLY old. this is not about 'lazy' it's easier for the user to select between 2 choices then between 4. multiply by 2 (FAT16/FAT32), this is 4 or 8 kernels. there's not much use for a 186 kernel as NOBODY has 186/286 machines these days, > Also, we keep offering 8086 compiles for the sake > of good old times and for people with emulators. > The 386 optimization is useful and we already used > it: Having 32 bit computations helps even for DOS. > There are also some new bit string opcodes, SETCC > (conditional set a byte) nothing of this is used by the compiler > JCXZ was always supported > and near conditional > jumps and loops that are supported starting at 386. *far* conditional jumps started with 386. however what *IS* used by wcc is the additional FS and GS register some (few) push DWORD constant what would be useful, but is not used by WCC dword arithmetic filesystem code uses long variables everywhere > Your 486 to 686 kernels are the same size and 486s > only XADD and BSWAP (and CMPXCHG). It is impressive > that those actually make any (100 byte) difference! strange enough, compiling here with -3 and -6 makes exactly no difference. using watcom 1.9 could you post the compiled files, or even for %i in (*.obj) do wdis -l -a -s %i for -3 and -6 and show us the differences ? > Maybe your compiles assume that 486 does and 386 > does not have FPU? That would not be very accurate. pointless as the kernel doesn't use any FPU code > As with 286, the news in 586 is mostly protected > mode related (simply speaking). Neither CMPXCHG8B > nor the time stamp counter nor CPUID bothers DOS. > The main news in 686 would be CMOV, a conditional > MOV, but looking only at kernel sizes, it is likely > that the compiler just does not use CMOV for 686. > It is odd to get exactly the same size otherwise. it doesn't use cmov > For even newer CPU, you could use FPU and vector > (MMX, SSE, SSE2, SSE3, SSE4a, EMMX, 3dNow, 3dNow+, > SSE4.1, SSE4.2, AVX FMA, not AES ;-)) instructions > but it is highly unlikely that those make any DOS > difference. At most they could speed up memmove. as the kernel doesn't much memcpy/memmove, you can't accelerate it by any significant amount.otherwise we *would* have rep movsD tom -- Get 100% visibility into Java/.NET code with AppDynamics Lite It's a free troubleshooting tool designed for production Get down to code-level detail for bottlenecks, with <2% overhead. Download for free and get started troubleshooting in minutes. http://p.sf.net/sfu/appdyn_d2d_ap2 ___ Freedos-kernel mailing list Freedos-kernel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] Kernel 2041 and Singlestepping the FDCONFIG.SYS.
> I use the Kernel 2041 and found follow strange: > If I press the key for singlestepping and then the key to skip a > command, the > singlestepping-process of the FDCONFIG.SYS is skipped. I implemented it this way because AFAICT MSDOS 6.2 behaves this way > Under MS-DOS the key skips only the current command and > doesn't skip the singlestepping-process. I may be wrong (it's a lonnng time ago), but I'm fairly sure that ESC finishes config.sys single stepping for MSDOS 6.2 > Under the commando-processor (I use the FreeCOM) the key > skips only the current command, too. that's a completely different thing > I think to skip the singlestepping-process is a good thing, but its better to > do this with another > key, like the key. better: use the same key that MSDOS uses. what is the MSDOS key for that ? Tom -- LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial Remotely access PCs and mobile devices and provide instant support Improve your efficiency, and focus on delivering more value-add services Discover what IT Professionals Know. Rescue delivers http://p.sf.net/sfu/logmein_12329d2d ___ Freedos-kernel mailing list Freedos-kernel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] Regarding commit 1702 (large sector sizes)
> that has low priority imho, as drives with large sectors > are a temporary thing, will be gone with GPT partitions. MBR partitioned disks will be gone shortly after the famous gate A20 is gone ;) currently *visible* 4KB sectors exist for a single purpose: to support disks > 2TB for Windows XP. therefore some USB drives to support disks > simulate 4KB sectors, even if the disk itself has to support disks > 512 Byte sectors. Even if the underlyying disk has really 4K sectors, all disks emulate 512 Byte sector size, so they can be used to boot Windows XP. as Windows XP can handle secondary disks with sector size > 512, we will see many USB adapters simulating sectors > 512. the Western Digital 3TB in 'My Book Essential' seems to have even 8K sectors. Tom -- Keep Your Developer Skills Current with LearnDevNow! The most comprehensive online learning library for Microsoft developers is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, Metro Style Apps, more. Free future releases when you subscribe now! http://p.sf.net/sfu/learndevnow-d2d ___ Freedos-kernel mailing list Freedos-kernel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] Regarding commit 1702 (large sector sizes)
>> Dear PerditionC, >> >> UBYTE DiskTransferBuffer[MAX_SEC_SIZE]; >> >> wastes 3,5 KB low memory for *everybody*, not only when it's needed. >> regarding how much time we have spend until we had 64 byte free >> I think this is a bad idea > please see my previous messages, I know exactly how much space is > wasted and clearly stated this along with statement 512 will be > default (and was already changed to such earlier) >> >> I also think that these experiments should NOT be in the stable >> branch. >> >> fork it, and make another 'unstable' branch if you want to experiment, >> but don't experiment with code that is supposed to be stable. >> >> Regards, Tom >> > These are not experiments, these are - in the current state - even useless experiments. > this is me working to improve compatibility > with MSDOS and existing though rare disks. a) the only problematic disks have a 4K sectors. your fix doesn't work with them. b) these disks don't exist, as there is currently no USB stack that supports 4K sectors I don't mind if you work on an unstable branch, or on your own local copy of the freedos kernel. however generating AGAIN an unstable kernel 2041 is a real bad idea. and tagging current state (after the questionable 1705) '2041' without further discussion is shit. Tom -- Keep Your Developer Skills Current with LearnDevNow! The most comprehensive online learning library for Microsoft developers is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, Metro Style Apps, more. Free future releases when you subscribe now! http://p.sf.net/sfu/learndevnow-d2d ___ Freedos-kernel mailing list Freedos-kernel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] Regarding commit 1702 (large sector sizes)
Dear PerditionC, UBYTE DiskTransferBuffer[MAX_SEC_SIZE]; wastes 3,5 KB low memory for *everybody*, not only when it's needed. regarding how much time we have spend until we had 64 byte free I think this is a bad idea I also think that these experiments should NOT be in the stable branch. fork it, and make another 'unstable' branch if you want to experiment, but don't experiment with code that is supposed to be stable. Regards, Tom -- Keep Your Developer Skills Current with LearnDevNow! The most comprehensive online learning library for Microsoft developers is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, Metro Style Apps, more. Free future releases when you subscribe now! http://p.sf.net/sfu/learndevnow-d2d ___ Freedos-kernel mailing list Freedos-kernel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] USB-HDD booting and LBA-to-CHS conversion
Hi Ranieri, try SYS CONFIG KERNEL.SYS FORCELBA=1 after that SYS CONFIG KERNEL.SYS to list current option this will force the freedos kernel.sys to always use LBA and ignore CHS completely. Tom am 7. Juli 2011 um 15:41 schrieben Sie: > I'm really sorry, I admit my description was quite confusing. All of > this is not exactly a problem to me, I could just format the pendrive > with the desktop BIOS geometry 974/128/63 and be done with it. I am > just being stubborn, trying to understand if there is a technical > reason that FreeDOS refuses this convoluted setup, while the other > loaders accept it, even MS-DOS. The following is not in chronological > order. > I have created a tiny 8 MB partition in the end of the desktop's hard > disk. I can boot FreeDOS from there and I also have copied Grub4dos > files to this partition. > My pendrive has syslinux in the partition boot sector. I have copied > FreeDOS files to its root and tried to chainload into it. Only on the > notebook everything works fine, because it sees the same geometry as > in the MBR. On the desktop syslinux boots, I can chainload FreeDOS > kernel, there is the expected WARNING about geometry, but COMMAND.COM > cannot be found on the pendrive partition. I must point it to the copy > of COMMAND.COM on the hard drive partition. > When I load FreeDOS from the hard drive, the pendrive partition gets a > drive letter but I cannot list its contents correctly. From here I can > run Grub4dos on the hard disk, then in its command line I can list the > contents of the pendrive. I can also: > - chainload the pendrive boot sector to get syslinux boot prompt. Then > I use the chain.c32 module to > - load FreeDOS from the pendrive > - or chainload back into the hard drive partition. > Except for swapped partition letters and drive numbers, it is the > same as booting from the pendrive. > - memory-map a floppy image with FreeDOS. Same thing, pendrive inaccessible. > - memory-map a MS-DOS 7.1 floppy image. It can see the pendrive correctly. > -- > 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 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
>>>> 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
>> 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 working, not SYS
Hallo Herr Ibidem,
am 1. April 2011 um 07:56 schrieben Sie:
> I tried building svn revision 1560 with Turbo C 2 and a 16-bit nasm
> 0.9x (FAT32/186). It started building, but then when build.bat hit
> SYS, I got this:
> Error sys.c 629: Expression syntax in function initOptions
> I REM'd out SYS (I have a working install and grub4dos), built the
> kernel, rebooted, loaded the kernel via grub4dos, and ran a few tests:
> SELFOWNT.COM (succeeds, with both messages).
> No significant regressions in functionality (VDE/TC/TCC/EDIT/Arachne
> work).
> HX untested.
> SHARE still compiles fine.
> The relevant lines in sys.c (starting at 629):
> if (!argv[drivearg][1] || (argv[drivearg][1]==':' &&
> !argv[drivearg][2]))
> // if 1st arg drive
> {
> if (!argv[argno][1] || (argv[argno][1]==':'
> && !argv[argno][2])) // if 2nd arg drive {
most likely
&& !argv[argno][2])) // if 2nd arg drive
{
Tom
--
Create and publish websites with WebMatrix
Use the most popular FREE web apps or write code yourself;
WebMatrix provides all the features you need to develop and
publish your website. http://p.sf.net/sfu/ms-webmatrix-sf
___
Freedos-kernel mailing list
Freedos-kernel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] CRITICAL BUG - crosslinked files - 2039 unusable
> As already pointed: > http://sourceforge.net/support/tracker.php?aid=2901916 > there is a CRITICAL BUG in FreeDOS kernel 2039 :-( > I can well reproduce it (not always, though) when COPY'ing files onto > a FAT28 volume. There can be even multiple crossy bunches per multiple (>>=2) files. Also the old files are getting corrupted, the last > written file can (?) be intact. Now I upgraded to 2038, let's see > whether it also has this bug, EDR-DOS definitely doesn't. just wondering: could this be an issue with JEMM386 and/or UIDE ? is this reproducable with only loading HIMEM and kernel ? Eric: you changed something in the FAT code. is this also in 2038 or only in 2039 ? Tom -- Return on Information: Google Enterprise Search pays you back Get the facts. http://p.sf.net/sfu/google-dev2dev ___ Freedos-kernel mailing list Freedos-kernel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] Boot sector LBA detection error
of course you are right. but maybe you are missing the point why the original author (m2) wrote it exactly as it is: to save precious 2 bytes in the boot sector code Tom am 6. Dezember 2009 um 00:32 schrieben Sie: > Hi, > the LBA detection of the FAT12/FAT16 boot sectors (both for the FreeDOS > and "OEM" kernels) could misdetect that a BIOS does support LBA if it > doesn't really. This is the used code (after calling Int13.41 for the boot > unit): >> shr cx, 1 >> ; CX must have 1 bit set >> sbb bx, 0aa55h - 1 >> ; tests for carry (from shr) too! >> jne read_normal_BIOS > This test succeeds if (cx&1) && (bx==AA55h) as intended but also succeeds > if (!(cx&1)) && (bx==AA54h). This is a highly unlikely case but > nonetheless an error which should be corrected. Example: >> sub bx, 0AA55h >> jne read_normal_BIOS >> shr cx, 1 >> jnc read_normal_BIOS > Note that the code after this expects bx to be zero, so sub must be used > here instead of cmp. I exchanged the order of the test for cx bit 0 (disk > access support) and the correct signature in bx since it's easier to > understand the code this way. (It would work the other way around as well.) > Regards, > Christian -- Join us December 9, 2009 for the Red Hat Virtual Experience, a free event focused on virtualization and cloud computing. Attend in-depth sessions from your desk. Your couch. Anywhere. http://p.sf.net/sfu/redhat-sfdev2dev ___ Freedos-kernel mailing list Freedos-kernel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] new kernel released
>> b) why there isn't a 386-fat32 binary available (hardly anyone even >> knows where he might see a real 8086 machine), and the 386 resident code is >> ~1,5 KB smaller > Point out the file(s) that were missed and I'll do an update. IMO the most useful kernel configuratiion is FAT32, compiled for 386 this is missing Tom -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july ___ Freedos-kernel mailing list Freedos-kernel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-kernel
[Freedos-kernel] new kernel released
The kernel developers have just finished up 2039 for release a few days ago (mostly bugfixes), so you can download it at ibiblio ( http://www.ibiblio.org/pub/micro/pc-stuff/freedos/files/dos/kernel/2039/ or at sourceforge ( http://sourceforge.net/projects/freedos ) just wondering, why a) this wasn't advertised on this list and b) why there isn't a 386-fat32 binary available (hardly anyone even knows where he might see a real 8086 machine), and the 386 resident code is ~1,5 KB smaller Tom -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july ___ Freedos-kernel mailing list Freedos-kernel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] Potential issues with FAR printf
> The FAR printf is probably good for 16-bit builds with DEBUG defined. > However, there are at least two potential issues (NOT YET VERIFIED). > 1. 386 (or higher) builds might fail on a FAR value, as a 32-bit FAR is past > 4GB. I don't know how the compilers treat FAR in these builds. exactly as the 16 bit builds. this is REAL mode. Tom -- Enter the BlackBerry Developer Challenge This is your chance to win up to $100,000 in prizes! For a limited time, vendors submitting new applications to BlackBerry App World(TM) will have the opportunity to enter the BlackBerry Developer Challenge. See full prize details at: http://p.sf.net/sfu/Challenge ___ Freedos-kernel mailing list Freedos-kernel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] kernel 2038 discussion stuck? history.txt changes
> * Windows 3.1x support seriously: is ANYBODY using Windows 3.x ? IMHO Windows 3.x is 100% obsolete, so why would anybody want windows 3.x support ? >>> & WfW support in stable, these might be handy. > Windows for Workgroups , which is a flavor of Microsoft Windows 3.11 WfW support will probably never come; WfW was tighly coupled to the kernel (at least according to Schulman et. al., WfW is MUCH more then just a flavour of Windows 3.11) >>> And SHSUCDX with UDF support does seem higher priority. >>> UDF-CDEX would be separate from kernel development > What does UDF support do? Enable copying video DVD? or enable packetwriting? being able to read UDF formatted DVD's, in particular all packet writing DVD software Tom -- OpenSolaris 2009.06 is a cutting edge operating system for enterprises looking to deploy the next generation of Solaris that includes the latest innovations from Sun and the OpenSource community. Download a copy and enjoy capabilities such as Networking, Storage and Virtualization. Go to: http://p.sf.net/sfu/opensolaris-get ___ Freedos-kernel mailing list Freedos-kernel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] Hello again
>> It won't help FreeDOS of course because it still uses fnodes for these >> things instead of SFTs. > Those are ancient relics that should be done away with. There is no > need for them anymore. I'd like to put that high on the priority list > for kernel development. in theory you are right. in praxis fnodes are everywhere throughout the file system (as you probably know), and there's a reason we left them in the kernel the last few years. it's probably fairly easy to convert a stable kernel into unstable by trying to convert this. not that I wouldn't like to get rid of the fnodes (it would be a very good thing), but it's probably a non-trivial amount of work (and risk) involved with that. dont start it if you are not prepared to finish it. Tom -- Crystal Reports - New Free Runtime and 30 Day Trial Check out the new simplified licensing option that enables unlimited royalty-free distribution of the report engine for externally facing server and web deployment. http://p.sf.net/sfu/businessobjects ___ Freedos-kernel mailing list Freedos-kernel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] Hello again
> Which app crashes from running on a FAT+ kernel? (Presuming you don't even > have that large files, or that the app doesn't access these files.) > Excluding low-level disk utilities such as defragmenting or disk checking > programs of course, because EVERY new or extended filesystem breaks them. each and every general file handling program like: COPY, XCOPY, Norton/Volkow Commander, ... ZIP, RAR, ... CHKDSK (and don't tell me CHKDSK isn't important), all Norton stuff xxBACKUP while they probably won't crash, some wont to what they are expected to do. Are you prepared to check the entire ecosystem of DOS utilities if they can handle 4GB+ size files ? it's probably MUCH a better idea to teach this hypotetical blueray player to handle multiple files. that's the reason I think that 4GB+ is a real stupid idea. > DOS-C's FAT+ support could be set by default I don't care what you do to DOS-C. but the FreeDOS kernel shouldn't support FAT+ > Since DOS-C doesn't (yet) support FAT16 file systems larger than 4 GiB yes another stupid idea. > , FAT16+ is no option anyway. right. Tom -- Crystal Reports - New Free Runtime and 30 Day Trial Check out the new simplified licensing option that enables unlimited royalty-free distribution of the report engine for externally facing server and web deployment. http://p.sf.net/sfu/businessobjects ___ Freedos-kernel mailing list Freedos-kernel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] Hello again
> The > main bug/feature that I plan to work on is FAT+ support, the working > with 4GB files goes along with this since it adds support for 4+GB > files. Please keep this out of production kernels. this involves the risk of breaking stuff inside the kernel, and is not (and never will be) supported of any other operating system. > EDR already supports this. who cares ? Tom -- The NEW KODAK i700 Series Scanners deliver under ANY circumstances! Your production scanning environment may not be a perfect world - but thanks to Kodak, there's a perfect scanner to get the job done! With the NEW KODAK i700 Series Scanner you'll get full speed at 300 dpi even with all image processing features enabled. http://p.sf.net/sfu/kodak-com ___ Freedos-kernel mailing list Freedos-kernel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] state of kernel 2038
>>> - int 21.1c should report invalid drives via AL (keep other regs?)
>>> News here: DR-DOS modifies BX/CX/DX but not DS for inv drives.
/* Get Drive Data */
case 0x1c:
{
BYTE FAR *p;
if (p = FatGetDrvData(lr.DL, &lr.AL, &lr.CX, &lr.DX) != NULL)
{
lr.DS = FP_SEG(p);
lr.BX = FP_OFF(p);
}
else
lr.AL = 0xff;
}
break;
should get the job done
> Unfortunately I do not know to what value DR DOS sets BX/CX/DX,
> only got the information that they looked kind of random...
MS-DOS is the king, and it lets all registers unchanged. more a DR-DOS
bug then anything else
> In any case AL has to be set to -1 to flag invalid drives :-)
right.
>>> - CHS calculations are off by 1 and overflowing (thanks Rayer)
>>> If your BIOS has no LBA, this was probably a real pain for you.
>>
>> any details about this ? like the original email ('thanks Rayer' is
>> not enough of a description)
> The discussion is spread over mail and chat,
but this is certainly in the kernel mailing list, isn't it ?
>>> - the BSS_INIT macro is bogus (thanks Rayer)
>> any details about this ? like the original email ('thanks Rayer' is
>> not enough of a description)
> Here is the relevant part of RayeR's kernel:
> diff -bur freedos/kernel/init-mod.h rayer/kernel/init-mod.h
> --- freedos/kernel/init-mod.h 2007-09-07 14:32:05.0 +0200
> +++ rayer/kernel/init-mod.h 2008-11-30 20:55:58.0 +0100
> @@ -32,8 +32,9 @@
> These guys are marked BSS_INIT to mark that they really should be BSS
> but can't be because of MS
> + Seems to be needed also for Watcom C 11.x
> */
> -#ifdef _MSC_VER
> +#if ((defined _MSC_VER) || (defined __WATCOMC__))
> #define BSS_INIT(x) = x
> #else
> #define BSS_INIT(x)
> I personally would suggest to always have BSS_INIT(x) = x and
> not only for certain compilers. After all, the kernel is not
> a "normal program" so compiler-specific BSS clearing code is
> usually not triggered...
> Thanks for commenting :-)
some comment is necessary; introduction into the crazy memory model ;)
it shouldn't matter if
int SomeVariable;
or
int SomeVariable = 0;
is declared. in the former case it is put into the BSS segment, and
initialized by the runtime libray. As we don't have the normal runtime
library, we do it in main.c
/* clear the Init BSS area (what normally the RTL does */
memset(_ib_start, 0, _ib_end - _ib_start);
(I verified that this at least seems to do something reasonable)
in the latter case it is put into the DATA segment, and initialized
with static data.
in both cases the variable ends up as 0
if this makes any difference, either
the memset() memset above doesn't work
or
the error relates to the actual placement of the variable in the
DATA segment. usually an overwriting problem or similar.
good luck hunting if it's the latter
--
Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA
-OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise
-Strategies to boost innovation and cut costs with open source participation
-Receive a $600 discount off the registration fee with the source code: SFAD
http://p.sf.net/sfu/XcvMzF8H
___
Freedos-kernel mailing list
Freedos-kernel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] Suggestion: Int 0x21, AX=0x7305, CX=0xFFFF handler
>> and after he verified this private version, may be even put it on >> ibiblio to be used by others ? > I hope you did see the mail earlier this week which says that > kernel 2038 is almost ready anyway ;-). whatever 'ready' means when nobody (except you self) tested it so far. in the good old times, we had a couple of prereleases, and also of post release fixes. the times they are a-changing ... the latest pubished kernel on ibiblio, freedos 1.0, etc. http://www.ibiblio.org/pub/micro/pc-stuff/freedos/files/dos/kernel/2036/ is from august 2006. - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace ___ Freedos-kernel mailing list Freedos-kernel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] Suggestion: Int 0x21, AX=0x7305, CX=0xFFFF handler
Hi Eric, how about compiling this for Christian ? not everybody likes to download watcom, find out how to get kernel sources compiled ... and after he verified this private version, may be even put it on ibiblio to be used by others ? Tom - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace ___ Freedos-kernel mailing list Freedos-kernel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] roadmap for freedos kernel 2038
> Hopefully someone can found the bug and fix it, my pathetic knowledge > forbid me to help. to fix any bug, it must be reproduced first. As noone has ghost 5, 'the bug' can't be reproduced, and so can't be fixed. end of story. Tom - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ ___ Freedos-kernel mailing list Freedos-kernel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] roadmap for freedos kernel 2038
>> >1658 Ghost 5.1 fails: Needs somebody with Ghost 5.1 to fix > Maybe true, but I do not have ANY version of Ghost to test :-( > If a newer version of Ghost works, then we could indeed set > the bug status to "wontfix" and mention that newer versions > do work fine. Or we could lower bug priority to "wish". this bug was reported for 2.20.29 and 2.20.31 'stable' kernels started with 2.20.35, so reported bugs should reference 2.20.35 at least >> >1956 extending JFT (FILES=...) fails: Fixed in SVN :-) that doesn't help if the famous FreeDOS 1.0 distributes something from 2006 :( Tom - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ ___ Freedos-kernel mailing list Freedos-kernel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] [Freedos-devel] flaws in user HMA memory allocation?
> 2. It is way slower in file "copy/compare" than other DOSes. > (maybe we should make FAT and DIR data access smarter?) depends on a couple of factors; the huge threat on http://www.drdosprojects.de/forum about FreeDOS is slow was less then scientific a) COPY FreeDOS allocates always the lowest unused cluster, even if the file should be enlarged by a large ( > 1 cluster) amount. this potentially searches a big part of the FAT to find place and writes the file fairly fragmented search for a bunch of clusters that are able to fit this request could accelerate this MSDOS 5 has been reported to allocate buffers on a 'round the disk' alghorithm (continue to search instead of restart from zero); has been reported to slow fragmentation b) COMPARE if enough (small) files in large enough directories with enough directory depth are compared, it might matter that fastopen isn't implemented. Anybody ? > I would like to comment on 1, please correct me if I am wrong... >>>> Experts should be Bart, Arkady, Lucho and Tom :-). <<< > - you can say "BUFFERS=-5" if you want "5 and not more than 5" > (as opposed to "BUFFERS=5" which is "at least 5" in FreeDOS) > - HMA allocation (int 2f.4a0n) in FreeDOS should allow apps (such > as Jack's drivers) to use the free HMA space beyond the user- > selected BUFFERS. So even if we fill all space with extra buffers > while the space is unused, we free that space for more useful > things as soon as some app asks for it. > Maybe there is a bug in int 2f.4a0n handling and/or config.c? yes and no; see http://www.bttr-software.de/forum/forum_entry.php?id=867 > - Arkady and Bart in 2004 > - Bart in 2001 > - Bart in 2004 (moved fnodes into HMA) > - Lucho in 2004 > - Tom in 2001 (created inithma.c) the HMA buffer logic came much later ;) Mit freundlichen Grüßen/Kind regards Tom Ehlert +49-241-79886 - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Freedos-kernel mailing list Freedos-kernel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] Comparison of FreeDOS 2036 to the Tom kernel
>>NOTE that both versions have a typo: "... the any key ..." > It's not a typo! Damnit! Still haven't found the any key? see http://www.computergear.com/pressanykey4.html and http://www.gadgetizer.com/2006/04/03/any-key-mistery-solved/ or just google for "the any key" ;) Tom - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ Freedos-kernel mailing list Freedos-kernel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] Tom's kernel changes vs. CVS
Hi Bart,
nice to see you're still alive :)
> Tom, can you explain?
> 1. config.c. Why use > instead of >=? Is there a corner case with equality?
IMO >= is correct (timeout 0 should exit immediately)
> 2. initoem.c:
> + if (ramsize == peek(0, RAMSIZE))
> if (ramsize * 64 == ebdaseg && ramsize < 640 && peek(0, RAMSIZE) == ramsize)
>the extra double check looks strange to me, why check twice?
> Something strange with short-circuit boolean evaluation?
looks strange, and I have no idea why exactly this is there.
But since I put it in after ke2035, I just assume I did that
intentionally. (this was changed on or before 11.07.2004)
I'd leave it under 'it doesn't hurt'
> 3. int21/ax=3301. The comment and the code are out of sync.
> By falling
> through it reports the new state of break_ena in DL (not AL).
right
besides that, the code should do the same in both cases (DL should be
00 or 01)
I don't mind much
Tom
> Moreover, RBIL tells us that Novell DOS 7 report the *old* state
> (instead of the new state) in DL. What is the intended logic here?
> Thanks,
> Bart
> --- ke2035/kernel/config.c 2004-05-25 01:02:46.0 -0400
> +++ ke2035ctom/kernel/config.c 2007-05-14 12:43:46.0 -0400
> @@ -753,8 +753,8 @@
> if (timeout >= 0) do
>{
> r.a.x = 0x0100; /* are there keys available ? */
> init_call_intr(0x16, &r);
> -if ((unsigned)(GetBiosTime() - startTime) >= timeout * 18u)
> +if ((unsigned)(GetBiosTime() - startTime) > timeout * 18u)
>return 0x;
>}
>while (r.flags & FLG_ZERO);
> diff -urb ke2035/kernel/dsk.c ke2035ctom/kernel/dsk.c
> +++ ke2035ctom/kernel/initoem.c 2007-05-14 12:43:46.0 -0400
> @@ -58,7 +59,8 @@
>unsigned ebdaseg = peek(0, EBDASEG);
>unsigned ramsize = ram_top;
> + if (ramsize == peek(0, RAMSIZE))
>if (ramsize * 64 == ebdaseg && ramsize < 640 && peek(0, RAMSIZE) ==
> ramsize)
>{
> unsigned ebdasz = peekb(ebdaseg, 0);
> diff -urb ke2035/kernel/inthndlr.c ke2035ctom/kernel/inthndlr.c
> --- ke2035/kernel/inthndlr.c2004-05-30 20:31:06.0 -0400
> +++ ke2035ctom/kernel/inthndlr.c2007-05-14 12:43:46.0 -0400
> @@ -78,17 +78,17 @@
> case 0x33:
>switch (irp->AL)
>{
> + /* Set Ctrl-C flag; returns al = break_ena */
> +case 0x01:
> + break_ena = irp->DL & 1;
> + /* fall through */
> +
>/* Get Ctrl-C flag */
> case 0x00:
>irp->DL = break_ena;
>break;
> - /* Set Ctrl-C flag */
> -case 0x01:
> - break_ena = irp->DL & 1;
> - break;
> -
> case 0x02: /* andrew schulman: get/set extended
> control break */
>{
> UBYTE tmp = break_ena;
> -
> This SF.net email is sponsored by DB2 Express
> Download DB2 Express C - the FREE version of DB2 express and take
> control of your XML. No limits. Just data. Click to get it now.
> http://sourceforge.net/powerbar/db2/
> ___
> Freedos-kernel mailing list
> Freedos-kernel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Mit freundlichen Grüßen / Kind regards,
Tom Ehlert
+49-241-79886
-
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
___
Freedos-kernel mailing list
Freedos-kernel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] FreeDOS MS DOS 3 last missing APIs, was: INT 21h, AX=43FFh
> - int 2f.4a00.cx=0 the kernel has to call this before it displays
>the "Insert diskette for drive B:" (or A:...) message, to let
>Win3 and the like show a GUI dialog instead of the message, DOS 5.0
seems to have been lost; should be
STATIC WORD play_dj(ddt * pddt)
{
/* play the DJ ... */
if ((pddt->ddt_descflags & (DF_MULTLOG | DF_CURLOG)) == DF_MULTLOG)
{
int i;
ddt *pddt2 = getddt(0);
for (i = 0; i < blk_dev.dh_name[0]; i++, pddt2++)
{
if (pddt->ddt_driveno == pddt2->ddt_driveno &&
(pddt2->ddt_descflags & (DF_MULTLOG | DF_CURLOG)) ==
(DF_MULTLOG | DF_CURLOG))
break;
}
if (i == blk_dev.dh_name[0])
{
put_string("Error in the DJ mechanism!\n"); /* should not happen! */
}
else
{
/* according to RBIL (te 22 jul 04) */
iregs r;
r.a.x = 0x4a00;
r.c.x = 0x;
r.d.b.l = pddt->ddt_logdriveno;
r.d.b.h = pddt2->ddt_logdriveno;
intr(0x2f,&r);
if (r.c.x == 0x)
{
/* someone else makes a nice dialog */
}
else
{
template_string[DRIVE_POS] = 'A' + pddt2->ddt_logdriveno;
put_string(template_string);
put_string("Insert");
template_string[DRIVE_POS] = 'A' + pddt->ddt_logdriveno;
put_string(template_string + 6);
put_string("Press the any key to continue ... \n");
fl_readkey();
}
pddt2->ddt_descflags &= ~DF_CURLOG;
pddt->ddt_descflags |= DF_CURLOG;
pokeb(0, 0x504, pddt->ddt_logdriveno);
}
return M_CHANGED;
}
return M_NOT_CHANGED;
}
-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys -- and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
___
Freedos-kernel mailing list
Freedos-kernel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] please change the default freecom and increasethe kernel version
Hello Bart, >> well, we have: >> kernel 2034, 2035 released by Bart >> kernel 2035A released by Jeremy >> kernel 2035B by Jeremy (2035A + "stable features backported from 2035W) >> kernel 2035W by Jeremy, experimental/development line > isn't there also still a kernel 2035-Tom somewhere (drivesnapshot.de)? Yes. > Or did 2035A supersede that as far as Tom is concerned? No. there were some changes in ke2035-Tom (mailed to the list), which - as fas as I know - went also in the stable branch. Drive Snapshot relies on a stable kernel, so I use one that I understand. At least I can't complain about possible bugs introduced by some experimental feature ;) Mit freundlichen Grüßen / Kind regards, Tom Ehlert +49-241-79886 --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://sel.as-us.falkag.net/sel?cmd=lnk&kid=103432&bid=230486&dat=121642 ___ Freedos-kernel mailing list Freedos-kernel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] Re: reload partition table and reassign drive letters
Hello David, > If FreeCom can handle drive letters coming and going due to network > drives being connected/disconnected, how would fixed disks coming and > going make a difference? I would have thought that FreeCom wouldn't > pay much attention to what type of drive it was looking at. it's not a freecom problem. but the kernel will simply not (re)detect coming and going partitions. remember FDISK ?you HAVE to reboot. Mit freundlichen Grüßen / Kind regards, Tom Ehlert +49-241-79886 --- This SF.Net email is sponsored by: Power Architecture Resource Center: Free content, downloads, discussions, and more. http://solutions.newsforge.com/ibmarch.tmpl ___ Freedos-kernel mailing list Freedos-kernel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] Re: reload partition table and reassign drive letters
Hello Kenneth, > The main issue with FreeCom would be the location of its resources > changing. under normal circumstances, FreeCom-xmsswap will have it's resources loaded at startup and touch them never again. Tom --- This SF.Net email is sponsored by: Power Architecture Resource Center: Free content, downloads, discussions, and more. http://solutions.newsforge.com/ibmarch.tmpl ___ Freedos-kernel mailing list Freedos-kernel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] Re: Analysis: Support for sector sizes != 512 bytes
Hello Eric, > While we are at it, I would suggest a new category "not planned at all > unless you tell us why it is useful or alternatively send us patches" > for the list: http://fdos.org/ripcord/fdos_1_0/official/post.htm > Candidates are: drivparm / driver sys / 3rd floppy support (kernel, sys...), > himem "cpuclock" and "eisa" options, graphics "lcd" option (for old CGA > 640x200 handhelds with widescreen display), emm386 Weitek FPU MMIO support... > Let me know if I forgot something. add sectorsize != 512 > PS: Eg. FASTOPEN can, imho, be useful, as scanning large directories > causes big load for CPU and BUFFERS / cache which can be reduced by a > specialized FASTOPEN directory entry cache. But thats just my 2 cents. send us patches tom --- This SF.Net email is sponsored by Oracle Space Sweepstakes Want to be the first software developer in space? Enter now for the Oracle Space Sweepstakes! http://ads.osdn.com/?ad_id=7393&alloc_id=16281&op=click ___ Freedos-kernel mailing list Freedos-kernel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] Analysis: Support for sector sizes != 512 bytes
Hello Eric, > Comments about useful sector sizes would be welcome: > Smaller (64, 128, 256), normal 512, Bigger (1024, 2048, others). 512. > Thanks for your comments! Trying to wake up the kernel list a bit :-)). add code to support dynamic disks. Tom --- This SF.Net email is sponsored by Oracle Space Sweepstakes Want to be the first software developer in space? Enter now for the Oracle Space Sweepstakes! http://ads.osdn.com/?ad_id=7393&alloc_id=16281&op=click ___ Freedos-kernel mailing list Freedos-kernel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] freedos
Hello Geraldo, > is possible to implement a virtualfilesystem layer on > freedos kernel? it has already: the network redirector interface. > what do you think about create a hardware abstraction layer > on freedos kernel? > it is interesting to make freedos "portable" to others > architectures it has already: it's called BIOS ;) tom --- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click ___ Freedos-kernel mailing list Freedos-kernel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] Re: [Freedos-cvs] kernel/kernel entry.asm,1.27.2.1,1.27.2.2
Hello Alain,
Tuesday, January 11, 2005, 1:24:48 PM, you wrote:
> Arkady V.Belousov escreveu:
>> Hi!
>>
>> 4-Янв-2005 19:05 [EMAIL PROTECTED] (Luchezar Georgiev) wrote to
>> [EMAIL PROTECTED]:
>>
>>
>>>Fix divide error message text
>>>+++ entry.asm 4 Jan 2005 19:05:08 - 1.27.2.2
>>>-; print a message 'Interrupt divide by zero'
>>>+; print a message 'Interrupt divide error'
>>
>>
>> This is not fix, this is change - though "division by zero" interrupt
>> INT0 hapens not only in case of real division by zero, but this ("Divide by
>> Zero") is a standard name. On the other side, "Interrupt divide error" I
>> read as "error in dividing the interrupt", so, if you wish to give more
>> meaningful name, there should be something like "Interrupt: division error".
>>
> I agree :)
I disagree :(
tom
---
The SF.Net email is sponsored by: Beat the post-holiday blues
Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek.
It's fun and FREE -- well, almosthttp://www.thinkgeek.com/sfshirt
___
Freedos-kernel mailing list
Freedos-kernel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] Re: Re: [Freedos-cvs] kernel/kernel inthndlr.c,1.87.2.12,1.87.2.13
Hello Eric, > Hi guys, interesting anecdote from Pat, but: yes, it was interesting to see Pat watching this list at all. and while I agree completely with what he wrote, IMO he slightly missed the point (and you -eric- miss it completely) > The whole point is that if you remove the break; completely, then > somebody who later reads or changes the code might be mislead into > thinking that the code SHOULD fall through ... the whole point is that in a shared programming effort (as the freedos kernel still should be) it's a waste of resources to change ANYTHING without a certain payback. in this case, removing 'break;' may have saved 5 bytes in the early 90ties, but is irrelevant (or even contraproductive) with optimizing compilers, and leads only to such irrelevant 'why was this changed' threads. even if this WOULD save 3,5, or even 10 byte: it's completly irrelevant. the kernel has more then enough space in HMA, >= 40 buffers ARE enough, and fighting lengthy email threads to free possibly another 512 byte (with exactly zero performance increase) is simply a waste of developers time, ethernet and my barins bandwidth. Besides that, this byte fiddeling attitude is the IMO the reason for the developement kernels name - 'unstable'. tom > after the return_user, > or that it would be OKAY to fall through - in both cases, he will > either not UNDERSTAND the code properly or will even add BUGS by > erroneously adding the possibility of returning to the caller to > return_user(). > So: OKAY, remove break; if you want, BUT add a comment instead of the > break;, to let people know that return_user() never returns. You should > even add such a comment to return_user() itself actually. > By the way, you probably save even more bytes - and a bit of stack > space - by using an evil GOTO for the return_user(), unless it already > is an inlined macro or similar already anyway. > OLD: break; > BAD: (nothing) > BETTER: /* return_user never returns, no break needed */ > EVIL: use goto instead of call for return_user ;-). > Eric > PS: Which kernels contain the DOSLFN compatibility patch (improved > xBPB/DPB initialization and set extended error code implemented), > did somebody contact GRUB people about 0.0.35 vs. 1.0.35 version ID, > does anybody remember why FreeCOM has "if XMS swap version, then > disable LOADFIX" in #if, and why old CATS of HTMLHELP required LOADFIX > to work with DOS=HIGH (I seem to remember that recompiling with either > Toms or my KITTEN version or recompiling ZLIB or both was what Bob did > to fix the bug... maybe there are OTHER programs with CATS affected? > Which programs still use CATS instead of KITTEN? Symptom was a CRASH > when using HTMLHELP several times on SOME systems if DOS=HIGH...) ...? > And did Arkady re-add the seemingly but not actually unneeded BPB/... > initialization at boot time which he had removed at some point? > --- > The SF.Net email is sponsored by: Beat the post-holiday blues > Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek. > It's fun and FREE -- well, > almosthttp://www.thinkgeek.com/sfshirt > ___________ > Freedos-kernel mailing list > Freedos-kernel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/freedos-kernel -- Kind regards, Tom Ehlert mailto:[EMAIL PROTECTED] +49-241-79886 --- The SF.Net email is sponsored by: Beat the post-holiday blues Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek. It's fun and FREE -- well, almosthttp://www.thinkgeek.com/sfshirt ___ Freedos-kernel mailing list Freedos-kernel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] Re: [Freedos-cvs] kernel/utils exeflat.c,1.9.2.3,1.9.2.4
Hello Arkady, >>> Small optimization: because BC doesn't knows, that exit() doesn't BO>> I don't think optimizing exeflat.exe's size is very important though ;) > Sure. :) But why not make more optimal code from scratch in any case, > without thinking "will this code often used"? And why not leave *existing* code as is - without wasting mental and ethernet bandwidth on it ? >>> LG> + qsort(reloc, header.exRelocItems, sizeof(reloc[0]), compReloc); >>> Why to spend extra time for sorting relocations? BO>> I think it's easier to read the output that way. Tom's idea. BO>> Does qsort() really take a long time for you in exeflat? I find that hard BO>> to believe, for just ~70 relocations. > Of course, qsort() if very fast algo (except some specific cases, when > it is O(N^2)), but why to do _any_ extra action, when unnecessary? :) it's not unnecessary - else I wouldn't have written it. > Especially, I suggest, (most) linkers do own sorting anyway? I call people who 'suggest' somethintg that is plain wrong (and they could have seen that themself) idiots. > Ok, ok, above questions are not critical and mostly rhetorical. but give some insight. > Hm. I think for simplicity and safety, exeflat should itself move > relocation table from executable's header inside executable itself, so that > it may be reused by MoveKernel(). This allows to eliminate manual table at > kernel.asm:__HMARelocationTableStart. > (Yes, I know __HMARelocationTableStart is not plain relocation table, > but jump/code table, with jmps and calls to EnableA20. But table from header > may be copied (after fixing) into "secondary" table. This allows to make > code, which is more relocatable and may make cross-segments calls and > accesses. This also solves issues with standard library routines, which may > be used both from non-relocatable low code and from relocatable code.) if you can write down a simpler and saver method to do that - fine. else - see my bandwidth comment... tom --- This SF.Net email is sponsored by: InterSystems CACHE FREE OODBMS DOWNLOAD - A multidimensional database that combines robust object and relational technologies, making it a perfect match for Java, C++,COM, XML, ODBC and JDBC. www.intersystems.com/match8 ___ Freedos-kernel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] some exeflat changes
Hi Bart,
good to see you alive and around :)
> http://freedos.sourceforge.net/kernel/exeflat.c
> (the file is smaller than the diff would be)
there are probably a couple of changes to makefiles & batches ?
> To use it you need to change the makefile to remove the explicit UPX call:
> this call is done via system() in exeflat.c now.
didn't test yet - that's all ?
this might, should and will be recoded by some sort of
system(getenv("XUPX", ...)
tom
---
This SF.Net email is sponsored by: InterSystems CACHE
FREE OODBMS DOWNLOAD - A multidimensional database that combines
robust object and relational technologies, making it a perfect match
for Java, C++,COM, XML, ODBC and JDBC. www.intersystems.com/match8
___
Freedos-kernel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/freedos-kernel
[Freedos-kernel] Fwd: FreeDOS kernel disk routines
This is a forwarded message From: Jose Antonio Senna Subject: FreeDOS kernel disk routines ===8<==Original message text=== Excuse me for sending this directly to you, but I am still unable to post on Freedos lists. I do not know who (if anyone) mantains the FreeDOS kernel disk routines. If it is not you, please pass this mail to the appropriate person. The problem I found is: My computer BIOS INT 13 is able to access up to 4096 cylinders in a hard disk, by using bits 6 -7 of DH in INT 13 requests as bits 10-11 of cylinder number. This BIOS variant is documented in Brown and Kyle interrupts list. However,FreeDOS hooks INT 13 and,in doing so,rolls over any cylinder number modulo 1024,that is,if I make a request to access cylinder 1024,it does not report any error,but I get cylinder 0, and so on. FreeDOS is not the only DOS to have this problem. Is it too difficult to solve ? I thank you for your attention JAS ===8<===End of original message text=== my comment: how are these disks/BIOS variants detected ? I have a faint memory of these translating BIOS's, but can't find it in RBIL. IMO the kernel shouldn't touch partitions that are to big to handle (>1024 cylinders), unless LBA is detected. tom --- This SF.Net email is sponsored by: Sybase ASE Linux Express Edition - download now for FREE LinuxWorld Reader's Choice Award Winner for best database on Linux. http://ads.osdn.com/?ad_id=5588&alloc_id=12065&op=click ___ Freedos-kernel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] unused SFT fields <-> f_nodes not needed???
Hello Eric, > Hi, I tried to check SFT compatibility of FreeDOS, quick conclusion: > sft_dcb is never accessed > sft_stclust is never accessed >... > sft_ifsptr is never accessed (nor initialized to 0?) you may be right. and it may be easy to replace (most of) the fnode data by the corresponding sft data. > Is that correct? I think SFT-messing programs like Windoze will not be > happy in particular about all those uninitialized cluster values, the > missing DCB pointer, and missing dir entry info. Unfortunately, this most probably won't make SFT-messing programs really happy, only slightly more happy. real word experience shows, that probably our own use of these fields is slightly different from what xxDOS is doing (think of +- 1 effects or similar). our own internal data is (or seems to be) consistent. if that corresponds *exactly* to the actual use of these fields by DOS is completely untested. maybe everything will be fine, until some funny program seeks (in Win3x) from end of file backward, or similar. good luck searching for these tiny bugs. tom --- This SF.Net email is sponsored by: Sybase ASE Linux Express Edition - download now for FREE LinuxWorld Reader's Choice Award Winner for best database on Linux. http://ads.osdn.com/?ad_id=5588&alloc_id=12065&op=click ___ Freedos-kernel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] Floppy boot config read broken in 2034/32+
Hello Eric, > Hi, Steve reports that while things were fine in kernels > 2030 ... 2033 (both with and without FAT32 support), kernel > 2034 WITH FAT32 support and all 2035 kernels fail to read > the (fd) config sys file when booting from floppy. *ALL* kernels 2023..2035BTom boot from 1.44 floppy, and have no problem reading config.sys, and never had. That's how I work (booting from floppy), and this got tested a few thousand times. So probably something different is wrong. Maybe the floppy itself is simply unreadable. > PPS: Very interesting question is why for 2034 only the FAT32 kernel hurts. because the kernel was written to a different place on the floppy ? tom --- This SF.Net email is sponsored by: Sybase ASE Linux Express Edition - download now for FREE LinuxWorld Reader's Choice Award Winner for best database on Linux. http://ads.osdn.com/?ad_id=5588&alloc_id=12065&op=click ___ Freedos-kernel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] FreeDOS, DR DOS and Win386 compatibility (shorter)
Hello Eric, > Hi, I exchanged some mails with Udo from DR DOS improvement project, > and the conclusion might be that FreeDOS is not missing much for 386Enh > compatibility - it only has one thing too much: fnodes. From what follows, it real seems to be easy to make FreeDOS Win3.1 compatible. So there's just one major problem tot mentioned: How to interest a kernel developer enough, that he throws his time at such a waste-of-time project ? tom N¬HYÞµéX¬²'²Þu¼Lúèvç-èzÈLƧj«°.®v¥RÇNèvç-²)ò¢êۺȧzËzYn³Z·*.¶§í é÷®±.¬êb*'°g·N§gh´'«¶'âq«^°)brKh~)Ý¢ëf¢·¡¶Úþèvç-èz+fjv z»#¢êçjW(ø.ש®¨¶je·v$z¹Þf¢)à+-·v$z¹ÞX¬¶Ë(º· ~àzwÛi³ÿåËl²«qç讧zßåËlþX¬¶)ߣ÷ëyçh²G«é
Re: [Freedos-kernel] Re: question about the kernel with
Hi Jeffrey, actually the kernel tries to finish CD harddisk emulation before booting from HD (main.c, EmulatedDriveStatus) unfortunately this doesn't seem to work (in your case, with your CD burning software,...) tom --- This SF.net email is sponsored by: IT Product Guide on ITManagersJournal Use IT products in your business? Tell us what you think of them. Give us Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more http://productguide.itmanagersjournal.com/guidepromo.tmpl ___ Freedos-kernel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] Broken VERSION= in 2035 etc. - too many kernels
Hello Eric, > - Tom has added only the best few lines of the Lucho / Arkady patches, > those which OBVIOUSLY fix bugs, but will have missed several bugfixes > which were hidden between optimizations that might have happened. But for sure I missed some bew bugs hidden between optimizations. > - Lucho / Arkady produced a big amount of patches which mainly contain > optimizations (hopefully not too compiler specific), but also important > bugfixes, which ones ? > Tom, are you planning to publish your kernel variant? www.drivesnapshot.de/freedos/ke2035bt.zip as of today > In either case, > could you help us to discuss the feature / bugfix differences between > your and Jeremies kernel? bugfixes - yes. > There must be a lot of useful stuff in all those patches, but we might > lose overview and miss all the goodies if the patch authors and kernel > maintainers do not start to help mortal programmers like me to catch up > with development why should kernel programmers care if mortal programmers can't follow? you won't follow anyway. tom --- This SF.Net email is sponsored by: YOU BE THE JUDGE. Be one of 170 Project Admins to receive an Apple iPod Mini FREE for your judgement on who ports your project to Linux PPC the best. Sponsored by IBM. Deadline: Sept. 24. Go here: http://sf.net/ppc_contest.php ___ Freedos-kernel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] Goodbye from Lucho (this time forever)
Hello Luchezar, Tuesday, September 14, 2004, 12:18:08 PM, you wrote: > Sorry Bart, I was wrong AGAIN. I will add creation times again, and this > will END my participation in the FreeDOS project. I feel that I'm NOT good > for such activity anymore. Jack R.Ellis was right to never participate in > mailing lists. At the age of 45, So you are REALLY, REALLY OLD (you think) unfortunately, I was 44 when I *started* with the Freedos Kernel, being 48 real soon. so that's no excuse to quit - back to work again ;) tom --- This SF.Net email is sponsored by: YOU BE THE JUDGE. Be one of 170 Project Admins to receive an Apple iPod Mini FREE for your judgement on who ports your project to Linux PPC the best. Sponsored by IBM. Deadline: Sept. 13. Go here: http://sf.net/ppc_contest.php ___ Freedos-kernel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] Tom's patch dated 5 July
Hello Luchezar, > Do you mean > http://www.mail-archive.com/[EMAIL PROTECTED]/msg01070.html yes > (It doesn't contain other comments but those in the patch.) If you > confirm, I can apply it. yes. >> it happens if a int24 handler returns to itself directly, instead of the >> 'normal' way to return to DOS with some error code. > But an Int 24h handler returns with an IRET, so to return to itself means > that it's re-entrant! has nothing to do with reentrancy. a) program installs it's own int24handler. b) critical error happens, int24() gets called. *usually* this sets carry flag etc. and returns to DOS (and DOS gets a chance to free_fnode() etc.) in the observed case (which probably came from some Turbo Pascal library, floating in the net), the program instead pops all (DOS saved) registers from stack, sets some magic flag in the application, and returns immediately to the user adress on the stack - no chance for DOS to reset errorlevel, no chance to free_fnode(). tom --- This SF.Net email is sponsored by: YOU BE THE JUDGE. Be one of 170 Project Admins to receive an Apple iPod Mini FREE for your judgement on who ports your project to Linux PPC the best. Sponsored by IBM. Deadline: Sept. 13. Go here: http://sf.net/ppc_contest.php ___ Freedos-kernel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] Re: kernel/kernel country.asm, inthndlr.c
Hello Luchezar, >> and removes (parts? of) tom's patch. > As you wrote youself, it's better to have the whole patch than parts of > it. And even better is to solve entirely the problem which this kludge > solves partially. But we don't know the problem :-( at least I know the problem - and described it when publishing the patch. it happens if a int24 handler returns to itself directly, instead of the 'normal' way to return to DOS with some error code. In that case the near f_nodes are never freed (until the program terminates) the only real solution that comes to my mind is to undo the alloc_fnode() change, even if that costs a few byte in low memory; if you don't have UMB's, it even saves a few byte (the memory used by the 2 near_fnodes) tom --- This SF.Net email is sponsored by: YOU BE THE JUDGE. Be one of 170 Project Admins to receive an Apple iPod Mini FREE for your judgement on who ports your project to Linux PPC the best. Sponsored by IBM. Deadline: Sept. 13. Go here: http://sf.net/ppc_contest.php ___ Freedos-kernel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] Boot sector drive incompatibility with other boot sectors
Hello Luchezar, >> "D:"==second disk? Second disk is a 81h value. > Only 0 and 80 are used by MS-DOS. All other values are "FreeDOS > extensions" ;-) are you SURE ? I remember a BIOS that had the option to boot from 2'nd drive. this only makes sense if DOS then boots from 0x81. tom --- This SF.Net email is sponsored by: YOU BE THE JUDGE. Be one of 170 Project Admins to receive an Apple iPod Mini FREE for your judgement on who ports your project to Linux PPC the best. Sponsored by IBM. Deadline: Sept. 13. Go here: http://sf.net/ppc_contest.php ___ Freedos-kernel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] NSSI Works!!!
Hello Luchezar, >> In FreeDOS 2035a, NSSI crashed. >> In the newest unstable kernel, NSSI works excellent! >> Get NSSI at http://www.navsoft.cz > Thanks for the information! Unfortunately if UDMA or CD-ROM driver is > loaded, it hangs at the "checking memory for viruses" stage under the > unstable CVS kernel. these were my results also - with boring, rock stable now DOES IT WORK ON UNSTABLE OR NOT ? WHICH UNSTABLE ? > Else it works, but hangs at the "Checking NLSFUNC" > stage when creating automatic report. Needless to say everything works > under MS-DOS 7.10. but scince NSSI is under active developement, the author can probably tell us what we are doing wrong. unfortunately, this las sentence was just a joke. tom --- This SF.Net email is sponsored by: YOU BE THE JUDGE. Be one of 170 Project Admins to receive an Apple iPod Mini FREE for your judgement on who ports your project to Linux PPC the best. Sponsored by IBM. Deadline: Sept. 13. Go here: http://sf.net/ppc_contest.php ___ Freedos-kernel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] NSSI Works!!!
> In FreeDOS 2035a, NSSI crashed. as it works for me (a different 2035a), could you give some details (like config.sys). in particular: does it crash with an empty config.sys ? tom > In the newest unstable kernel, NSSI works excellent! > Get NSSI at http://www.navsoft.cz > Interon --- This SF.Net email is sponsored by BEA Weblogic Workshop FREE Java Enterprise J2EE developer tools! Get your free copy of BEA WebLogic Workshop 8.1 today. http://ads.osdn.com/?ad_id=5047&alloc_id=10808&op=click ___ Freedos-kernel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] Review on kernel files, some questions
Hello Aitor, > I have started watching kernel source files, and trying to understand > its logic by reading sources. good luck ;) > (1) why are there STRINGS.C and MISC.C, apparently with the same > functionality and same routines in the same programming language? historical reasons. it was so, and never cared to clean up. > (3) I see that the BPBs are initialised (MAIN.C:InitializeAllBPBs) by > opening and closing a file for each drive, any hint why this is so? in theory, this initializeAllBPBs() shouldn't be necessary, but instead be done automatically as drives are accessed. > (such as code in DSK.C where I could see: "if file opened for the first > time, then initialise the BPB"). exactly. however, some time back (2030 or similar), VC would hang on some drives that hadn't been accessed yet; consider initializeAllBPBs() some sort of hack. No idea if it's still needed. > (4) I ignore if the boot loader will send any valuable value to kernel > routine inside variables AX and BX. AFAIK, AX doesn't hold anything useful. > (5) By the way, strangely enough I don't happen to see "123 - Initdisk" > anymore, due most probably to the \r before the kernel compatibility. \r introduced to remove the debug only '123 - initdisk' to avoid unnecessary screen clutter. > (7) A big questions: I have noticed the following two things: > - there is a stack for the IRQ interrupts (apparently independent from > the rest) > - there is a kernel stack there are always 3 kernel stacks, with fixed location, and fixed size of 384 byte each; used for int21 processing. completely independent is the *option* to give some hardware interrupt routines (timers etc.) a separate stack. tom --- SF.Net email is sponsored by Shop4tech.com-Lowest price on Blank Media 100pk Sonic DVD-R 4x for only $29 -100pk Sonic DVD+R for only $33 Save 50% off Retail on Ink & Toner - Free Shipping and Free Gift. http://www.shop4tech.com/z/Inkjet_Cartridges/9_108_r285 ___ Freedos-kernel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] Announce: COUNTRY.SYS
Hello Aitor, > Yes, but as I mentioned, the problem is that, how do we get collating > tables, etc for other countries than US and Germany? We could rely on > user's efforts to create those tables, but this can be quite laborious > (provided that, for copyright issues, the COUNTRY.SYS of the > "competitors" are distributable). well - we get it the same way that the MS COUNTRY information was collected - BY MANUAL EFFORT BY HOWEVER DOES IT - paid or not. using MS COUNTRY.SYS isn't an option other COUNTRY.SYS's simply don't exist. and IMO the way that all your 100+ keyboard tables were obtained is - even if it *might* not be strictly illegal - certainly far beyond any means of 'fair use' simply sort of 'disassembling' some work that MS has done, and pretending this is our work, is hardly anything I appreciate. so I would really dislike this continued in country.sys. IMO, if it's important to have south guinean keybors support/collating tables, some south guinean local should provide these tables. and if nobody provides these tables - fine. but ripping of MS(DOS/Windows/WinNT) these tables is really something I dislike. BTW: all MKEYB tables were created manually (AFAIK; at least if I did them) it would be easy to write a compiler/interpreter to make (X)keyb tables usable in MKEYB as well; I simply don't like the tables. tom --- SF.Net email is sponsored by Shop4tech.com-Lowest price on Blank Media 100pk Sonic DVD-R 4x for only $29 -100pk Sonic DVD+R for only $33 Save 50% off Retail on Ink & Toner - Free Shipping and Free Gift. http://www.shop4tech.com/z/Inkjet_Cartridges/9_108_r285 ___ Freedos-kernel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] Information wants to be free
Hello Luchezar, >>> Not only Bulgarians. 3/4 of the world thinks so. And many Americans and >>> Germans too, by the way. >> >> there is a german saying 'hey guys - eat shit! Billions of flies can't >> be wrong' > So we're just billions of flies to you. Very well :) Otherwise it's a > great anti-fashion proverb. no. it means 'just because many, many people do X, that doesn't prove X to be right' (nor does it prove it's wrong) >> information is as much a product as a car or a house, and it costs >> similar effort. > I disagree. Building 1000 houses costs one almost 1000 times more than a > single house. Making 1000 copies of a program costs one much less than > developing the program itself. It's a false analogy. but developing just one copy of a program (that is worht to be bought) is usually more expensive than building a house; after it's finished it's indeed fairly inexpensive to sell it multiple times. unfortunately I haven't yet found many customers that pay me the price of a house for a single copy;) So I sold the first copy of Drive Snapshot for the same price as the thousandth, and (of course hope to sell millions). Do you really think after having sold thousand copies, I'm a good programmer, who deserves any dollar he makes, and after selling millions copies (and having charged money for it) I'll be suddenly an immoral man ? IMO it will (or propably 'would') still be the same thing: the customer gets some value for some amount of money. if the product is good enough, that the customer is happy - great. if not - not so great. But the customers contentness is probably not related to the fact, that I'm billionaire or not. tom --- SF.Net email is sponsored by Shop4tech.com-Lowest price on Blank Media 100pk Sonic DVD-R 4x for only $29 -100pk Sonic DVD+R for only $33 Save 50% off Retail on Ink & Toner - Free Shipping and Free Gift. http://www.shop4tech.com/z/Inkjet_Cartridges/9_108_r285 ___ Freedos-kernel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] Announce: COUNTRY.SYS
Hello Eduardo, > Lucho, Steffen, everybody, we should have some discussion to determine > which COUNTRY.SYS format we should use in FreeDOS. 1'st let me state that I never used NLSFUNC, so I may be the wrong person. 2'nd, all I needed for FreeDOS was 24 hour time/european date, and I implemented it in the kernel.sys (rather then in some external COUNTRY.SYS), because it requires only a few bytes (for the current supported date,time, currency,...) and is hardly worth the requirement of an extra COUNTRY.SYS. this changes IMO, if uppercasing tables etc. are supported for many countries, but not sooner; and I think that moving the date/time functionality to *require* COUNTRY.SYS is a step in the wrong direction (even if it suits lucho in his attempts to get a few byte smaller kernel) > In fact, I've had a working NLSFUNC for some weeks now. The only thing > it needs for general availability is a kernel with functions 2f.1226 to > 2f.1229. Actually, it works with the implementation of these functions > that I posted to this list (I modified NLSFUNC to avoid running out of > stack as Bart suggested) and it even works calling to the int21 > equivalents (saving the caller stack and switching to a local one before > calling int21). Congratulations. I still don't understand why this should be done from inside DOS; in real life you'll have an external utility NLSFUNC SET LANGUAGE GREEK or similar that can use any desired method, and doesn't have to rely on fancy kernel internal calls/IOCTLS/etc. I may be wrong with that, though. > Another problem is that it does _not_ uses the MS COUNTRY.SYS format, > but the one that Steffen Kaiser designed when he was implementing the > NLS support for the kernel. The advantages are that it was designed with > the kernel NLS structures in mind and that there are also utilities to > convert to/from a text (source) format. IMO that's not a disadvantage. We can't use MS country.sys anyway, and there are hardly many third party COUNTRY.SYS's floating around we must be compatible with. I'd prefer a different country.sys format alltogether, with smaller size in mind. It doesn't has to be xxZIP'ed (due to relative large decoding code size), but you get get a significant amount of compression by some 'this toupper table is almost the same as the table before with the expection of characters 187-192 and 205-119, differences follow' not difficult to implement, and worth the effort IMO. just my 2 cents tom > Regards, > Eduardo. > --- > SF.Net email is sponsored by Shop4tech.com-Lowest price on Blank Media > 100pk Sonic DVD-R 4x for only $29 -100pk Sonic DVD+R for only $33 > Save 50% off Retail on Ink & Toner - Free Shipping and Free Gift. > http://www.shop4tech.com/z/Inkjet_Cartridges/9_108_r285 > _______ > Freedos-kernel mailing list > [EMAIL PROTECTED] > https://lists.sourceforge.net/lists/listinfo/freedos-kernel -- Best regards, Tom Ehlert mailto:[EMAIL PROTECTED] +49-241-79886 --- SF.Net email is sponsored by Shop4tech.com-Lowest price on Blank Media 100pk Sonic DVD-R 4x for only $29 -100pk Sonic DVD+R for only $33 Save 50% off Retail on Ink & Toner - Free Shipping and Free Gift. http://www.shop4tech.com/z/Inkjet_Cartridges/9_108_r285 ___ Freedos-kernel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] Information wants to be free
Hello Luchezar, >>> It's not worth a penny because it can be freely downloaded from Vietnam >>> (I posted the URL here ;-) >> >> I know bulgarians think that way. > Not only Bulgarians. 3/4 of the world thinks so. And many Americans and > Germans too, by the way. there is a german saying 'hey guys - eat shit! Billions of flies can't be wrong' >> It's still theft. > It would be a theft if I *move* the files. If I copy them, I don't deprive > anybody form anything. The whole nature of information allows copying sorry - no. information is as much a product as a car or a house, and it costs similar effort. and the people who made this product must be paid - some way or the other. just because you can technically copy it (whithout causing me any direct harm) does NOT imply you MAY do that. please accept the fact, that there is FREE information, and for some other information you have to pay, or you will kill the producer in the long run (because he will starve to death) > Quite the contrary, corporations steal our money when they ask us to buy > their software. it's simple as that: they want your money IF you use their software. they offer you a deal, which you can accept - or deny. stop using their software, and you don't have to pay them a dime. > Copyright is dying, long life copyleft! ;-) I assume your company produces some sort of (hardware) gadget, that it sells - which in the end ends up as salary in your pockets. I wonder what happens if I rip off your gadgets design and internal software, 'reengineer' the gadget, produce it myself (at much lower cost as I don't have to pay the engineers), and sell it at a price below your gadget. probably neither your employer nor you what be very glad in the end. tom --- SF.Net email is sponsored by Shop4tech.com-Lowest price on Blank Media 100pk Sonic DVD-R 4x for only $29 -100pk Sonic DVD+R for only $33 Save 50% off Retail on Ink & Toner - Free Shipping and Free Gift. http://www.shop4tech.com/z/Inkjet_Cartridges/9_108_r285 ___ Freedos-kernel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] Compilers (the eternal topic :)
Hello Luchezar, > It's not worth a penny because it can be freely downloaded from Vietnam (I > posted the URL here ;-) I know bulgarians think that way. It's still theft. tom --- SF.Net email is sponsored by Shop4tech.com-Lowest price on Blank Media 100pk Sonic DVD-R 4x for only $29 -100pk Sonic DVD+R for only $33 Save 50% off Retail on Ink & Toner - Free Shipping and Free Gift. http://www.shop4tech.com/z/Inkjet_Cartridges/9_108_r285 ___ Freedos-kernel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] Re: Int 2f.122f already supported?
Hello Luchezar, > Hallo Eric, >> does FreeDOS already support int 2f.122f, set DOS version number? > Now it does - see patch below ;-) according to RBIL: INT 2F U - DOS 4.x internal - SET DOS VERSION NUMBER TO RETURN AX = 122Fh DX = DOS version number (h = return true DOS version) note the 'internal', 'true version', and '4.x' ( not 4+ ) I'd recommend to implement setver in a reasonable fashion :(( tom --- SF.Net email is sponsored by Shop4tech.com-Lowest price on Blank Media 100pk Sonic DVD-R 4x for only $29 -100pk Sonic DVD+R for only $33 Save 50% off Retail on Ink & Toner - Free Shipping and Free Gift. http://www.shop4tech.com/z/Inkjet_Cartridges/9_108_r285 ___ Freedos-kernel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] Re: 32RTM Bug Found, no good fix
Hello Eric, >> - lr.CH = REVISION_MAJOR; /* JPP */ >> - lr.CL = REVISION_MINOR; >> + lr.CX = 0; /* serial number must be 0 or buggy 32RTM thrashes >> stack! */ > I would vote for lr.CH = 0 lr.CL = *letter* MSDOS votes cx=0. end of story. tom --- SF.Net email is sponsored by Shop4tech.com-Lowest price on Blank Media 100pk Sonic DVD-R 4x for only $29 -100pk Sonic DVD+R for only $33 Save 50% off Retail on Ink & Toner - Free Shipping and Free Gift. http://www.shop4tech.com/z/Inkjet_Cartridges/9_108_r285 ___ Freedos-kernel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] 32RTM Bug Found, no good fix
Hello Luchezar, >> There you have it folks. A dumb bug in a Borland product that by purest >> happenstance fails under FreeDOS and not MS-DOS. I don't have any idea >> how to gracefully fix the problem other than to have FreeDOS change its >> serial number. And it shouldn't have to do that. Another one who whishes to congratulate Michael for finding this bug, and thanks. > --- cvs/kernel/kernel/inthndlr.c 2004-07-25 20:12:50.0 +0200 > +++ src/kernel/kernel/inthndlr.c 2004-08-13 12:05:56.0 +0200 > @@ -698,10 +698,8 @@ > case 0x30: > lr.AL = os_setver_major; > lr.AH = os_setver_minor; > - lr.BH = OEM_ID; > - lr.CH = REVISION_MAJOR; /* JPP */ > - lr.CL = REVISION_MINOR; > - lr.BL = REVISION_SEQ; > + lr.BX = (OEM_ID << 8) | REVISION_SEQ; > + lr.CX = 0; /* serial number must be 0 or buggy 32RTM thrashes > stack! */ and that's a patch I can peer review, understand it's implications, and merged into my boring rock solid (as stone) kernel branch ;) tom --- SF.Net email is sponsored by Shop4tech.com-Lowest price on Blank Media 100pk Sonic DVD-R 4x for only $29 -100pk Sonic DVD+R for only $33 Save 50% off Retail on Ink & Toner - Free Shipping and Free Gift. http://www.shop4tech.com/z/Inkjet_Cartridges/9_108_r285 ___ Freedos-kernel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] More kernel bugs and incompatibilities
Hello Luchezar, >> one reason for different behaviour *might* be that smartdrv traps >> int25/int26, which is used differently in FreeDOS (not everything is >> rooted through it) > What isn't routed through it? the kernel talks directly to int13 and never uses int25 internally. >> a) he implemented FAT32 >> b) he implemented FAT32 virtually bugfree on first try >>without 25 'please everybody test this' alpha releases. >>he probably tested it himself before publishing. >> c) he implemented FAT32 - and virtually every single line he changed >>was necessary to do the job. no additional noise at all. >>he probably optimized for smallest diff. > Great. So Victor's work can be an excellent example of how the job should > be done, indeed. YES. YES. YES. BTW: michael devore works exactly the same way. >> bug fixing will probably never stop, but squeezing single byte out of it >> is IMO a complete waste of time. > When there are important bugs to fix - yes. But Arkady notices bugs > exactly while optimising! ;-) AFAIR, he found *one* bug, that *might* have real world significance (ret_AH), which was introduced lately by some optimizations by Bart. >> 4 serious real world bugs; so I wouldn't call my branch dead. > You're right. It's not dead. Good job, Tom! Still, there's no progress in > anything but bug fixing - "the call of the day". I don't see any new features in keDANGEROUS either. > By the way, will all your changes go into the "stable" branch? hope so - at least they get posted here. and the source is available on request anyway. tom --- This SF.Net email is sponsored by OSTG. Have you noticed the changes on Linux.com, ITManagersJournal and NewsForge in the past few weeks? Now, one more big change to announce. We are now OSTG- Open Source Technology Group. Come see the changes on the new OSTG site. www.ostg.com ___ Freedos-kernel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] More kernel bugs and incompatibilities
Hello Luchezar,
> I use IOCTL every day and that's how I found that the XMSDSK lock bug that
> prevented SCANDISK from checking the XMSDSK drive had come back as Arkady
> moved the lock check too low. Without anger, I wrote a patch for this, he
> accepted it with some minor changes, and - voila! Problem solved :)
well - good to see that someone fixes some of these optimization
induced bugs.
> I don't even know what MS-LANMAN is, and I guess I don't use it ;-)
accessing files on a networked drive on a MS Server.
> Sure, but this can be said for the "stable" version too. In fact, Arkady
> hasn't touched the file system processing part of the kernel at all. So
> the two kenels don't differ very much internally.
except for 2 changed lines.
> You already wrote this, but (1) I'd prefer the "innocent presumption", to
> the "guilty presumption" towards him,
it's the guilty assumption about *any* change, that I didn't peer
review myself.
> and (2) I think that accusing him
> when he's absent to defend himself is not ethical.
I certainly didn't wait to say this until he's absent
>> smartdrv is an entirely different beast, that knows a lot about the
>> underlying DOS; expecting compatibility with SMARTDRV is probably beyond
>> the requitrements of this project (wouldn't hurt for sure, but not
>> *required* )
> I agree, but as I use it every day with FreeDOS, I think that besides the
> obscure incompatibility with its delayed write feature on FAT32 that I
> reported (which may well be a bug in SMARTDRV itself that doesn't reveal
> in MS-DOS!) I haven't noticed any other problems with it under FreeDOS.
one reason for different behaviour *might* be that smartdrv traps
int25/int26, which is used differently in FreeDOS (not everything is
rooted through it)
>> *very* easy to fix if you have softice loaded.
>>
>> boot normal.
>> softice>bpint 13 ah=2
>> softice>bpr 0:0 a000:0 t
>> softice>boot (which reboots the machine, but leaves s-ice
>> softice>active, and you can step booting !!)
> Yes, the great SoftICE! Sweating on the scene is good, but now I'd prefer
> to be among the public and see if anyone else can sweat instead of me ;-)
> Let's give a chance to the young generation ;-)
I wouldn't hold my breath if I'd like to see this bug fixed.
>> It's been a pleasure for me to work with Bart, you and the nearly
>> forgotten victor who gave us FAT32 in a very ompressive way.
> Victor Vlasenko? Can you write more about this remarkable achievement of
> his? I'm sure that such people may not be, can not be, and are not
> forgotten!
a) he implemented FAT32
b) he implemented FAT32 virtually bugfree on first try
without 25 'please everybody test this' alpha releases.
he probably tested it himself before publishing.
c) he implemented FAT32 - and virtually every single line he changed
was necessary to do the job. no additional noise at all.
he probably optimized for smallest diff.
>> It's good enough for what I do, and I take care that it remains that way.
> So this is your role since you stopped active kernel development - to act
> as a kind of Kerberos, and thus prevent the only person who still actively
> works on the kernel from having impact on it!
yes.
and while I see no purpose in what he's doing in general, I look at
his changes, and what makes sense (to me), goes into my branch as well.
> Which means that the kernel development has virtually stopped now. How
> sad...
bug fixing will probably never stop, but squeezing single byte out of
it is IMO a complete waste of time.
you may have seen that while I stopped to work regularily on the
kernel, I probably made Stev Gibson happy with FreeDOS (stacks=9,256),
made FreeDOS load DD1000XX.SYS, made freedos kernel load Intel Pro1000
network driver, and found one reason for panic('too many fnodes in use')
4 serious real world bugs; so I wouldn't call my branch dead.
tom
---
This SF.Net email is sponsored by OSTG. Have you noticed the changes on
Linux.com, ITManagersJournal and NewsForge in the past few weeks? Now,
one more big change to announce. We are now OSTG- Open Source Technology
Group. Come see the changes on the new OSTG site. www.ostg.com
___
Freedos-kernel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] More kernel bugs and incompatibilities
>> Remember that Steve Gibson went round trip back to FreeDOS after >> evaluating several other DOSes so this means that FreeDOS can't be that >> bad :) a) other DOS's were just too expensive b) his problems seem to have been entirely related to the 2033 kernel default stacksize of 128 byte c) he uses VERY few DOS functions; IMO Spinrite might even work with ke2028 (which had still MANY bugs) >> I just hope that if I ever need spinrite myself Steve can pay >> back by giving me a free copy ;) I's sure he'll be happy to send you a license; I'm proud owner of it already. > ;-) ;-) ;-) You're right. It's not bad at all. good *enough* for me (at least the part I use) > You know I like it, but I'm > afraid the remaining bugs (I don't mean just "my" bugs of course) may play > bad jokes on us in the future if not fixed. Besides, Steve can't afford to > use any DOS illegally. So if I were him, I'd choose FreeDOS too. it's just the question, if it's good enough for the job at hand. if 'yes' - use it. if 'no' - it's far too expensive, even if free. tom --- This SF.Net email is sponsored by OSTG. Have you noticed the changes on Linux.com, ITManagersJournal and NewsForge in the past few weeks? Now, one more big change to announce. We are now OSTG- Open Source Technology Group. Come see the changes on the new OSTG site. www.ostg.com ___ Freedos-kernel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] More kernel bugs and incompatibilities
Hello Luchezar, >> or call the 'optimized' kernel keUNSTABLExxx or keARxxx, as the main >> stream kernel should concentrate on FIXING bugs, rather then introducing >> new ones. > 100% agreed. Since I use "unstable" kernel every day in practice, I think > it has no more bugs than the "stable" one. that you use it doesn't mean there are no news bugs. e.q. the complete ioctl was 100% mixed/changed/... how many ioctl's are you using - not every day, but at least once per month? do you use MS-LANMAN networking (at least once per month)? etc... just because YOU don't find bugs (old or new) doesn't mean there are no (old or new) bugs. in particular (by your own finding) the new SYS is buggy ( if loadseg != 60), but you only found out after using SYS (at least once). this shall not imply the arkady introduces new bugs every other day (although I've seem a couple of OOPS's); it's simply that I can't verify (perr review) what he changed simply because his stupid 'change everything' attitude. and so I won't touch the arkady branch with a 3 meter long stick. > But during the last few weeks I > noticed several more bugs and incompatibilities present in both "stable" > and "unstable" branches, most of them extremely difficult to fix, namely: > 1. While copying a directory tree containing many LFNs *without* DOSLFN > loaded and *with* delayed write of SMARTDRV in a FAT32 directory, many > invalid directory entries are created, which consist of parts of the > contents of the copied files. Turning delayed write off makes the bug > vanish. If FreeDOS ir replaced by MS-DOS or if copying to a FAT16 > directory under FreeDOS, there is no bug. if you are using (and distributing) SMARTDRV, you can also distribute msdos xx. smartdrv is an entirely different beast, that knows a lot about the underlying DOS; expecting compatibility with SMARTDRV is probably beyond the requitrements of this project (wouldn't hurt for sure, but not *required* ) you didn't report, if the same problem happens with LBACACHE. > 3. If load segment (/L option) was different than 60h, bootstrap causes a > read error during the loading of the kernel if it's longer than about 62 > KB. The exact value of the load segment doesn't matter, and the bug > reveals for *any* value other than 60h. *very* easy to fix if you have softice loaded. boot normal. softice>bpint 13 ah=2 softice>bpr 0:0 a000:0 t softice>boot (which reboots the machine, but leaves s-ice softice>active, and you can step booting !!) > 4. SYS hangs up or causes an invalid opcode at the time of reading the > boot sector of my ATA flash cards, if compiled by anything than Watcom. > Non-Watcom versions of SYS work on all other drives. again - softice should be your friend. > So, as a prospective user of the kernel, after contributing to it for more > than an year, I can conclude than it's good enough for simpler tasks not > involving writing a lot of long named files on a FAT32 partition. For more > complex tasks, however, MS-DOS 7.1, PC-DOS 7.1 and ROM-DOS 7.1 are more > suitable. not 'complex tasks'. for tasks involving LFNDOS and creating new files; creating a lot of them just makes it more probable to happen. > Thank you for your attention. It's time for me to concentrate on other > tasks. It's been a pleasure for me to work with you guys. I hope that > FreeDOS will be THE DOS one day. But hardly "real soon now"... It's been a pleasure for me to work with Bart, you and the nearly forgotten victor who gave us FAT32 in a very ompressive way. For me, it's THE dos today - and I can affort to distribute a junk DOS even less then Steve Gibson. It's good enough for what I do, and I take care that it remains that way. tom --- This SF.Net email is sponsored by OSTG. Have you noticed the changes on Linux.com, ITManagersJournal and NewsForge in the past few weeks? Now, one more big change to announce. We are now OSTG- Open Source Technology Group. Come see the changes on the new OSTG site. www.ostg.com ___ Freedos-kernel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] exeflat (2035-Arkady) start segment must be variable
Hello Luchezar, > I didn't know that there are TWO kernel builds called 2035a... Perhaps you > should call yours 2035b where b = Bart (a = Arkady ;-) or call the 'optimized' kernel keUNSTABLExxx or keARxxx, as the main stream kernel should concentrate on FIXING bugs, rather then introducing new ones. tom --- This SF.Net email is sponsored by OSTG. Have you noticed the changes on Linux.com, ITManagersJournal and NewsForge in the past few weeks? Now, one more big change to announce. We are now OSTG- Open Source Technology Group. Come see the changes on the new OSTG site. www.ostg.com ___ Freedos-kernel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] Versions and builds, conservatism
Hello Luchezar, > OK, long live the holy conservatism that saves the FreeDOS world > from the Arkadifying hell ;-G By 100% agreed tom --- This SF.Net email is sponsored by OSTG. Have you noticed the changes on Linux.com, ITManagersJournal and NewsForge in the past few weeks? Now, one more big change to announce. We are now OSTG- Open Source Technology Group. Come see the changes on the new OSTG site. www.ostg.com ___ Freedos-kernel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-kernel
[Freedos-kernel] bug in kernel 2035ar
downloaded ke2035ar. just did what I did for 3 years in a row: copy my old CONFIG.BAT saidc:>BUILD and got Compilation was aborted! congratulations :(( tom --- This SF.Net email is sponsored by BEA Weblogic Workshop FREE Java Enterprise J2EE developer tools! Get your free copy of BEA WebLogic Workshop 8.1 today. http://ads.osdn.com/?ad_id=4721&alloc_id=10040&op=click ___ Freedos-kernel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] Strange bug in kernel 2035
Hello Eduardo,
> I've found what seems an odd bug in the kernel (version 2035) while
> testing a first alpha version of nlsfunc and it is driving me mad:
> In nls.c:muxLoadPkg(), the value of cp becomes 0 right after the first
> call to muxGo() (the one that does the installation check).
solved:
*** nls.c, 98:
STATIC COUNT muxGo(int subfct, UWORD bp, UWORD cp, UWORD cntry, UWORD bufsize,
void FAR *buf, UWORD *id)
{
int ret;
iregs r;
log(("NLS: muxGo(): subfct=%x, cntry=%u, cp=%u, ES:DI=%p\n",
subfct, cntry, cp, buf));
/* ret = call_nls(subfct, &nlsInfo, bp, cp, cntry, bufsize, buf, id);
mov al, [bp + 4]; subfct
mov ah, 0x14
mov si, [bp + 6]; nlsinfo
mov bx, [bp + 10] ; cp
mov dx, [bp + 12] ; cntry
mov cx, [bp + 14] ; bufsize
les di, [bp + 16] ; buf
pushbp
mov bp, [bp + 8]; bp
int 0x2f
pop bp
mov bp, [bp + 20] ; store id (in
SS:) unless it's NULL
or bp, bp
jz nostore
mov [bp], bx
*/
r.a.b.h = 0x14;
r.a.b.l = subfct;
r.si = (short)&nlsInfo;
r.bp = bp;
r.b.x = cp;
r.d.x = cntry;
r.c.x = bufsize;
r.di = FP_OFF(bp);
r.es = FP_SEG(bp);
intr(0x2f,&r);
if (*id)
*id = r.b.x;
ret = r.a.x;
log(("NLS: muxGo(): return value = %d\n", ret));
return ret;
}
int2f,406
+%if 0
; moved into intr() style by tom
; extern UWORD ASMCFUNC call_nls(UWORD subfct, struct nlsInfoBlock *nlsinfo,
; UWORD bp, UWORD cp, UWORD cntry, UWORD bufsize, UWORD FAR *buf, UWORD *id);
global _call_nls
_call_nls:
int2f, 439:
ret
+%endif
additionally, you need my recent patch, that makes intr available again.
tom
---
This SF.Net email is sponsored by BEA Weblogic Workshop
FREE Java Enterprise J2EE developer tools!
Get your free copy of BEA WebLogic Workshop 8.1 today.
http://ads.osdn.com/?ad_id=4721&alloc_id=10040&op=click
___
Freedos-kernel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] SYS fix
Hello Arkady, > Some times I report about bugs in SYS. Unfortunately, these reports was > completely ignored. (tom, what about "discussion"?) to make one thing clear - once and for all time: you post about 10 changes to this list - do you really expect that everyone reads, tries to understand, and 'discuss' this ? as I'm not using SYS anyway, my interest in it is fairly reduced; if it does exist at all; why should I 'discuss' that ? I AM interested in kernel and freecom, that's enough. > Currently, I write completely new SYS > (tom, and not say later, that I not offer discussion here!). you'll write a COMPLETELY NEW sys anyway - what's to be discussed here ? just go ahead. but don't be surprised if noone is going to use it. > Before this, Lucho prepares some fixes for current SYS. I have no opinion in SYS - as long as LUCHO does them. a) he tends to fix BUGS b) he tends to fix them by changing 3 lines. c) he probably tested them as well. tom --- This SF.Net email is sponsored by BEA Weblogic Workshop FREE Java Enterprise J2EE developer tools! Get your free copy of BEA WebLogic Workshop 8.1 today. http://ads.osdn.com/?ad_id=4721&alloc_id=10040&op=click ___ Freedos-kernel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] Boot sector OEM name
Hello Arkady, > Eric offers: - memcpy(bs->>OemName, "FreeDOS ", 8); + memcpy(bs->>OemName, "FRDOS4.1", 8); > Otherwise, Win9x/.. will sometimes ignore boot sector BPB (yuck!). > Value must be 5 uppercase letters, a digit (4 or 5), a dot, then a digit. > Is there any objection against this? if all your mails would be like that, we could become friends: mentions bug reason, provides a fix, and changes one line only. my objection is, that we mimic dos 5.x (or better), and that it doesn't hurt to include the reason for change. so I offer memcpy(bs->OemName, "FRDOS5.1", 8); /* Win9x seems to require 5 uppercase letters, digit(4 or 5) dot digit */ tom --- This SF.Net email is sponsored by BEA Weblogic Workshop FREE Java Enterprise J2EE developer tools! Get your free copy of BEA WebLogic Workshop 8.1 today. http://ads.osdn.com/?ad_id=4721&alloc_id=10040&op=click ___ Freedos-kernel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] ludivmul.inc
Hello Arkady, > - may/should be `static dmatch Dmatch;' in fcbfns.c moved to stack in the > FcbFindFirstNext() (as in other functions in fcbfns.c)? I' abolutely NOT sure about that. you are right - it doesn't seem to make much sense. I have some dark memory, that I changed that (back in the dark ages), because else the stack would overrun it's 384 byte size, and dmatch is fairly large. please look up yourself - if that wasn't yet in ~2035, this was the reason to make it static. tom --- This SF.Net email is sponsored by BEA Weblogic Workshop FREE Java Enterprise J2EE developer tools! Get your free copy of BEA WebLogic Workshop 8.1 today. http://ads.osdn.com/?ad_id=4721&alloc_id=10040&op=click ___ Freedos-kernel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] Re: Smaller tour of 32bit stuff in kernel, optimize, bugs
Hello Eric,
>> EA> LBA_Transfer should call the appropriate int 2f.xx function before
>> EA> calling play_dj - or play_dj should call it itself: This allows
>> EA> GUIs to return "okay, notified, please suppress DJ text message".
> INT 2F CU - DOS 5+ - FLOPPY-DISK LOGICAL DRIVE CHANGE NOTIFICATION
> AX = 4A00h
> CX = h
> DH = new drive number
> DL = current drive number
> Return: CX = h to skip "Insert diskette for drive X:" message
> Note: called by MS-DOS 5.0+ IO.SYS just before displaying the message
> "Insert diskette for drive X:" on single-floppy systems
these are nearly implementation instructions - I wasn't aware of this
call. you could have posted it the first time.
unfortunately AFAICS RBIL intermixed DH and DL here (it has an
advantage to be proud owner of MSDOS :)
changes needed:
hdr\pcb.h, 691
unsigned ASMPASCAL intr(int nr, iregs * rp);
INTR.ASM, 136:
no_read_error:
ret
+ global INTR
+INTR:
+ INTR
segment INIT_TEXT
;
DSK.C, 231
if (i == blk_dev.dh_name[0])
{
put_string("Error in the DJ mechanism!\n"); /* should not happen! */
}
else
{
+ /* according to RBIL (te 22 jul 04) */
+ iregs r;
+
+ r.a.x = 0x4a00;
+ r.c.x = 0x;
+ r.d.b.l = pddt->ddt_logdriveno;
+ r.d.b.h = pddt2->ddt_logdriveno;
+
+ intr(0x2f,&r);
+
+ if (r.c.x == 0x)
+ {
+ /* someone else makes a nice dialog */
+ }
+ else
+ {
template_string[DRIVE_POS] = 'A' + pddt2->ddt_logdriveno;
put_string(template_string);
put_string("Insert");
template_string[DRIVE_POS] = 'A' + pddt->ddt_logdriveno;
put_string(template_string + 6);
put_string("Press the any key to continue ... \n");
fl_readkey();
+ }
tom
---
This SF.Net email is sponsored by BEA Weblogic Workshop
FREE Java Enterprise J2EE developer tools!
Get your free copy of BEA WebLogic Workshop 8.1 today.
http://ads.osdn.com/?ad_id=4721&alloc_id=10040&op=click
___
Freedos-kernel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] Smaller tour of 32bit stuff in kernel, optimize, bugs
Hello Arkady, >>> For drives beyond lastdrive, get_cds result protects from crashes, >>> but in between, access to unformatted disks returns nonsense for >>> int 21.36 and even crashes while trying to do critical error dialog te>> really ? te>> please provide exact code sequence where it DOES return nonsense - and te>> I'll fix it. (we are talking about ke2035 !!) > Bernd and Eric many times report, that WHICHFAT utility behaves wrongly > under FreeDOS. If you blindly ommit those reports, then this not close the > fact, that this happens. and why didn't you fix it long ago ? >>> LBA_Get_Drive_Parameters should NOT disable LBA access if heads or >>> sectors are > 64k te>> As I wrote this: > WHEN why don't you go to HISTORY.TXT ? > AND WHERE?! most probably in aachen, western germany, 3'rd planet in solar system >>> but should be mentioned in kernel docs (<-> DEVICEHIGH/LOADHIGH). te>> which kernel docs ? > config.txt? this isn't an issue of *additional, non-standard* config.sys sysntax. tom --- This SF.Net email is sponsored by BEA Weblogic Workshop FREE Java Enterprise J2EE developer tools! Get your free copy of BEA WebLogic Workshop 8.1 today. http://ads.osdn.com/?ad_id=4721&alloc_id=10040&op=click ___ Freedos-kernel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] Re: Smaller tour of 32bit stuff in kernel, optimize, bugs
Hello Eric, >> > DosGetFree (FatGetDrvData int 21.1c/21.36) can crash, maybe because of >> > a NULL navc pointer. >> If so, please submit some code to make the kernel crash. >> if not, shut up. > I did. Read and shut up: > http://www.ibiblio.org/pub/micro/pc-stuff/freedos/files/dos/format/format-0.91r.txt do you really expect me to occasionally search for such texts ? I haven't seen any such report on the kernel list, or in bugzilla yes - it contains indeed code that crashes the kernel although it's for DOSEMU and the optimized ke2035a, I'll check in a real machine with ke2035; if that crashes as well, it'll be fixed soon. 1 hour later: I checked that. what I did: I have a drive, that is definitivlely not proper formatted, and if I say DIR K: I get some Abort/retry/fail dialog. I tried this with the mentioned (format-0.91r.txt) functions 21.36 and 21.1c I don't know if the behaviour is the same as in MSDOS (returning carry set or not, returning same register values etc.), but at least ke2035 on real hardware behaves completely *reasonable* and does not crash. while I won't buy you another DOS (you destroyed your own copy of MSDOS yourself and on purpose), you CAN get ke2035, and you CAN test it on real hardware. >> > Maybe saturation would be better. How do other DOSes handle this? >> maybe would be better that YOU check other DOS'es behaviour BEFORE > Buy me another DOS or shut up. just assume that the people who wrote this code compared it to other DOS's while writing it (I know). so buy another DOS or shut up >> please provide exact code sequence where it DOES return nonsense - and >> I'll fix it. (we are talking about ke2035 !!) > That translates to: Provide a fix and you will have provided a fix. Helpful. I intended to say (as above, but didn't exactly say it): provide some sort of mov ax,XXX mov dx,YYY int 21h --> misbehaviour (wrong return value, crash or just reboot) and the cavalry is set into march >> there is no 32/16 and 32%16 compiler support, only 16/16 and 32/32. >> end of story. > Compiler weakness :-P. compiler facts >> > or if totalSectHigh is nonzero. >> this will be relevant when disk (arrays) are larger then >> 2 TB (not that far away) >> but then we good old partitioning scheme stops to make sense, >> and it's better not to touch these disks at all. > I vote for: Then you better only use the first 2 TB. I vote for: wait till 2TB disks arrive. see. possibly fix bugs. THEN remove this. > And you will probably have only a fraction of the DOS > partitions reachable at all if you drop to CHS mode. if you understood the new style partitioning scheme, you'd know that you'll have NO partition available for DOS anymore. >> > Track wrap protection and DMA wrap >> > protection should be turned off (maybe add a SYS CONFIG variable!) >> > for harddisks. >> nonsense again: there's a specific field in EXT13 functions... > I know that you cannot detect this. I can detect this. > BUT on the other hand I believe I measured - it's irrelevant. > that turning off track wrap protection and maybe also DMA wrap protection > can help to significantly improve performance, so it's not worth the effort. tom --- This SF.Net email is sponsored by BEA Weblogic Workshop FREE Java Enterprise J2EE developer tools! Get your free copy of BEA WebLogic Workshop 8.1 today. http://ads.osdn.com/?ad_id=4721&alloc_id=10040&op=click ___ Freedos-kernel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] Smaller tour of 32bit stuff in kernel, optimize, bugs
Hello Eric, > DosGetFree (FatGetDrvData int 21.1c/21.36) can crash, maybe because of > a NULL navc pointer. If so, please submit some code to make the kernel crash. if not, shut up. > I wonder if it is really desirable that the > current implementation fakes bigger cluster sizes to allow cluster > counts below 64k Probably Bart implemented it for sheer fun ? > Maybe saturation would be better. How do other DOSes handle this? maybe would be better that YOU check other DOS'es behaviour BEFORE writing emails, because you are just bored ? > For drives beyond lastdrive, get_cds result protects from crashes, > but in between, access to unformatted disks returns nonsense for > int 21.36 and even crashes while trying to do critical error dialog really ? please provide exact code sequence where it DOES return nonsense - and I'll fix it. (we are talking about ke2035 !!) > for int 21.1c - probably some 0:xx data or stack got overwritten. please provide exact code sequence where it DOES overwrite something - and I'll fix it. (we are talking about ke2035 !!) > LBA_Get_Drive_Parameters should NOT disable LBA access if heads or > sectors are > 64k As I wrote this: if sectors or heads are > 64K the LBA BIOS is probably buggy. and IMO it's better to refuse to work with a buggy BIOS then to try to trash a users disk. > or if totalSectHigh is nonzero. this will be relevant when disk (arrays) are larger then 2 TB (not that far away) but then we good old partitioning scheme stops to make sense, and it's better not to touch these disks at all. there could be some (easy) workarounds for that (my estimate less then a few hundred resident byte) + understanding dynamic disk partitioning (non resident code). until that is done it's a better idea not to touch these disks. > At several places, "ULONG / value" and "ULONG % value" could be > explicitly marked as "ULONG / UWORD" and "ULONG % UWORD" type, > to allow compiler optimizations (32:32->32 bits is more complex > on 8086 than 32:16->32 bits). as was relied before (but you are probably so busy writing emails rather then reading) : there is no 32/16 and 32%16 compiler support, only 16/16 and 32/32. end of story. > LBA_Transfer should call the appropriate int 2f.xx function before > calling play_dj - or play_dj should call it itself: which 2f.xx functions please ? > For the latter two, I recommend: > If buffer is exactly aligned, transfer limit should probably be > 64k, not 64k - 1 sector. nonsense. you simply cant issue a read request to DOS > 0x > Track wrap protection and DMA wrap > protection should be turned off (maybe add a SYS CONFIG variable!) > for harddisks. nonsense again: there's a specific field in EXT13 functions, if DMA crossing is allowed or not (and the kernel doesn't care about it) doesn't make a difference anyway. > There is also UMB avoidance: If a buffer is in > UMB or HMA, all access is copied through the low RAM disk transfer > buffer (which is only 1 sector big). Probably required, definitively for EMM386 style UMB's (lacking Virtual DMA support) on some UMBPCI machines > but should be mentioned in kernel docs (<-> DEVICEHIGH/LOADHIGH). which kernel docs ? tom --- This SF.Net email is sponsored by BEA Weblogic Workshop FREE Java Enterprise J2EE developer tools! Get your free copy of BEA WebLogic Workshop 8.1 today. http://ads.osdn.com/?ad_id=4721&alloc_id=10040&op=click ___ Freedos-kernel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] Optimization idea: DIV/MODULO never full 32=32/32bit
Hello Eric, > Somebody else already tuned the clock driver: > ticks = ((ticks / 59659u) << 16) + ((ticks % 59659u) << 16) / 59659u; > ... scaling factor 1193180/6553600 = 59659/327680 = 59659/65536/5 ... done by Bart and me ~2002 (50% by me, and Bart gave it the final touch) compared to the original ( ~2023 ) kernel, that saved 2* more code then ALL 100+ combined microoptimizations by this young russian talent. and THEN it's worth doing it - else it induces only bugs. tom --- This SF.Net email is sponsored by BEA Weblogic Workshop FREE Java Enterprise J2EE developer tools! Get your free copy of BEA WebLogic Workshop 8.1 today. http://ads.osdn.com/?ad_id=4721&alloc_id=10040&op=click ___ Freedos-kernel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] Re: FreeCOM
->>> BREAKS FreeCOM and possibly also FDAPMs "Am I run from INSTALL=?" > 1. MS-DOS-style mean two \0 and 2035a produces two \0. EA>> So Arkady has optimized away 4 "wasted" bytes in environment, > 6. PLONK. tom --- This SF.Net email is sponsored by BEA Weblogic Workshop FREE Java Enterprise J2EE developer tools! Get your free copy of BEA WebLogic Workshop 8.1 today. http://ads.osdn.com/?ad_id=4721&alloc_id=10040&op=click ___ Freedos-kernel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] About Eric's CLUSTER v ULONG remarks.
Hello Arkady, BO>> Or ULONG or u32 or uint32_t or uint_least32_t or simply "unsigned long". BO>> These structures aren't portable anyway. What's in a name? > Nothing in C/C++ is portable, this is nature of these languages, which > present only machine specific types. But BYTE/WORD/DWORD types are > explicitly developed to ease portability. About uint32_t: good name, but > DWORD (UDWORD) is more traditional. :) the kernel has a 10 year tradition to use ULONG, but you aren't going to play by any rule anyway :(( >>> PS: Do you see the patch from tom, related to unfreed near fnodes at >>> critical handler? BO>> Yes. > And? For me, it looks as "quick and dirty" hack, may be there is better > ways for "garbage collection" over near fnodes? I agree - it's a damned dirty hack. but I haven't found a way so far to do it better - and I *had* to find a solution for this problem. tom --- This SF.Net email is sponsored by BEA Weblogic Workshop FREE Java Enterprise J2EE developer tools! Get your free copy of BEA WebLogic Workshop 8.1 today. http://ads.osdn.com/?ad_id=4721&alloc_id=10040&op=click ___ Freedos-kernel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] Kernel patch policy, branches, and FreeCOM
Hello Eric, > I am sure 2035a fixes several bugs of 2035 found the ret_ah bug. if that has real world implications is unknown. found the Ulong 32%32 bug - impressive, but 100% irrelevant to the kernel as all real world use will work 100% ok. claims to have found a bug in umb_link code for a001: now it doesn't work either, and is again irrelevant as noone uses (for good reasons) /I=a000-afff possibly made the graphical MENU better - but certainly broke Eric's and mine non-graphical config.sys found a bug so now MS Smartdrv loads - unfortunately now FreeCOM doesn't work any longer (even if that's a bug) IMO that's less then impressive just as a OT sidenote, found somewhere on joelonsoftware.com: the old WIN developers took it *personally* if some old stuff wouldn't run any longer. this went as far as: they found that SIMCITY would run beutiful on DOS, but crash in windows. after some lengthy debugging they found that simcity frees some memory - and uses it afterwards. sure this works in DOS - and fails badly in a multitasking environment where this memory is reused by someone else. now there 2 solutions for that solution a) say this code is buggy, ask manufacturer solution b) implement 'is the current task simcity ?' if so, delay the *real* free for a couple of seconds. they (the MS developers) took b) and for me this ends the threat. tom --- This SF.Net email is sponsored by BEA Weblogic Workshop FREE Java Enterprise J2EE developer tools! Get your free copy of BEA WebLogic Workshop 8.1 today. http://ads.osdn.com/?ad_id=4721&alloc_id=10040&op=click ___ Freedos-kernel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] ludivmul.inc
BB>> replace "readable" by "understandable for inexperienced C programmers" > Unimportant. here I have to agree - kernel programming is nothing for inexperienced programmers, and will never be. > Note: this is myth. well - my private email archives show that 'arkadifying code' is used as synonym for 'hardly understandable cryptic stuff' - both incoming and outgoing. SOMETIMES this may be useful - and we used it: the kernel's memory model is probably beyond most peoples understanding using it ALL the time is nonsense. However, the main kernel programming style was set forth ~10 years ago by Pat Villani in the kernel original sources. Both Bart and I didn't agree 100% with it (COUNT is discussable at least), but agreed to KEEP this style as much as reasonable. > You often read tom's words about "russian magician, > which makes cryptic code" and you trust these words. Yes, sometime I use not > very common tricks, but I (always) try to comment all such places! If you > see my code (and, especially compare it with original code), you find this. > For example, compare original ludivmul.inc and my edition. I think, > this is light example of what is my changes. > Another example. Remeber, as you try to comment Umb_State in config.c, > which was initialized by magic value 0, 1, 2? Compare _now_ with my edition, > where used (commented) enumerations UMB_NONE, UMB_DONE and UMB_REQ. > And, if sometime my comments not enough, I alway open and hear, and may > comment more, if this will be asked. > --- > This SF.Net email is sponsored by BEA Weblogic Workshop > FREE Java Enterprise J2EE developer tools! > Get your free copy of BEA WebLogic Workshop 8.1 today. > http://ads.osdn.com/?ad_idG21&alloc_id040&oplick > ___ > Freedos-kernel mailing list > [EMAIL PROTECTED] > https://lists.sourceforge.net/lists/listinfo/freedos-kernel -- Best regards, Tom Ehlert mailto:[EMAIL PROTECTED] +49-241-79886
Re: [Freedos-kernel] ludivmul.inc
Hello Bernd, >>BB> to work out his changes. At a given moment, he should probably issue a >>BB> code-freeze and then make stuff more readable/review-able >> >> May you point, what in my code isn't readable (or, at least, less >>readable, than in original code)? :( well - he skipped the 'reviewable' part - noone will want to review all of the kernel anyway. tom --- This SF.Net email is sponsored by BEA Weblogic Workshop FREE Java Enterprise J2EE developer tools! Get your free copy of BEA WebLogic Workshop 8.1 today. http://ads.osdn.com/?ad_id=4721&alloc_id=10040&op=click ___ Freedos-kernel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] FreeDOS 2035a detail discussion: FreeCOM, menu compatibility
My dear Mr. Belousov, > _I_ _report_ bug in FreeCOM. If now FreeDOS is closer to MS-DOS and > FreeCOM now incorrectly works in both under MS-DOS and FreeDOS (with empty > environment), who wrong? do you really think a new kernel that breaks all installed FreeCOM's in the wild is an improvement ? Do you really want to force everyone to update to a new freecom? (people often update only one component) Do you really want to see all the 'updated to new kernel, now freecom doesn't work anymore' being a possibly talented programmer is one thing. but handling real world issues decently (and silently) seems not to be one of your virtues. tom --- This SF.Net email is sponsored by BEA Weblogic Workshop FREE Java Enterprise J2EE developer tools! Get your free copy of BEA WebLogic Workshop 8.1 today. http://ads.osdn.com/?ad_id=4721&alloc_id=10040&op=click ___ Freedos-kernel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] ludivmul.inc
Hi Bart, > In any case, I appreciate that a bug was found in ludivmul.inc so do I > What I don't like is that the fix from Arkady (for the 1000th time...) > does 3 things at the same time -- formatting, fixing, and optimizing. neither do I like that. > This makes it impossible to see where things are really fixed. See the > following is enough: > --- ludivmul.inc.~1.2.~ Sun Jan 27 14:13:07 2002 > +++ ludivmul.incTue Jul 20 00:35:31 2004 > @@ -88,10 +88,12 @@ > pop bx ; get dividend lo-word > mov cx, ax ; save quotient > mul di ; quotient * divisor hi-word (low only) > + pushdi ; save divisor hi-word > xchgax, di ; save in di > mov ax, cx ; ax=quotient > mul si ; quotient * divisor lo-word > add dx, di ; dx:ax = quotient * divisor > + pop di ; restore divisor hi-word > sub bx, ax ; dividend-lo - (quot.*divisor)-lo > mov ax, cx ; get quotient > pop cx ; restore dividend hi-word thanks for that. I was going to analyse it was well to find the REAL difference to apply to my kernel branch, your effort saves me some time and it's again remarkable how little changes are needed wrt. the 200+ line diff's arkady sends. > I'm sorry but I simply don't have the time to go through all the other > patches. neither do I - specially if they are 90% completely useless formatting changes, 9% introcing LPVOID and Cstr data types, with (at most) 1% hidden gem inside. > If they were reduced to just bug fixes I'll promise that I'll > have another look though -- I still monitor the mailing list every now and > then. Guys *any* project that wants to be close to a 1.0 release must be > in deep freeze, a stabilation, that means that we should really freeze the > mainline kernel for anything but bug fixes. No optimizations, no > reformatting, no new fancy macros, no nothing but bug fixes with the > minimal amount of lines changed. 110% agreed. > Of course feel free to have your own > branch, but I don't think it's in the interest of the project to > use that for a 1.0. > So I can make a deal, you isolate your bug fixes and I'll return and be > friendly, or you don't and I'll simply disappear. It's that easy. well - I maintain such a kernel branch; however not sure if I catch every hidden gem... of course source is available on request. tom --- This SF.Net email is sponsored by BEA Weblogic Workshop FREE Java Enterprise J2EE developer tools! Get your free copy of BEA WebLogic Workshop 8.1 today. http://ads.osdn.com/?ad_id=4721&alloc_id=10040&op=click ___ Freedos-kernel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-kernel
