You can subscribe to this list here.
2003 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
(60) |
---|---|---|---|---|---|---|---|---|---|---|---|---|
2004 |
Jan
(280) |
Feb
(411) |
Mar
(455) |
Apr
(367) |
May
(125) |
Jun
(155) |
Jul
(266) |
Aug
(131) |
Sep
(223) |
Oct
(76) |
Nov
(103) |
Dec
(132) |
2005 |
Jan
(70) |
Feb
(113) |
Mar
(57) |
Apr
(38) |
May
(110) |
Jun
(74) |
Jul
(365) |
Aug
(198) |
Sep
(116) |
Oct
(119) |
Nov
(184) |
Dec
(55) |
2006 |
Jan
(97) |
Feb
(70) |
Mar
(51) |
Apr
(16) |
May
(46) |
Jun
(176) |
Jul
(305) |
Aug
(427) |
Sep
(223) |
Oct
(121) |
Nov
(112) |
Dec
(48) |
2007 |
Jan
(16) |
Feb
(19) |
Mar
(67) |
Apr
(69) |
May
(48) |
Jun
(35) |
Jul
(26) |
Aug
(44) |
Sep
(33) |
Oct
(86) |
Nov
(15) |
Dec
(28) |
2008 |
Jan
(120) |
Feb
(7) |
Mar
(76) |
Apr
(47) |
May
(41) |
Jun
(24) |
Jul
(25) |
Aug
(34) |
Sep
(58) |
Oct
(7) |
Nov
(16) |
Dec
(40) |
2009 |
Jan
(17) |
Feb
(53) |
Mar
(121) |
Apr
(69) |
May
(28) |
Jun
(39) |
Jul
(12) |
Aug
(22) |
Sep
(25) |
Oct
(15) |
Nov
(53) |
Dec
(9) |
2010 |
Jan
(10) |
Feb
(30) |
Mar
(10) |
Apr
(44) |
May
(36) |
Jun
(14) |
Jul
(21) |
Aug
(19) |
Sep
(1) |
Oct
(6) |
Nov
(22) |
Dec
(11) |
2011 |
Jan
(10) |
Feb
(45) |
Mar
(6) |
Apr
(7) |
May
(38) |
Jun
(40) |
Jul
(248) |
Aug
(150) |
Sep
(124) |
Oct
(40) |
Nov
(36) |
Dec
(57) |
2012 |
Jan
(64) |
Feb
(22) |
Mar
(14) |
Apr
(20) |
May
(54) |
Jun
(27) |
Jul
(36) |
Aug
(63) |
Sep
(11) |
Oct
(4) |
Nov
(13) |
Dec
(33) |
2013 |
Jan
(49) |
Feb
(36) |
Mar
(8) |
Apr
(17) |
May
(34) |
Jun
(24) |
Jul
(45) |
Aug
(4) |
Sep
(14) |
Oct
(8) |
Nov
(3) |
Dec
(16) |
2014 |
Jan
(32) |
Feb
(10) |
Mar
(41) |
Apr
(35) |
May
(23) |
Jun
(9) |
Jul
(110) |
Aug
(9) |
Sep
(12) |
Oct
(6) |
Nov
(16) |
Dec
(77) |
2015 |
Jan
(249) |
Feb
(9) |
Mar
(95) |
Apr
(28) |
May
(126) |
Jun
(151) |
Jul
(11) |
Aug
(35) |
Sep
(258) |
Oct
(198) |
Nov
(123) |
Dec
(186) |
2016 |
Jan
(166) |
Feb
(100) |
Mar
(11) |
Apr
(4) |
May
(24) |
Jun
(13) |
Jul
(34) |
Aug
(18) |
Sep
(8) |
Oct
(49) |
Nov
(69) |
Dec
(33) |
2017 |
Jan
(20) |
Feb
(29) |
Mar
(2) |
Apr
(4) |
May
(33) |
Jun
(32) |
Jul
(16) |
Aug
(8) |
Sep
|
Oct
(67) |
Nov
(39) |
Dec
(4) |
2018 |
Jan
(29) |
Feb
(42) |
Mar
(2) |
Apr
(5) |
May
(13) |
Jun
(24) |
Jul
(160) |
Aug
(76) |
Sep
(64) |
Oct
(42) |
Nov
(47) |
Dec
(32) |
2019 |
Jan
(33) |
Feb
(29) |
Mar
(36) |
Apr
(11) |
May
(11) |
Jun
(18) |
Jul
(20) |
Aug
(11) |
Sep
(7) |
Oct
(16) |
Nov
(3) |
Dec
(20) |
2020 |
Jan
(10) |
Feb
|
Mar
(10) |
Apr
(13) |
May
(53) |
Jun
(26) |
Jul
(8) |
Aug
(20) |
Sep
(8) |
Oct
(60) |
Nov
(93) |
Dec
(119) |
2021 |
Jan
(20) |
Feb
(54) |
Mar
(26) |
Apr
(17) |
May
(200) |
Jun
(231) |
Jul
(124) |
Aug
(100) |
Sep
(25) |
Oct
(18) |
Nov
(17) |
Dec
(93) |
2022 |
Jan
(129) |
Feb
(59) |
Mar
(58) |
Apr
(70) |
May
(39) |
Jun
(22) |
Jul
(83) |
Aug
(110) |
Sep
(65) |
Oct
(80) |
Nov
(42) |
Dec
(19) |
2023 |
Jan
(145) |
Feb
(118) |
Mar
(179) |
Apr
(76) |
May
(46) |
Jun
(67) |
Jul
(76) |
Aug
(69) |
Sep
(31) |
Oct
(52) |
Nov
(82) |
Dec
(46) |
2024 |
Jan
(51) |
Feb
(97) |
Mar
(50) |
Apr
(51) |
May
(150) |
Jun
(96) |
Jul
(117) |
Aug
(87) |
Sep
(106) |
Oct
|
Nov
|
Dec
|
From: Alain <ala...@co...> - 2004-01-23 14:03:48
|
tom ehlert escreveu: > If someone does and writes the code [...] AND TESTS IT, I won't mind integrating it. tom is very touchy about this. But I believe he is right ;-) Thanks for all tom Alain |
From: Alain <ala...@co...> - 2004-01-23 14:01:21
|
Michael Devore escreveu: > [...] in the scope > of my current work, which involves extending features in HIMEM/EMM386 > for >64M, VCPI addition, and perhaps other new stuff, or fixing any > obvious bugs. Thank you, really very much :) > Which is all subject to Tom Ehlert's approval as > maintainer, naturally. ;-) Alain |
From: Alain <ala...@co...> - 2004-01-23 13:56:24
|
Eric Auer escreveu: > http://www.coli.uni-sb.de/~eric/stuff/soft/by-others/ edit07.zip > (still the same zip name, but EDIT now identifies itself as 0.7a) I really believe that you should allways have e differnt name even for very small changes ;-) Alain |
From: tom e. <te...@dr...> - 2004-01-23 12:41:54
|
LG> Regarding A20, I can't understand why the perfectly good Int LG> 15h AH=24h functions 0 to 3 (A20 disable / enable / get status / LG> query support) are not supported by all BIOS writers / releases?! neither can I understand that. LG> Isn't something so hardware-dependent supposed to be dealth by LG> BIOS rather than DOS?! But still some BIOSes do support these LG> functions, so wouldn't be a good idea to query this support LG> (function 3) and use it if it exists, Tom? a very good idea. Unfortunately all my 3 maschines report int15/ax=2403 no carry, ax=0, bx=1 'supported on keyboard controller' and int15/ax=2400,2401,2402 carry, ah=86 'function not supported' as I don't see ANY problems with A20 switching, I won't put any effort into that. If someone does and writes the code and has a maschine that supports int15/24 AND TESTS IT, I won't mind integrating it. tom |
From: Luchezar G. <lu...@ga...> - 2004-01-23 12:02:31
|
Hello, Regarding A20, I can't understand why the perfectly good Int 15h AH=24h functions 0 to 3 (A20 disable / enable / get status / query support) are not supported by all BIOS writers / releases?! Isn't something so hardware-dependent supposed to be dealth by BIOS rather than DOS?! But still some BIOSes do support these functions, so wouldn't be a good idea to query this support (function 3) and use it if it exists, Tom? Lucho |
From: Luchezar G. <lu...@ga...> - 2004-01-23 09:52:34
|
On Fri, 23 Jan 2004 03:28:47 +0800, Johnson Lam wrote: > Tom is doing a great job, I read some documents and hear the > discussing here and realize that coding memory manager is an > 'horrible' job. Indeed, both Tom and Michael did a wonderful job and we should all thank them! > According to our good old chinese(cantonese) tradition, I owe you guys > a dinner. You're very kind! Who knows, maybe some day we could meet? One never knows in our small world! ;-) Regards, Lucho |
From: Michael D. <Fre...@de...> - 2004-01-23 09:46:47
|
At 05:17 PM 1/23/2004 +0800, you wrote: >On Thu, 22 Jan 2004 22:00:01 +0100 (MET), you wrote: > >Hi Eric, > >>The XMS / HMA driver, e.g. HIMEM64, actually SHOULD test whether things >>go wrong (e.g. A20 slower than intended) and SOLVE (i.e. wait longer) >>the problem AUTOMATICALLY and DYNAMICALLY. Even if the extra test and >>the extra wait code makes the driver bigger. > >I agree. >And I see Michael already feedback, he's not refuse your suggestion, >actually I don't think anyone will. What he mention is a step by step >changes of the code, every step need testing to avoid new bugs >created. Also need Tom to do the final stage, that is to compile a new >version. I didn't refuse the A20 suggestion, but I'm not gonna be the one to do it. That part of HIMEM is some of Tom Ehlert's original code, and it appears from the code and source/FreeDOS comments that it was written that way for a purpose. If nothing else, it's simply not in the scope of my current work, which involves extending features in HIMEM/EMM386 for >64M, VCPI addition, and perhaps other new stuff, or fixing any obvious bugs. Which is all subject to Tom Ehlert's approval as maintainer, naturally. Anyway, changing the A20 code is his decision, and you -- not you personally, but a someone out there "you" -- would need to present him with the case for it and see if he agrees. |
From: tom e. <te...@dr...> - 2004-01-23 09:39:22
|
EA> My suggestion EA> in return: Use JMP SHORT to the exit-from-call code of one-out-of-3 EA> functions and save the space that would be needed for the exit-from- EA> call code in two-out-of-3 functions that way... Talking about ~20 bytes saving, but getting absolutely ugly, unmaintainable source as payback. forget it. EA> I think FDXMS already EA> does use this trick, but HIMEM does not...) Probably the reason it's ~450 byte larger. tom |
From: tom e. <te...@dr...> - 2004-01-23 09:36:23
|
JL> I format an old hard disk and boot up with floppy FreeDOS, when I try JL> to use DEVLOAD to run HIMEM64.EXE it crashed, but I can run FDXXMS.SYS JL> without any problem. DEVLOAD'ing HIMEM or FDXMS doesn't make much sense; DOS won't move into HMA that way. |
From: tom e. <te...@dr...> - 2004-01-23 09:36:20
|
Hello Patrick, PJL> On an IBM Thinkpad T20, using HIMEM64.EXE (uncompressed) and booting PJL> with PXELINUX+memdisk, I get a crash: PJL> Invalid Opcode at 3687 FFFF 0213 AA7D FFDC 0001 0E24 10A3 0000 0001 0000 0002 0001 what happens with HIMEM ? what happens with HIMEM64 /NOABOVE16 ? PJL> Booting the same image from a physical floppy, it does not crash. of course. |
From: Johnson L. <jo...@tm...> - 2004-01-23 09:17:30
|
On Thu, 22 Jan 2004 22:00:01 +0100 (MET), you wrote: Hi Eric, >The XMS / HMA driver, e.g. HIMEM64, actually SHOULD test whether things >go wrong (e.g. A20 slower than intended) and SOLVE (i.e. wait longer) >the problem AUTOMATICALLY and DYNAMICALLY. Even if the extra test and >the extra wait code makes the driver bigger. I agree. And I see Michael already feedback, he's not refuse your suggestion, actually I don't think anyone will. What he mention is a step by step changes of the code, every step need testing to avoid new bugs created. Also need Tom to do the final stage, that is to compile a new version. >About BIOS Antivirus software: Database updates are rather pointless, >as you would need a BIOS update to install the update. In the end it is >hard to do anything useful in the BIOS. Bigger software on disk can "analyze" >whether the boot sector e.g. stays resident in RAM and/or accesses other boot >sectors. The BIOS can only write-protect it (good) or compare it to some >known-as-harmless contents (not good, but done by Trend). I don't use Trend, so I've no idea how their engine work, but detect FreeDOS as a virus is a joke, it just let the users know how incompetence the software is. They should improve their analyse engine or remain it as a joke. I use 'F' brand virus scanner which the DOS version is FREE. It's working much better, at lease didn't conflict with FreeDOS. Rgds, Johnson. |
From: tom e. <te...@dr...> - 2004-01-23 09:17:07
|
EA> So now the problem: How do I detect redirection of EA> stdout? if (isatty(fileno(stdout))) ... |
From: Eric A. <eric@CoLi.Uni-SB.DE> - 2004-01-23 05:07:06
|
Hi, there is a suggestion to add /Z:help to FORMAT (sorry, not /help, limitations of the parser) which would display the LONG (> 25 lines) help text as well as some licensing and contributors info etc. ;-). So now the problem: How do I detect redirection of stdout? If it is hard to detect, then I would add a line at the bottom of the help text "use /Z:pagehelp to see the help pagewise" which would enable "wait for a key after every 25 lines". A third method would be a text at the bottom of the long help text "use FORMAT /Z:help | MORE to read this text pagewise". The long help text would be around 70 lines plus licensing and contributor info. By the way, an intermediate version with again more "Win98se kernel gives me a stupid BPB but I have to cope with it" code can be found on: http://www.coli.uni-sb.de/~eric/format-0.91M.zip No idea if it now works under Win98se kernel :-(. Eric. |
From: Eric A. <eric@CoLi.Uni-SB.DE> - 2004-01-23 04:51:02
|
Hi, I have modified EDIT a bit. Changes: New hotkeys ^N new ^O open ^S save Time display should now use country setting to decide am/pm <-> 24h display and proper separator (e.g. 23.59.59 <-> 11:59:59pm), blinking got fixed and alignment of time display for 1-digit hour values got fixed. A crash when displaying an error message for files > 64000 bytes got fixed. Hope all fixes really do what they should do :-). Changed source files: readme, edit.lsm, edit.txt (source of edit.hlp), message.c (clock), dflat.h (version string), menus.c (new hotkeys), editbox.c (exclude new hotkeys from verbatim typing), calendar.c (now displays sth. like "ctrl-f4 to close"), edit.c (big file error message). http://www.coli.uni-sb.de/~eric/stuff/soft/by-others/ edit07.zip (still the same zip name, but EDIT now identifies itself as 0.7a) PS: Talking about small fixes, is FAT32 sector read/write for DEBUG on the way? Eric. |
From: Eric A. <eric@CoLi.Uni-SB.DE> - 2004-01-22 21:00:04
|
Hi Johnson, to make things clear: The XMS / HMA driver, e.g. HIMEM64, actually SHOULD test whether things go wrong (e.g. A20 slower than intended) and SOLVE (i.e. wait longer) the problem AUTOMATICALLY and DYNAMICALLY. Even if the extra test and the extra wait code makes the driver bigger. About BIOS Antivirus software: Database updates are rather pointless, as you would need a BIOS update to install the update. In the end it is hard to do anything useful in the BIOS. Bigger software on disk can "analyze" whether the boot sector e.g. stays resident in RAM and/or accesses other boot sectors. The BIOS can only write-protect it (good) or compare it to some known-as-harmless contents (not good, but done by Trend). Eric. |
From: Johnson L. <jo...@tm...> - 2004-01-22 20:54:21
|
On Thu, 22 Jan 2004 21:00:21 +0100 (MET), you wrote: Hi >Hi, A20 problems? I may be repeating myself, but I recommend that >XMS memory managers do a TEST whether the A20 switching has worked Sorry, I have to repeat again: Users have no idea what is A20. And why it's important, so we must not scare them with many switches or long documentation. IMHO, memory manager need to smart enough to take care the jobs until abnormal situation happen. >PS: Did you know that FreeDOS is a VIRUS? Well, Trend ChipAway Virus >Guard thinks so. It checksums the boot sector before booting and compares I think Trend isn't update it's database for too long. Though FreeDOS is not thunderstrike famous but it take over many software distribution package from M$-DOS. (Personal opinion: Even DELL selling PC with FreeDOS, Trend should do something other than marketing ;-) Rgds, Johnson. |
From: Michael D. <Fre...@de...> - 2004-01-22 20:36:29
|
> >(Most suggestions for XMS drivers first have to pass the evil "but >the driver has to be VERY small in memory" barrier... My suggestion >in return: Use JMP SHORT to the exit-from-call code of one-out-of-3 >functions and save the space that would be needed for the exit-from- >call code in two-out-of-3 functions that way... I think FDXMS already >does use this trick, but HIMEM does not...) Maybe I'm missing something, but are you making minor byte-level post code optimization suggestions now in the development process? To do so would be premature. At this point the general idea would seem to be making the code work with the largest amount of machines and ensure stability via reasonably well-written code. Otherwise, I could probably whack 100+ bytes out of the HIMEM source code image if I applied most of the optimizations I've ever learned and wanted to rewrite or reposition large swaths of source code, plus make things a heck of lot less readable. It wouldn't be just changing jumps and returns. Were code size of a few byte savings an incredibly important issue at this time, the kernel plus shell would be far better recoded in optimized assembly language compared to trivial HIMEM tweaks. You could squeeze the footprints down substantially, probably well over a kilobyte total, possibly much more. And the kernel and shell are always with a FreeDOS system, unlike HIMEM which won't always be present (well, I suppose some people might replace the shell, but probably not to get it smaller). |
From: Eric A. <eric@CoLi.Uni-SB.DE> - 2004-01-22 20:00:24
|
Hi, A20 problems? I may be repeating myself, but I recommend that XMS memory managers do a TEST whether the A20 switching has worked every time and do some extra WAITING if not. Some of our memory managers just have a delay loop, and as AT style switching is slow, you may have to configure a longer delay. Bad idea, most users will not think that far. I think that would be worth "wasting" 20 or more bytes of resident driver size for the sake of secure operation. (Most suggestions for XMS drivers first have to pass the evil "but the driver has to be VERY small in memory" barrier... My suggestion in return: Use JMP SHORT to the exit-from-call code of one-out-of-3 functions and save the space that would be needed for the exit-from- call code in two-out-of-3 functions that way... I think FDXMS already does use this trick, but HIMEM does not...) As far as I know, AT style switching will always work after testing it once and PS2 style switching will always work after testing it once, so you only have to decide on switching style (PS2 preferred) at driver load time. Later only timing should be a problem. DURING the initial test you (of course) must not wait infinitely for the switch to work because that may never happen (e.g. PS2 style never works on very old computers...). Hm. Already wrote too much. You get the idea anyway :-). PS: Did you know that FreeDOS is a VIRUS? Well, Trend ChipAway Virus Guard thinks so. It checksums the boot sector before booting and compares it to a list of known boot sectors, it seems! Older BIOS virus protection systems just block the BIOS call "write to sector 0/0/1", so THOSE will not complain if you wait with enabling them until AFTER SYSing your disk. In both protection variants, the alarm will be a popup text window with some "Virus!? Proceed? Y/N" style user interface. EXTRA experience from that: The KERNEL does not clear the extra lines in video RAM if you select an higher video mode in config sys! At least the extra lines (e.g. what the virus guard has backed up before poping up) will scroll into the visible area later that way (not really scroll, but "jump", when the visible area suddenly grows by the mode change). Eric. |
From: Johnson L. <jo...@tm...> - 2004-01-22 19:28:50
|
On Thu, 22 Jan 2004 20:20:41 +0200, you wrote: Hi Lucho, >> I'll try your HIMEM64. >The mere act of compilation doesn't make the program mine - it's still Tom's ;-) Of course, but anyone contributed effort should be mentioned ;-) Tom is doing a great job, I read some documents and hear the discussing here and realize that coding memory manager is an 'horrible' job. According to our good old chinese(cantonese) tradition, I owe you guys a dinner. Rgds, Johnson. |
From: Luchezar G. <lu...@ga...> - 2004-01-22 18:28:23
|
On Fri, 23 Jan 2004 02:14:46 +0800, Johnson Lam wrote: > Is DYNALOAD freeware? Where can I download it? Unfortunately, no. It's from PC-DOS 7 and 2000. As it's just 1376 bytes, I could send it here, but as I already hear load voices against turning this list into a WAREZ distribution list, I won't :( > I'll try your HIMEM64. The mere act of compilation doesn't make the program mine - it's still Tom's ;-) Lucho |
From: Luchezar G. <lu...@ga...> - 2004-01-22 18:15:35
|
On 22 Jan 2004 12:36:54 -0500, Patrick J. LoPresti wrote: > Uh, oh. I may have spoken too soon. > > On an IBM Thinkpad T20, using HIMEM64.EXE (uncompressed) and booting > with PXELINUX+memdisk, I get a crash: > > Kernel allocated 40 Diskbuffers = 21280 Bytes in HMA > > Invalid Opcode at 3687 FFFF 0213 AA7D FFDC 0001 0E24 10A3 0000 0001 0000 0002 0001 > > Booting the same image from a physical floppy, it does not crash. > > If I use "DEVICE=fdxxms.sys ps2", instead of himem64.exe, it works fine... Here I suppose that just after the kernel has been moved to the HMA, the first far code call from it caused "invalid opcode" (note the FFFF:3687 address of the invalid opcode in the stack dump). What's probably happening here is that under these circumstances (PXE boot) your machine works better with PS/2-style A20 switching than with AT-style. And because HIMEM had tested AT-style and it worked, it assumed that it's OK to use it from that moment on. FDXXMS, on the other hand, has been expressly directed to use PS/2-style, so it works. Tom, why not do things the other way around? First test for PS/2-style A20 switching, and if it works, use it, else use AT-style swithing. This will also be more optimal for PS/2-style machines. Did you try this before? If so, what happened? Of course, the M$ HIMEM.SYS supports almost 20 different /MACHINE switches - something that FreeDOS HIMEM could hardly ever do! :-( Lucho |
From: Johnson L. <jo...@tm...> - 2004-01-22 18:14:51
|
On Thu, 22 Jan 2004 19:53:08 +0200, you wrote: Hi Lucho, Eric told me there're some problem with DEVLOAD, it's good and convenient so I hope someone can fix this. >Because unlike the much better and smaller DYNALOAD, DEVLOAD doesn't like the compressed HIMEM64.EXE (as distributed). By the way, I don't think that something basic like HIMEM64 should be loaded dynamically and not from CONFIG.SYS. Try the uncompressed one I sent here a couple of days ago... Is DYNALOAD freeware? Where can I download it? I'll try your HIMEM64. Thanks. Rgds, Johnson. |
From: Luchezar G. <lu...@ga...> - 2004-01-22 18:00:50
|
On Fri, 23 Jan 2004 01:43:22 +0800, Johnson Lam wrote: > I format an old hard disk and boot up with floppy FreeDOS, when I try > to use DEVLOAD to run HIMEM64.EXE it crashed, but I can run FDXXMS.SYS > without any problem. Because unlike the much better and smaller DYNALOAD, DEVLOAD doesn't like the compressed HIMEM64.EXE (as distributed). By the way, I don't think that something basic like HIMEM64 should be loaded dynamically and not from CONFIG.SYS. Try the uncompressed one I sent here a couple of days ago... Lucho |
From: Patrick J. L. <pa...@us...> - 2004-01-22 17:45:43
|
Eric Auer <eric@CoLi.Uni-SB.DE> writes: > This version should now be foolproof enough to run even under Win9x, > and it sports yet another NEW command line switch /A. If you activate > that switch, the data clusters will start at a sector number which will > be a multiple of 8. This is useful for optimizing filesystems IF your > filesystem uses 4k or bigger cluster size. The /A switch will work for > smaller clusters, too, but ONLY if you have at least 4k cluster size you > will be able to use an optimized FAT32->NTFS conversion in WinXP or newer. (It might be nice to take a numeric argument like oformat does, in case the user wants a larger alignment. But 4K clusters are what MS recommends for NTFS, so I'm not complaining.) I can confirm that using "format /a" on a 4000M FAT32 partition and then converting it to NTFS on Windows XP yields a 4K cluster size on the NTFS volume. Excellent. Very nice work! - Pat |
From: Johnson L. <jo...@tm...> - 2004-01-22 17:43:22
|
On 22 Jan 2004 12:36:54 -0500, you wrote: Sorry for breaking in ... >If I use "DEVICE=fdxxms.sys ps2", instead of himem64.exe, it works >fine... I don't know it's same situation or not. I format an old hard disk and boot up with floppy FreeDOS, when I try to use DEVLOAD to run HIMEM64.EXE it crashed, but I can run FDXXMS.SYS without any problem. Rgds, Johnson. |