Re: [Freedos-devel] confused by NLS-settings
Hi Bernd, Briefly in DOS, both kernel and character device drivers are (or should be) codepage aware. - Kernel because of the collation tables, used for example to turn filenames into the uppercase, and so store them uppercased in the FAT - Character devices, because sending out a character to a character device should be codepage independent. Thus, each character device should know how to write certain byte of certain codepage. This all is controlled using character device's IOCTL call This all is broadly not used in the US, thus it is mostly loadable, in the sense that it isn't loaded by default kernel and character devices, and should be loaded as extensions. Finally, a kernel interrupt controls the codepage change (21h/6602h) in the system as a whole: changes the collation table and the character devices (issuing IOCTL's) globally. 2011/6/29 Bernd Blaauw bbla...@home.nl: This involves the following: * COUNTRY= (config.sys, COUNTRY.SYS / COUNTRY2.SYS / COUNTRY3.SYS) Set the initial collation table (data is retrieved from the specified file) * DISPLAY (a TSR by Aitor, versus device driver in MSDOS) CON extension: should control both keyboard and screen. To change screen's codepage, uses int9h. To change keyboard's codepage, calls KEYB (int 2Fh / AD81h) DISPLAY itself has a int 2Fh / AD00h backdoor, that can do all the IOCTL stuff: - MS-DISPLAY is a regular DOS device driver that overrides system CON (provides IOCTL to DOS' CON device) - FD-DISPLAY is a TSR, implements only the 2Fh / AD00h backdoor * NLSFUNC (with optional COUNTRY support, but only if not listed in config.sys yet?) Implements the logic behind 21h/6602h to change the codepage globally. * MODE versus MODECON versus different configurations whether or not COUNTRY= is set? MODE CON CP or MODE xxx CP is the DOS standard way to call IOCTL on the device xxx. Thus, could be used to change the codepage of the device xxx, but also for some other codepage aware functionality, such as loading codepage tables, etc. As FreeDOS DISPLAY is not a true device driver, for CON it must issue the 2Fh / AD00h backdoor, and thus MODECON was created. This functionality was included into FD MODE, thus MODECON is deprecated and must no longer be used. MODE xxx CP PREPARE is the way to load a codepage from certain CPI/CPX file (using IOCTL write from device xxx, or int 2Fh / AD00h for FD-DISPLAY) MODE xxx CP SELECT is the not recommended way to change the codepage for device xxx (using generic IOCTL from device xxx, or int 2Fh / AD00h for FD-DISPLAY). It leaves the system inconsistent: codepage should be changed for kernel and ALL the devices at the same time (21h/6602h), in other words, CHCP. * CHCP (internal command to FreeCOM) A simple call to 21h/6602h. * KEYB (and CPI/CPX files) The keyboard part of the CON extension. It really makes BIOS be codepage aware on keyboards. You miss PRINTER.SYS (if we had any), which would be the PRN extension. I haven't ever seen extensions to COMx devices, but I guess they should be (if they exist) device-dependent. * EDIT 0.9a prints its version and DFLAT banner at every invocation. in the background. If it causes problems, I have annotated to create a switch to turn it off. Aitor -- 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-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] confused by NLS-settings
Hello, 2011/6/29 Bernd Blaauw bbla...@home.nl: I remember DISPLAY 2.0 being troublesome with regard to UMBs, but that was years ago. It is not that it is trobulesome with regards to UMBs, but that you hardly ever have so much room in UMBs to load it. DISPLAY allows you to have a maximum of 5 codepages prepared in memory to be changed, and that is a bit less than 64 KB. After loading, in the commandline you usually only make room for 1 or 2 codepages (last parameter): DISPLAY CON=(EGA,437,1) and you barely use 11KB, but you don't know beforehard, thus DOS needs to reserve the whole of 64 KB just in case. Most modern versions use XMS and take lesser convenctional memory. Isn't MODECON deprecated / unnecessary?? Guess so, but that's what my entire help request is about. Confirmed. Eric introduced MODECON into MODE some versions ago. Did I mention hating CuteMouse 2.1b4's cursor/pointer refreshing speed in EDIT ? Like 5 times per second instead of once every 2 seconds or so :( There's a similar bug filled into EDIT that I marked as not reproduced, because I was never able to reproduce it, but I never tried CTMOUSE now that you mention it. So in the end it may end up being a CTMOUSE bug (or misconfiguration)? Aitor -- 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-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] confused by NLS-settings
Hello, 2011/6/30 Rugxulo rugx...@gmail.com: I remember DISPLAY 2.0 being troublesome with regard to UMBs, but that was years ago. It still needs a lot of unnecessary UMB room free to load there, e.g. 64 kb or some fairly high amount. And you may even have to explicitly mention it. I forget exactly and always (I think) loaded it low. Well, I'd have to check If only I could assume that there's ALWAYS XMS ;))) Ok, I'm revealing something about the next version (if I happen to find some spare time for it): There'll be a DISPLAYX.COM file that will refuse to load if there's no XMS. But if there is, then the maximally needed RAM will be of about 10-11 KB, thus the UMB trouble is gone. Could it be made even smaller? I have ideas to do so, but not so much motivation: - if I can asume everyone has a VGA card and stays in text mode - if I can asume that (J)EMM386 has the ROM= option implemented - ... NLSFUNC seems to be able to take COUNTRY.SYS file as an argument/parameter Yes, but it's hardcoded to a specific DISPLAY version, I think. Like I said, I never heavily used it (COUNTRY + NLSFUNC) since it lacked support for 853 anyways. Yes. The payload for being DISPLAY a TSR and not a device driver is that MODE and NLSFUNC are FD-DISPLAY specific (and tied to versions whenever int 2FH changed). I intended to turn it into a device driver once it is stable, but I don't really know if people prefer a TSR or device driver. * EDIT 0.9a prints its version and DFLAT banner at every invocation. Recompile? :-) Or just include a different editor (I'd cram TDE, if possible, or EZEDIT if not). Pretty stuck at using EDIT as a baseline replacement of MS EDIT. Other programs always welcome as extension. Well, the 64 kb file limit was a bit of a put-off for me, personally. Maybe good for average use, I guess (just not my favorite preference). If only I could asume that there is ALWAYS a DPMI... ;))) Well, from the above you see how much one would need a 386+ and VGA card as a minimum. Would be nice to know how many real FreeDOS users do not meet any of these two requirements. Aitor -- 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-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] confused by NLS-settings
Hi Aitor, Rugxulo, It still needs a lot of unnecessary UMB room free to load there, e.g. 64 kb or some fairly high amount. And you may even have to explicitly mention it. I forget exactly and always (I think) loaded it low. Well, I'd have to check If only I could assume that there's ALWAYS XMS ;))) As far as I remember, the main problem was that you did not want to require DOS 4.0 or newer and therefore first allocated MANY buffers, then reducing them. With DOS 4.0 or newer, can simply check at run-time whether the user-selected amount of buffers will fit into the available memory, even for device drivers :-) Could it be made even smaller? I have ideas to do so, but not so much motivation: - if I can asume everyone has a VGA card and stays in text mode You cannot assume that, but you could reload fonts from disk after the user returns to text mode. Would of course need some extra care to avoid doing that at the wrong moment but I guess reentrancy is less of an issue as you hook int 10, not int 21. - if I can asume that (J)EMM386 has the ROM= option implemented Evil idea but effective for real mode BIOSes. For VESA VBE 3 or similar VGA BIOSes, the actually used copy might be in higher memory around 3-4 GB but that is just a guess of me here. Pretty stuck at using EDIT as a baseline replacement of MS EDIT. Other programs always welcome as extension. Well, the 64 kb file limit was a bit of a put-off for me, personally. Maybe good for average use, I guess (just not my favorite preference). If only I could asume that there is ALWAYS a DPMI... ;))) There already are TDE, SETEDIT and others for 386 systems, so I would keep EDIT free of that. You could swap buffers of EDIT to XMS when XMS is available (detect at run-time). Regards, Eric -- All of the data generated in your IT infrastructure is seriously valuable. Why? It contains a definitive record of application performance, security threats, fraudulent activity, and more. Splunk takes this data and makes sense of it. IT sense. And common sense. http://p.sf.net/sfu/splunk-d2d-c2 ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] confused by NLS-settings
Op 10-7-2011 10:14, Aitor Santamaría schreef: Hi Bernd, * EDIT 0.9a prints its version and DFLAT banner at every invocation. in the background. If it causes problems, I have annotated to create a switch to turn it off. Programs usually don't print any banners or version output unless they themselves already fill half the screen with output. Try opening/editing/closing the same file about 10 times and you'll have a background full of banners/versions. I can't recall *any* other EDIT version reporting its version unless by /? or perhaps when starting an empty file. Also going to run UPX (--best --8086) over it to reduce filesize:) Aitor Bernd -- 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-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] confused by NLS-settings
Hi, On 7/10/11, Bernd Blaauw bbla...@home.nl wrote: Also going to run UPX (--best --8086) over it to reduce filesize:) --ultra-brute --lzma --8086 is optimal. But LZMA is a lot slower to unpack on really ancient machines, hence why it's not default for dos/mz. Heck, I think there's even (undocumented?) --small (but I can't remember if it makes a difference with dos/mz, surely not much anyways [few bytes]). -- 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-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] confused by NLS-settings
Hi, On 7/10/11, Eric Auer e.a...@jpberlin.de wrote: Pretty stuck at using EDIT as a baseline replacement of MS EDIT. Other programs always welcome as extension. Well, the 64 kb file limit was a bit of a put-off for me, personally. Maybe good for average use, I guess (just not my favorite preference). If only I could asume that there is ALWAYS a DPMI... ;))) There already are TDE, SETEDIT and others for 386 systems, so I would keep EDIT free of that. You could swap buffers of EDIT to XMS when XMS is available (detect at run-time). Don't forget InfoPad (included with CC386), it uses (modified) DFlat also, so maybe it could be adapted to (additionally) make EDIT386. You know what can edit arbitrary-sized files? sed !!! (My favorite!) Maybe that should be included in FreeDOS 1.1 by default! ;-)) http://lvogel.free.fr/sed.htm -- 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-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] confused by NLS-settings
On Sun, 10 Jul 2011, Bernd Blaauw wrote: I can't recall *any* other EDIT version reporting its version unless by /? or perhaps when starting an empty file. Which is the exact behavior of the QBASIC editor used in MS-DOS 5 and 6 (and PC DOS 5.x). Personally, I'd dispense with that - as MS also did with the second, standalone version of their editor (win9x, win2k/xp). -uso. -- 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-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] confused by NLS-settings
Hi Eric, 2011/7/10 Eric Auer e.a...@jpberlin.de: Hi Aitor, Rugxulo, It still needs a lot of unnecessary UMB room free to load there, e.g. 64 kb or some fairly high amount. And you may even have to explicitly mention it. I forget exactly and always (I think) loaded it low. Well, I'd have to check If only I could assume that there's ALWAYS XMS ;))) As far as I remember, the main problem was that you did not want to require DOS 4.0 or newer and therefore first allocated MANY buffers, then reducing them. With DOS 4.0 or newer, can simply check at run-time whether the user-selected amount of buffers will fit into the available memory, even for device drivers :-) You remember wrong. It's simply that if the reallocate call fails, DISPLAY won't load at all, and that is not desirable. Could it be made even smaller? I have ideas to do so, but not so much motivation: - if I can asume everyone has a VGA card and stays in text mode You cannot assume that, but you could reload fonts from disk after the user returns to text mode. Would of course need some extra care to avoid doing that at the wrong moment but I guess reentrancy is less of an issue as you hook int 10, not int 21. Change codepage can be called anytime. I can't just assume the disk/file will be there to reload. Anyway Eric, I won't discuss anymore about this. Be it public or private, it is boring to be talking about the same issues once and once again. If instead of talking you send me some code that works the way it is expected, I may merge it into the sources. Pretty stuck at using EDIT as a baseline replacement of MS EDIT. Other programs always welcome as extension. Well, the 64 kb file limit was a bit of a put-off for me, personally. Maybe good for average use, I guess (just not my favorite preference). If only I could asume that there is ALWAYS a DPMI... ;))) There already are TDE, SETEDIT and others for 386 systems, so I would keep EDIT free of that. You could swap buffers of EDIT to XMS when XMS is available (detect at run-time). I know. But it's a lot more complex ;) Aitor -- 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-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] confused by NLS-settings
Hi Aitor, It still needs a lot of unnecessary UMB room free to load there, e.g. 64 kb or some fairly high amount. And you may even have to explicitly mention it. I forget exactly and always (I think) loaded it low. Well, I'd have to check If only I could assume that there's ALWAYS XMS ;))) As far as I remember, the main problem was that you did not want to require DOS 4.0 or newer and therefore first allocated MANY buffers, then reducing them. With DOS 4.0 or newer, can simply check at run-time whether the user-selected amount of buffers will fit into the available memory, even for device drivers :-) You remember wrong. It's simply that if the reallocate call fails, DISPLAY won't load at all, and that is not desirable. At the moment, DISPLAY will fail to load into any normal-sized UMB which means people will avoid using DISPLAY at all, which is even less desirable than a failure to load it when you try to load it into a too small USB. In the latter case, you can still reduce the number of buffers or make a bit more space to load DISPLAY into an USB at the next boot. When DISPLAY always starts with huge initial heap size, there is no workaround possibly beyond not using it... That said, a possible fallback could be to allocate low memory ONLY if the reallocation call fails. Then you neither have to start with huge initial heap nor have to abort loading either. Change codepage can be called anytime. I can't just assume the disk/file will be there to reload. It could be a command line option to enable this - saving RAM at the expense of a limited risk of change codepage calls later. Actually if XMS is available, buffering there will avoid a risk. If instead of talking you send me some code that works the way it is expected, I may merge it into the sources. Such code would fail to load DISPLAY at all if the user wants too many buffers and tries to load DISPLAY into a too small UMB (unless the low memory fallback is implemented) so it is in a way a matter of taste how to fail under RAM shortage. My personal opinion is that most people will only need SMALL numbers of buffers, so you could have a fixed allocation for that. Then only explicitly selecting many buffers will have the risk of failed reallocation calls and can be documented. so I would keep EDIT free of that. You could swap buffers of EDIT to XMS when XMS is available (detect at run-time). I know. But it's a lot more complex ;) I know ;-) Eric -- All of the data generated in your IT infrastructure is seriously valuable. Why? It contains a definitive record of application performance, security threats, fraudulent activity, and more. Splunk takes this data and makes sense of it. IT sense. And common sense. http://p.sf.net/sfu/splunk-d2d-c2 ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] confused by NLS-settings
Hello, 2011/7/10 Eric Auer e.a...@jpberlin.de: Hi Aitor, It still needs a lot of unnecessary UMB room free to load there, e.g. 64 kb or some fairly high amount. And you may even have to explicitly mention it. I forget exactly and always (I think) loaded it low. Well, I'd have to check If only I could assume that there's ALWAYS XMS ;))) As far as I remember, the main problem was that you did not want to require DOS 4.0 or newer and therefore first allocated MANY buffers, then reducing them. With DOS 4.0 or newer, can simply check at run-time whether the user-selected amount of buffers will fit into the available memory, even for device drivers :-) You remember wrong. It's simply that if the reallocate call fails, DISPLAY won't load at all, and that is not desirable. At the moment, DISPLAY will fail to load into any normal-sized UMB which means people will avoid using DISPLAY at all, which is even less desirable than a failure to load it when you try to load it into a too small USB. In the latter case, you can still reduce the We all understood in the firs place. number of buffers or make a bit more space to load DISPLAY into an blah, blah as I said, I'm tired of talking about this with you again and again and again... That said, a possible fallback could be to allocate low memory ONLY if the reallocation call fails. Then you neither have to start with huge initial heap nor have to abort loading either. That is what LOADHIGH is supposed to do. Aitor -- 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-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
[Freedos-devel] File directory buffering and updates
I have a report from a user who is getting stale directory data when running the mTCP FTP server. They are running a TSR in the background which is updating a file once a day. If they connect to the FTP server and look at the directory they will see the date and size of the file at the time the FTP server started, not the most current values. Apparently a WATTCP32 based app has the same symptoms, but the Datalight Sockets FTP server does not. (I think the Datalight Sockets FTP server runs as a TSR, not a foreground app.) I use _dos_findfirst and _dos_findnext to read directories. These use function 0x4E. I expect that if there is a TSR modifying something in the background that calling the DOS function directly (as I am) should provide the most current results, but that is not what is being reported. Can somebody give me an idea of what I am missing? I am not sure what they would get if they tried to open the file and transfer it. I also don't know if the TSR is closing the file after each update - I imagine that leaving the file open would create problems. Regards, Mike -- 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-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] mTCP FTP performance (Was: watcom tcp
Op 7-7-2011 13:58, Michael B. Brutman schreef: Mike Mike, do you have any experience using UPX (executable file compressor) on your programs? I'm wondering if 1) programs still load properly for you on 8086 2) smaller disksize + in-memory-decryption faster than loading entire file. I'm pretty sure the compression program itself is 386+ or 586+, but compressed executables should be 8086+ if used with proper options. (upx.sf.net ) , upx --best --8086 c:\mtcp\*.exe Ultimate Packer for eXecutables Copyright (C) 1996 - 2010 UPX 3.07d Markus Oberhumer, Laszlo Molnar John Reiser File size Ratio Format Name -- --- --- 51974 - 32191 61.94% dos/exe dhcp.exe 39372 - 25975 65.97% dos/exe dnstest.exe 102256 - 56758 55.51% dos/exe ftp.exe 111996 - 58321 52.07% dos/exe ftpsrv.exe 87044 - 48833 56.10% dos/exe ircjr.exe 76430 - 44563 58.31% dos/exe nc.exe 40092 - 26488 66.07% dos/exe ping.exe 41660 - 27319 65.58% dos/exe sntp.exe 69230 - 40488 58.48% dos/exe spdtest.exe 86730 - 48854 56.33% dos/exe telnet.exe -- --- --- -- 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-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] mTCP FTP performance (Was: watcom tcp
On 7/10/2011 10:25 AM, Bernd Blaauw wrote:
Op 7-7-2011 13:58, Michael B. Brutman schreef:
Mike
Mike,
do you have any experience using UPX (executable file compressor) on
your programs? I'm wondering if
1) programs still load properly for you on 8086
2) smaller disksize + in-memory-decryption faster than loading entire file.
I'm pretty sure the compression program itself is 386+ or 586+,
but compressed executables should be 8086+ if used with proper options.
(upx.sf.net ) , upx --best --8086 c:\mtcp\*.exe
Ultimate Packer for eXecutables
Copyright (C) 1996 - 2010
UPX 3.07d Markus Oberhumer, Laszlo Molnar John Reiser
File size Ratio Format Name
-- --- ---
51974 - 32191 61.94% dos/exe dhcp.exe
39372 - 25975 65.97% dos/exe dnstest.exe
102256 - 56758 55.51% dos/exe ftp.exe
111996 - 58321 52.07% dos/exe ftpsrv.exe
87044 - 48833 56.10% dos/exe ircjr.exe
76430 - 44563 58.31% dos/exe nc.exe
40092 - 26488 66.07% dos/exe ping.exe
41660 - 27319 65.58% dos/exe sntp.exe
69230 - 40488 58.48% dos/exe spdtest.exe
86730 - 48854 56.33% dos/exe telnet.exe
-- --- ---
That looks very promising - I will test it out. I imagine that
decompression time on the smaller machines is a little longer, but that
is offset by that much less disk I/O. And the smaller machines are
often tight on storage.
Mike
--
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-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel
[Freedos-devel] DEVLOAD issue
I've had issues with DEVLOAD refusing to load drivers in XMS-only
situation when using DEVLOAD's /H paramater (which is try UMBs first,
just like DEVICEHIGH/INSTALLHIGH/LOADHIGH).
Through some testing this has been narrowed down as a difference between
Devload 3.20 (works) and 3.21 (fails)
Configuration:
kernel 2040 + XMGR + FreeCOM + UIDE (so XMS-only, no UMBs)
Commandline:
DEVLOAD /H UIDE.SYS /H /D:FDCD0001 /S5
3.20 visual output:
Using UMB-first allocation
Filename: A:\DOS\UIDE.SYS
{lots of UIDE output}
1 char device installed.
Driver staying resident
result:
UIDE ending up in low memory if no UMBs.
(think it actually installs 2 char devices, being FDCD0001 and UIDE$,
but oh well)
3.21 visual output:
Trying to use UMB.
Error: Can't grab memory to load driver (0001h - File read error)
result:
Loading aborted
I'm able to email a 1.44MB bootdisk image if anyone wants to verify my
test setup and results.
So should I use/supply 3.20 instead of 3.21?
Was 3.21's intention to explicit fail instead of still load, if no UMBs
or too few UMBs? It's a valid decision, just prefer to know about it.
best regards,
Bernd
--
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-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] Updated INSTALL program
Hi all, I've tagged version 4.01 of the FreeDOS Install program. This is a completely new Install program, designed as a major improvement for the FreeDOS 1.1 distribution. The new Install asks the user only a few questions: if you want to install everything, and if you want to install source code. From there, the installer takes over and does everything for you. After you answer those two questions, you can walk away and let the installer do its thing. A very obvious progress bar will show you how far along you are in the install process. There are some known issues (see doc\BUGS.TXT) but this seems stable enough that it can be used as an installer for the FreeDOS 1.1-test distribution. I'd prefer to use Info-Zip's UzpMain() library, but it barfs when called from inside the Install program. Works okay if I call this same UzpMain() through an external wrapper program. I don't see what's wrong. If anyone can help me fix this bug, I'll buy you a beer. In the meantime, Install assumes an external UNZIP.EXE, and the makefiles will produce one if you do not have your own. Details and screenshots at http://www.freedos.org/jhall/install/ Download at https://sourceforge.net/projects/freedos/files/Install/ (inst401s.zip) -jh -- 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-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] DEVLOAD issue
I am doing some testing of basic stuff and would appreciate the image. You can email me or let me know where I can download from. I am playing with the test image, some rough edges but I like the isolinux menu. Jeremy -- 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-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
