Re: [Freedos-user] (no subject)
On Sun, Jun 17, 2012 at 9:21 PM, Marcos Favero Florence de Barros fav...@mpcnet.com.br wrote: Aha! So that's why one of my favorite text editors won't run in some machines; it' the same error message, and it uses the Borland interface too. Which editor? An assortment use the Borland interface. Some are based on the old Borland Editor Toolkit, but I believe there are a few more modern variants in Pascal that don't. Marcos Fávero Florence de Barros Campinas, Brazil __ Dennis https://plus.google.com/u/0/105128793974319004519 -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
[Freedos-user] TurboPascal Runtime Error 200
Aha! So that's why one of my favorite text editors won't run in some machines; it' the same error message, and it uses the Borland interface too. Which editor? An assortment use the Borland interface. Some are based on the old Borland Editor Toolkit, but I believe there are a few more modern variants in Pascal that don't. It's a shareware from 1995 called Vision Edit, by PrimaSoft. It's not sophisticated like Aurora, but it's practical and I like it. I fixed the problem yesterday: in the batch file that runs it, I added a line FDAPM speed3 to drop processor speed below 200 MHz, and then FDAPM speed8 in the end to return to normal speed. This is the *third* thing I do in order to continue using this particular program. The other two are: loading Japheth's HDPMI16.EXE because apparently the original DPMI won't work under FreeDOS, and loading DPAKBD to make it FDAPM-aware. Marcos -- Marcos Fávero Florence de Barros Campinas, Brazil -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] Networking
Tom Ehlert t...@drivesnapshot.de wrote: try using MSDOS or linux (or even Windows) for the 'server' machine, and see if the problema go away I did the test with MS-DOS in the server and FreeDOS in the client. The problem vanished. I even used MODE con rate=32 which is the fastest typematic rate, and kept the arrow keys and PgUp/PgDn pressed in both computers for about a minute. The system is completely stable. then the problem is not related to SHARE, but most likely a kernel problem. SHARE is responsible to resolve conflicts around multiple *write* requests to the same file. just scrolling through a database should work with or without locking. but: in this case the remote machine and the local one (the 'server') ascess the file at the same time, with a decent probability that the server machine is inside DOS, when the read request from the remote machine arrives. if this is not handled properly, you get a lot of interesting (seemingly random) error messages as reported in you initial post From the server: - General failure reading drive C - Disk is write protected From the client: - Not ready reading drive G - (This one is from DataPerfect, in a rare instance when the client did not crash along with the server:) Network error. One or more of the database files can't be accessed because of the current authorization for the files [..] this is the black art of reliable disk access from a TSR (MSCLIENT), along InDOS flag, SDA, possibly some internal calls, ... most likely FreeDOS Kernel behaves just a tiny bit different from MSDOS, and 'multitasking' on top of FreeDOS goes wrong. btw: this could also affect different network stacks, because the problem would be similar. conclusion: don't use FreeDOS as a 'server' machine. Tom -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] Networking
Pentium definitely came in a 233MHz version, but I thought the 300MHz version was Pentium II only. -Original Message- From: Rugxulo [mailto:rugx...@gmail.com] Sent: Monday, June 18, 2012 12:10 AM To: freedos-user@lists.sourceforge.net Subject: Re: [Freedos-user] Networking Hi, On Jun 17, 2012 6:32 PM, Ulrich Hansen uhan...@mainz-online.de wrote: Ah, and NEOS: I didn't have time to really create a NEOS network here. I will look into it some other time. But at least the readme sounds good at first glance. The NEOS installer works on my old laptops (486SX33) but it doesn't in VirtualBox. In VirtualBox I get the TurboPascal Runtime Error 200 which seems to mean that the program won't work on computers with a clock speed faster than 200 MHz. So how old are your Pentiums? You can patch those problematic programs or run a TSR. ftp://ftp.sac.sk/pub/sac/utilprog/r200fix.zip BTW, I had vaguely thought the highest Pentium was 200 or 233 Mhz, but Wikipedia says 300 Mhz, but I think they were more common in lower speeds. -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] Networking
The highest clock rates that were sold were 200MHz for Pentium, 233MHz for Pentium MMX, and 300MHz for Mobile Pentium MMX. The late mobile chips were made with a finer process (250nm IIRC). On Mon, 18 Jun 2012 11:25:01 -0400, David C. Kerber dker...@warrenrogersassociates.com wrote: Pentium definitely came in a 233MHz version, but I thought the 300MHz version was Pentium II only. -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] FreeDOS 1.1: JemmEx conflicts with Keyb
Hi, old thread ;) There were in the past conflicts with KEYB 2.00 and JEMM that were apparently solved with KEYB 2.01. The NOHI option mostly controlls KEYB access to XMS, but reading this thread, and knowing what I fixed 2.00 to 2.01, I suspect JEMM may make the DOS' memory allocation strategy functions less robust than they are with other DOSes. In case it helps JEMM... Aitor El viernes, 13 de enero de 2012, Ulrich Hansen uhan...@mainz-online.de escribió: Am 13.01.2012 um 18:54 schrieb Bernd Blaauw: Op 13-1-2012 16:11, Ulrich Hansen schreef: Description: I have installed FreeDOS 1.1 with german language and keyboard. If I boot (after a fresh install) with bootmenu option 1 (Load FreeDOS with JemmEx) keyb will crash with the error message: Keyboard layout : C:\FDOS\bin\keyboard.sys:GR [858](3) Critical error: cannot allocate memory. DOS reported error: 8 could you try adding /NOHI at your KEYB line please? Wow. This worked! In AUTOEXEC.BAT I have now a line: KEYB GR,,keyboard.sys /NOHI In FDCONFIG.SYS I went back to all the original settings of FreeDOS 1.1. So the JemmEx line looks like this again: 1?DEVICE=C:\FDOS\BIN\JEMMEX.EXE NOEMS X=TEST I=TEST NOVME NOINVLPG X=TEST is just a test for checking which UMB areas are (un)safe to use. Could you perhaps try adding X=TEST to option 2 (EMM386) ? See if that works. I've not been able to reproduce your case in VMWARE Workstation 8. X=TEST is originally in option 2. The lines in FDCONFIG.SYS (untouched after installation) look like this: 2?DEVICE=C:\FDOS\BIN\HIMEMX.EXE 2?DEVICE=C:\FDOS\BIN\JEMM386.EXE X=TEST I=TEST I=B000-B7FF NOVME NOINVLPG So this is OK. I don't really understand why leaving out X=TEST in option 1 solved the problem too. Testing the UMBs should lead to a more stable behavior of JEMMEX.EXE. Instead it crashed KEYB somehow. It's odd but it's easy to reproduce with any fresh FreeDOS installation on VirtualBox with the default settings (and choosing german keyboard layout). Anyway, starting KEYB with /NOHI seems to be the more elegant and logical solution. Thanks! If this could be the default in FreeDOS, I think it would help other users. At least the german ones... ;-) regards Ulrich -- RSA(R) Conference 2012 Mar 27 - Feb 2 Save $400 by Jan. 27 Register now! http://p.sf.net/sfu/rsa-sfdev2dev2 ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] FreeDOS 1.1: JemmEx conflicts with Keyb
Am 18.06.2012 um 22:15 schrieb Aitor Santamaría: There were in the past conflicts with KEYB 2.00 and JEMM that were apparently solved with KEYB 2.01. The NOHI option mostly controlls KEYB access to XMS, but reading this thread, and knowing what I fixed 2.00 to 2.01, I suspect JEMM may make the DOS' memory allocation strategy functions less robust than they are with other DOSes. In case it helps JEMM... Thanks for looking into this. There is also a page in the FreeDOS wiki about the problem: http://sourceforge.net/apps/mediawiki/freedos/index.php?title=VirtualBox_-_Chapter_9 As I wrote, KEYB v2.01 and JEMMEX v5.75 are installed in a way in FreeDOS 1.1 that leads to KEYB crashing at boot - if you choose option 1 from the boot menu and - manually changed AUTOEXEC.BAT to install a keyboard layout. Generally spoken this means people with a different keyboard than the US have a problem. AFAIK there are two ways to work around this as user: 1. Solution: Change the following line in FDCONFIG.SYS 1?DEVICE=C:\FDOS\BIN\JEMMEX.EXE NOEMS X=TEST I=TEST NOVME NOINVLPG to read 1?DEVICE=C:\FDOS\BIN\JEMMEX.EXE NOEMS I=TEST NOVME NOINVLPG (remove X=TEST) Or 2. Solution: Change the following line in AUTOEXEC.BAT (if you install f.i. the german keyboard layout) KEYB GR,,keyboard.sys to read KEYB GR,,keyboard.sys /NOHI Effects on free memory: 1st solution: 598,736 total 594,656 conv 4,080 upper 2nd solution: 590,560 total 590,208 conv 352 upper So the first solution gives me more free memory while the second solution may result in a more robust system (more tested and excluded upper memory blocks). Of course from a user's perspective it would be best if either KEYB or JEMMEX could be fixed. According to your remarks it should be JEMMEX. I just tested the new JEMMEX v5.76 but there was no difference. regards Ulrich El viernes, 13 de enero de 2012, Ulrich Hansen uhan...@mainz-online.de escribió: Am 13.01.2012 um 18:54 schrieb Bernd Blaauw: Op 13-1-2012 16:11, Ulrich Hansen schreef: Description: I have installed FreeDOS 1.1 with german language and keyboard. If I boot (after a fresh install) with bootmenu option 1 (Load FreeDOS with JemmEx) keyb will crash with the error message: Keyboard layout : C:\FDOS\bin\keyboard.sys:GR [858](3) Critical error: cannot allocate memory. DOS reported error: 8 could you try adding /NOHI at your KEYB line please? Wow. This worked! In AUTOEXEC.BAT I have now a line: KEYB GR,,keyboard.sys /NOHI In FDCONFIG.SYS I went back to all the original settings of FreeDOS 1.1. So the JemmEx line looks like this again: 1?DEVICE=C:\FDOS\BIN\JEMMEX.EXE NOEMS X=TEST I=TEST NOVME NOINVLPG X=TEST is just a test for checking which UMB areas are (un)safe to use. Could you perhaps try adding X=TEST to option 2 (EMM386) ? See if that works. I've not been able to reproduce your case in VMWARE Workstation 8. X=TEST is originally in option 2. The lines in FDCONFIG.SYS (untouched after installation) look like this: 2?DEVICE=C:\FDOS\BIN\HIMEMX.EXE 2?DEVICE=C:\FDOS\BIN\JEMM386.EXE X=TEST I=TEST I=B000-B7FF NOVME NOINVLPG So this is OK. I don't really understand why leaving out X=TEST in option 1 solved the problem too. Testing the UMBs should lead to a more stable behavior of JEMMEX.EXE. Instead it crashed KEYB somehow. It's odd but it's easy to reproduce with any fresh FreeDOS installation on VirtualBox with the default settings (and choosing german keyboard layout). Anyway, starting KEYB with /NOHI seems to be the more elegant and logical solution. Thanks! If this could be the default in FreeDOS, I think it would help other users. At least the german ones... ;-) regards Ulrich -- RSA(R) Conference 2012 Mar 27 - Feb 2 Save $400 by Jan. 27 Register now! http://p.sf.net/sfu/rsa-sfdev2dev2 ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT
