Re: [Freedos-user] Re: Re: Announce: EDIT 0.7b
Hi there, Eric Auer escribió: Hi Aitor, you are a little late... Probably yes ;-) Better late than never they say. Anyway, your history of DFLAT/EDIT is very nice and clarifying. Things started in 2003: I had sent some AltGr handling patch to Joe early in 2003, but the patch turned out to work only on a few older BIOSes. So I modified my own keyboard driver to include a workaround. Later, Patric found a D-Flat version which was useable to compile EDIT, I am very curious to know, is there a website for DFLAT? Where does one get latest versions? I think it would be about time for EDIT version 0.83, to catch up with my 0.7b - actually having TWO versions of EDIT around can be a source of inspiration for both branches :-). Konkurrenz belebt das Geschaeft, as we would say. Aitor --- This SF.Net email is sponsored by: NEC IT Guy Games. Get your fingers limbered up and give it your best shot. 4 great events, 4 opportunities to win big! Highest score wins.NEC IT Guy Games. Play to win an NEC 61 plasma display. Visit http://www.necitguy.com/?r=20 ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
[Freedos-user] FreeDOS Password v0.25 - homepage changed
Hello World ;-) The FreeDOS Password seems to be bugfree now (current release is v0.25), so I moved its homepage to my 'official' website at http://the.killer.webpark.pl/en/password.htm FreeDOS Password is a program which prevent strangers to access to your PC under DOS. All logins and attempts to login are stored in a log file, passwords are hashed using the SMDB hash. It's possible to create as many users as we like, there is a restriction only for passwords and logins length - can't exceed 25 chars each (who use so long passwords??). I wrote that tool in hope that it will be usefull especially for FreeDOS users (that's why I called it FreeDOS Password). Latest version supports language files (That's not CATS/Kitten, but sort of). I wrote english, polish and french files myself, I hope peoples will write files for other languages :-P (not difficult at all, just edit the PASSWORD.EN text file, sign it and send it back to me) Regards, Mateusz Viste Fox P.S. What are the rules for an application to be listed somewhere in the Software section of FreeDOS.org? --- This SF.Net email is sponsored by: NEC IT Guy Games. Get your fingers limbered up and give it your best shot. 4 great events, 4 opportunities to win big! Highest score wins.NEC IT Guy Games. Play to win an NEC 61 plasma display. Visit http://www.necitguy.com/?r=20 ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] FreeDOS Password v0.25 - homepage changed
Fox schreef: Hello World ;-) hello Fox, nice to hear from you again. FreeDOS Password is a program which prevent strangers to access to your PC under DOS. All logins and attempts to login are stored in a log file, passwords are hashed using the SMDB hash. It's possible to create as many users as we like, there is a restriction only for passwords and logins length - can't exceed 25 chars each (who use so long passwords??). I wrote that tool in hope that it will be usefull especially for FreeDOS users (that's why I called it FreeDOS Password). Latest version supports language files (That's not CATS/Kitten, but sort of). I wrote english, polish and french files myself, I hope peoples will write files for other languages :-P (not difficult at all, just edit the PASSWORD.EN text file, sign it and send it back to me) define 'supports' please. Does your program work without *any* external language file, or are they *required* instead of only *optional* ? In what file are the users/passwords stored? not in a language file I hope, as language preferences can be changed (and thus loose your users). Layout something like this?: password.com/exe userpass.txt logfile.txt language.txt Besides NLSPATH and current directory, can you also search %PATH% ? the install.bat you wrote is quite dangerous, because it's valid only for MS-DOS 6.22 or later, with MS COMMAND.COM in use. FreeDOS uses another menu system, for example, and autoexec.bat can also be changed. One last question: do you explicitly set input to CON device? because MS allows this: rem set input/output device to NUL instead of CON, thus disable CTRL-C SHELL=C:\COMMAND.COM NUL /P @echo off password /login mouse keyb ctty con echo Now you see output again. Regards, Mateusz Viste Fox P.S. What are the rules for an application to be listed somewhere in the Software section of FreeDOS.org? Many 'free' and/or opensource software appears in the UTILITIES section. BASE usually is for programs that replace in some way the basic MS-DOS programs. Bernd --- This SF.Net email is sponsored by: NEC IT Guy Games. Get your fingers limbered up and give it your best shot. 4 great events, 4 opportunities to win big! Highest score wins.NEC IT Guy Games. Play to win an NEC 61 plasma display. Visit http://www.necitguy.com/?r=20 ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] FreeDOS Password v0.25 - homepage changed
On Monday 02 May 2005 19:55, Bernd Blaauw wrote: define 'supports' please. Does your program work without *any* external language file, or are they *required* instead of only *optional* ? Supports, mean that it can use HIS OWN language files. His own - it's simply the model (english) file translated line by line into another language. Yes, it works with *any* external language file, as far as the file has first 10 lines empty (or comments, or anything), and following 23 lines are the translation of the 23 lines from PASSWORD.EN. Translation files are NOT required. What a weird idea :) The program works like that: IF there is LANG environment variable other than 'EN' THEN IF there is NLSPATH environment variable, then search in that path the required PASSWORD.%lang% file. IF There is LANG but no translation files found in NLSPATH (or there isn't NLSPATH at all) then search in the PASSWORD's directory. IF there is in PASSWORD's directory the required file, then load it. IF above commands can't load the translation file defined by LANG, then use internal (english) messages. All that means that language files are only OPTIONAL. If there isn't any language file, or there isn't LANG - no matter, we will use english (internal) messages. In what file are the users/passwords stored? not in a language file I hope Of course, not in the language file. You have really weird ideas today, Bernd ;) Users and password's hashes are stored in the PASSWORD.DAT file in the PASSWORD's directory. Layout something like this?: password.com/exe userpass.txt logfile.txt language.txt PASSWORD.EXE (main executable) PASSWORD.DAT (passwords and hashes) PASSWORD.LOG (the LOG file, created when you run PASSWORD for the first time) PASSWORD.* (EN, PL and FR are included with the program, but others can be used too of course, if someone take care to write them - by the way, Bernd, if you have time feel free to make a dutch translation ;-) ) PASSWORD.LSM (description file) PASSWORD.PAS (source) Besides NLSPATH and current directory, can you also search %PATH% ? For what?? Of course, I *could* if I want, but I don't see any interest in that. NLSPATH should be enough, and I additionally check the PASSWORD's directory if NLSPATH fails, I think that it is even more than enough. By the way, as Eric said, CATS/Kitten looks only into NLSPATH, nowhere else :-P the install.bat you wrote is quite dangerous, because it's valid only for MS-DOS 6.22 or later, with MS COMMAND.COM in use. FreeDOS uses another menu system, for example, and autoexec.bat can also be changed. Why dangerous I know that the [common] section will not always work, but it's surely not dangerous. And for AUTOEXEC.BAT, what is the problem? It can be changed by who? When? One last question: do you explicitly set input to CON device? I think it's not needed Even if someone wants to redirect the input to anything else than CON (for example LPT or COM), he will have to enter the login and password that way. All screen writes/reads in FD Password are done by the standard input/output. What others thinks about that? Eric? Best regards, Fox --- This SF.Net email is sponsored by: NEC IT Guy Games. Get your fingers limbered up and give it your best shot. 4 great events, 4 opportunities to win big! Highest score wins.NEC IT Guy Games. Play to win an NEC 61 plasma display. Visit http://www.necitguy.com/?r=20 ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] Re: EMM386 2.0 Released
At 07:52 PM 4/29/2005 +0200, Eric Auer wrote: More problems ahead. I tested several programs with EMM386 2.0, setting X=TEST VDS. Many failed. Most of them did work, however, when I added EMM=20480 to the settings, to disable the EMS / XMS / VCPI memory pool sharing. Some programs still failed now, and only worked with the old EMM386 1.15 properly. Finally found the initialization problem that would affect many users running VCPI- or EMS-based applications. I'll post a 2.01 EMM386 fix version later today It should clear up your DOS extender problems, anyway. Except for DOS/32A having a hard limitation of 256M VCPI. That bit of stupidity on its part will take user intervention to circumvent. --- This SF.Net email is sponsored by: NEC IT Guy Games. Get your fingers limbered up and give it your best shot. 4 great events, 4 opportunities to win big! Highest score wins.NEC IT Guy Games. Play to win an NEC 61 plasma display. Visit http://www.necitguy.com/?r=20 ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] Re: EMM386 2.0 Released
Hi, I tried the EMM386 v2.0, and there is a weird behave: When I boot the PC, my apps works ok (I tested with JAZZ JackRabbit, LAME, MPXPLAY and FastTracker 2). But when I quit the app and want to launch another one from the list, the second app is freezing or crashing with some Hex on-screen. For example, I boot the PC, launch FT2 - all works great, I quit FT2 and launch JAZZ, then black screen and many hex. Then I reboot the PC, launch Jazz and it works ok! But if I quit Jazz and wants to run FT2 (or any other app I mentionned before), the same thing happen - immediate crash. Best regards, Fox --- This SF.Net email is sponsored by: NEC IT Guy Games. Get your fingers limbered up and give it your best shot. 4 great events, 4 opportunities to win big! Highest score wins.NEC IT Guy Games. Play to win an NEC 61 plasma display. Visit http://www.necitguy.com/?r=20 ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] Re: EMM386 2.0 Released
At 10:22 PM 5/2/2005 +0200, Fox wrote: Hi, I tried the EMM386 v2.0, and there is a weird behave: When I boot the PC, my apps works ok (I tested with JAZZ JackRabbit, LAME, MPXPLAY and FastTracker 2). But when I quit the app and want to launch another one from the list, the second app is freezing or crashing with some It might be fixed EMM386 2.01 since there was an obscure runtime bug which would hit a few users besides the main fix. It could appear after running things for a while, or never happen at all. Try downloading 2.01 in an hour or three. --- This SF.Net email is sponsored by: NEC IT Guy Games. Get your fingers limbered up and give it your best shot. 4 great events, 4 opportunities to win big! Highest score wins.NEC IT Guy Games. Play to win an NEC 61 plasma display. Visit http://www.necitguy.com/?r=20 ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
[Freedos-user] EMM386 2.01 Bugfix Released
Uploaded to ftp://ftp.devoresoftware.com/downloads/emm386 are the files emmx201.zip, EMM386/HIMEM mostly executable package, and emms201.zip, EMM386/HIMEM mostly source package. EMM386 Version 2.01 is a bugfix release for Version 2.0. It is required for everyone who has version 2.0, and is a recommended upgrade for earlier 1.x EMM386 versions. Approximately half of all users will experience a fatal error in version 2.0 that 2.01 fixes, and another bug fixed in 2.01 could cause a crash for any user as they run applications, although it is much less common. EMM version 2.01 also supports the CPU WRMSR instruction and DOS redirection of help screen output, as does the HIMEM included. This version should be quite a bit more stable, but the possibility of lingering or less serious bugs after the extensive 1.x - 2.0 rewrite is moderate. Please report any problems. A quick rundown of change details follows: During initialization when pool-sharing was present (no EMM= setting), EMM386 could compute an odd 16K amount of free memory, depending on total available XMS memory. The odd 16K was not properly masked to an even 32K border, leading to immediate fatal errors when an application using EMS or VCPI was used and memory allocated to the program. It was pure luck whether your machine computed an odd or even amount of 16K blocks available, so approximately 50% of all users were probably affected. Another error that could occur during runtime allocation of XMS to an EMS/VCPI memory was a 8-bit value overflow if the value was 0FDh or higher. This could happen any time a new XMS allocation was made to EMS/VCPI pool allocation blocks. I'd roughly guess 5-10% of users might encounter the problem over the lifetime of a DOS session. EMM386 and HIMEM allow DOS redirection of their command line output to a file or through MORE, etc. Whoopee. The relevant modification is in PRF.C. Alert code browsers may note the user of an extremely dumb #ifdef to change to this behavior. Borland/Turbo C doesn't like #ifdef 0 for reasons which escape me, so I just forced it to work rather than waste time fooling around guessing how the compiler's brain worked. The protected CPU instruction WRMSR is supported via EMM386 emulation in its exception handler, to match its twin instruction RDMSR. Two trivial wording changes were made to HIMEM. --- This SF.Net email is sponsored by: NEC IT Guy Games. Get your fingers limbered up and give it your best shot. 4 great events, 4 opportunities to win big! Highest score wins.NEC IT Guy Games. Play to win an NEC 61 plasma display. Visit http://www.necitguy.com/?r=20 ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] Re: EMM386 2.0 Released
Michael Devore escribió: At 07:52 PM 4/29/2005 +0200, Eric Auer wrote: More problems ahead. I tested several programs with EMM386 2.0, setting X=TEST VDS. Many failed. Most of them did work, however, when I added EMM=20480 to the settings, to disable the EMS / XMS / VCPI memory pool sharing. Some programs still failed now, and only worked with the old EMM386 1.15 properly. Finally found the initialization problem that would affect many users running VCPI- or EMS-based applications. I'll post a 2.01 EMM386 fix version later today It should clear up your DOS extender problems, anyway. Except for DOS/32A having a hard limitation of 256M VCPI. That bit of stupidity on its part will take user intervention to circumvent. Hi Michael, I like very much the report that you do at every new posting of EMM. Just one thing that perhaps it is quite worthwile, it is to mention the switch for HIMEM to be used to circumvent the problem, so that it can be easily reported by Jim in the webpage, and gets documented somewhere in other place than the message where you posted the result. Many thanks for your work, Aitor --- This SF.Net email is sponsored by: NEC IT Guy Games. Get your fingers limbered up and give it your best shot. 4 great events, 4 opportunities to win big! Highest score wins.NEC IT Guy Games. Play to win an NEC 61 plasma display. Visit http://www.necitguy.com/?r=20 ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
[Freedos-user] Re: EMM386 2.01 Bugfix Released
Hi Michael, big cheers for those bugfixes! Things work a lot better now :-)). Still not perfect, though... All my testings below were done without /max=... in HIMEM, so roughly 192 - (56+1) = 135 MB of XMS were free when I reached the prompt, less if EMM386 loaded but pool sharing disabled, of course. 1. EMM386 X=TEST VDS EMM=32640 gcube, mft, zip, jazz jackrabbit, raptor, ctstoast, lemmings 3d demo all work. In other words: PMODE/W, general EMS stress test (bench), CWSDPMI, RTM/DPMI16BI, DOS/16M, DOS32A, DOS/4GW are all happy. Did not test Descent (dos4gw/dos32a) and AuGoS (rtm) explicitly now. Remaining PROBLEM: Lemmings 3d hangs right before returning to DOS. 2. EMM386 X=TEST VDS Still everything as above :-). Pool sharing now on, though. I got an unreproduceable not enough XMIN from Raptor which went away when I did rap /? to figure out how to avoid it, even though /? officially has no effect in Raptor. The L3d hang was still there. Notice: DOS32A uses 50 MB, DOS4GW uses 32276 kB in Descent -verbose. 3. No EMM386 at all The RTM / DPMI16BI programs RTM and AuGoS spontaneously reboot at init. As checked earlier, it only seems to help to use HIMEM /max=? with ? being something like 31744, something about 32 MB addres space. Different to Aladdin, /X2MAX32 alone does not seem to help... Lemmings 3d does not work without EMS, by the way. Apart from the RTM problem, I notice a typical DOS4GW crash (which I remember to have happened long ago, maybe DOS4GW gets confused above 64 MB of XMS free when no VCPI is present)... Loading with DOS32A is okay (168 MB RAM used and still okay, when testing with less RAMDISK size...! I mean 168 MB used by DOS32A.). The DOS4GW crash log tells: GPF at 3e58:24d7 (typical offset), esi=5b30 (1 above ES limit), edi=56cc, eax=ecx=c000, ebx=edx=16c, es=198 etc. etc. Apart from the above test results, there are documentation issues: todo.txt emm386.txt and emm386.lsm are all outdated, some even telling (still) that there is no VCPI yet and a 64 MB limit and that FDXMS would be unsupported because it would have a bug, and so on... :-P :-). Eric --- This SF.Net email is sponsored by: NEC IT Guy Games. Get your fingers limbered up and give it your best shot. 4 great events, 4 opportunities to win big! Highest score wins.NEC IT Guy Games. Play to win an NEC 61 plasma display. Visit http://www.necitguy.com/?r=20 ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] Re: EMM386 2.0 Released
At 01:59 AM 5/2/2005 +0200, Aitor Santamaría Merino wrote: Michael Devore escribió: It should clear up your DOS extender problems, anyway. Except for DOS/32A having a hard limitation of 256M VCPI. That bit of stupidity on its part will take user intervention to circumvent. Hi Michael, I like very much the report that you do at every new posting of EMM. Just one thing that perhaps it is quite worthwile, it is to mention the switch for HIMEM to be used to circumvent the problem, so that it can be easily reported by Jim in the webpage, and gets documented somewhere in other place than the message where you posted the result. The /MAX=256M option? Actually, I wouldn't be so mad about the DOS/32A problem, except 1. It leaves allocated all the memory it allocated up to the fail point. I mean, the developers are able to make it work well enough to give a gee, we're sorry error message and terminate, but they don't have it clean up afterwards. Completely avoidable situation with basic programming skillz d00ds. No way to free back the allocated memory either, unless one is handy with assembly language and a debugger. The only good thing is that since the first fail eats up a ton of memory, you can usually run the bound application again and it works, because DOS/32A chewed up so much memory the first time it failed. Probably take several times through if you have a 2G machine, though. 2. It is so heavily touted on the mail list and Bugzilla as THE solution to DOS extender problems. Maybe that will die down a bit now. Of course, maybe they have fixed DOS/32A. Releases are stopped dead on SourceForge for last couple of years, but I could be using an older bound-in version for the failing MPXPLAY than last release. Or there's a chance of a bug left in EMM386. Doesn't act like it though, and since they didn't clean up after themselves, either way I won't say I'm sorry for calling its behavior stupid. DOS/32A supporters can research if there is a workaround or fix. I think after all the recommendations given for it, the cheerleader(s) might feel responsible to see why it fails. --- This SF.Net email is sponsored by: NEC IT Guy Games. Get your fingers limbered up and give it your best shot. 4 great events, 4 opportunities to win big! Highest score wins.NEC IT Guy Games. Play to win an NEC 61 plasma display. Visit http://www.necitguy.com/?r ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
