From: Don P. <do...@ma...> - 2000-09-22 07:40:19
|
I have been using mingw on W2K for a while now and it seems fine. -----Original Message----- From: min...@li... [mailto:min...@li...]On Behalf Of Tim Reed Sent: Thursday, September 21, 2000 9:11 PM To: min...@li... Subject: [Mingw-users] Win2k I was wonder if there are any known problems related to mingw32 on Windows 2000? _______________________________________________ MinGW-users mailing list Min...@li... You may change your MinGW Account Options at: http://lists.sourceforge.net/mailman/listinfo/mingw-users |
From: Earnie B. <ear...@ya...> - 2000-09-22 12:22:55
|
--- Tim Reed <ti...@vi...> wrote: > > I was wonder if there are any known problems related to mingw32 on Windows > 2000? > I know of none. Cheers, ===== --- <http://earniesystems.safeshopper.com> --- Earnie Boyd: <mailto:ear...@ya...> __Cygwin: POSIX on Windows__ Cygwin Newbies: <http://gw32.freeyellow.com/> __Minimalist GNU for Windows__ Mingw Home: <http://www.mingw.org/> __________________________________________________ Do You Yahoo!? Send instant messages & get email alerts with Yahoo! Messenger. http://im.yahoo.com/ |
From: Juan C. A. B. <jc...@ro...> - 2000-09-22 17:08:20
|
At 05:22 AM 9/22/2000 -0700, you wrote: > > I was wonder if there are any known problems related to mingw32 on Windows > > 2000? > >I know of none. The zsh (and some of the other tools too) that you can find at: http://www.weihenstephan.de/~syring/win32/UnxUtils.html crash very miserably under Win2K. Don't know the reason. I double-checked with Joerg, who is using the zsh, and it doesn't happen to him on NT. Salutaciones, JCAB --------------------------------------------------------------------- Juan Carlos "JCAB" Arevalo Baeza | http://www.roningames.com Senior Technology programmer | mailto:jc...@ro... Ronin Entertainment | ICQ: 10913692 (my opinions are only mine) JCAB's Rumblings: http://www.metro.net/jcab/Rumblings/html/index.html |
From: Franco B. <fra...@gm...> - 2000-09-22 20:01:32
|
Am Fre, 22 Sep 2000 schrieb Juan Carlos Arevalo Baeza: > The zsh (and some of the other tools too) that you can find at: > >http://www.weihenstephan.de/~syring/win32/UnxUtils.html > > crash very miserably under Win2K. Don't know the reason. > > I double-checked with Joerg, who is using the zsh, and it doesn't >happen to him on NT. > > > Salutaciones, Check the setting of the Command Prompt (Dos-BOX) in the Control Panel. In NT the visible Window-size is equal to the Window-buffer size (by default), in Win2k the Buffer-size if a lot larger. This crashed the Win32 port of GNU Midnight Commander on Win2k. I fixed the problem by adjusting mc to use the real Window-size, and not the buffer-size (in mc's source). This might affect all console (Dos-Box) programs that use the curses or slang library. Ciao, Franco |
From: <fra...@gm...> - 2000-09-25 06:15:26
|
Regarding the Win2k console settings: It seems that M$ forgot to put the Console settings in the Control Panel on Win2k. But if you open a Console and choose "Properties" from the System Menu You get the Dialog I mean. On the Third Tab (Layout) You'll find the settings for "Windowbuffersize" and "Windowsize". On WinNT both default to 80x25, on Win2k the Buffer is 80x300 and the Window is 80x25. This huge Buffersize crashed previous Versions of MC for Win32, it might affect other Programs too. Ciao, Franco -- Sent through GMX FreeMail - http://www.gmx.net |
From: Franco B. <fra...@gm...> - 2000-09-25 19:37:44
|
>I run the "zsh" using a shortcut from the desktop, and this includes >the property settings "window size: 80 (columns) x 50 (lines)" >and "buffer size: 80 x 100" (the vertical scrollbar at the right). > >So all I can say is that the "zsh" can deal with a buffer that has >more lines than the window, and that it is not limited to the standard >25 lines. So the problem is not the difference between Buffer and Window Size, but the Size itself. With 100 lines it works. But with 300 lines it might fail. It seems to me like a trivial OVERFLOW problem. The libs (ncurses, slang) probably use only nibbles (4 Bit = 128) or bytes (8 Bit = 256) to store screen coordinates in text mode. That means any resolution (true, or only buffer) that exeeds 128x128 (or 256x256 resp.) might fail with programs that modify the screen buffer directly. Ciao, Franco |
From: Earnie B. <ear...@ya...> - 2000-09-26 11:45:06
|
--- Franco Bez <fra...@gm...> wrote: > >I run the "zsh" using a shortcut from the desktop, and this includes > >the property settings "window size: 80 (columns) x 50 (lines)" > >and "buffer size: 80 x 100" (the vertical scrollbar at the right). > > > >So all I can say is that the "zsh" can deal with a buffer that has > >more lines than the window, and that it is not limited to the standard > >25 lines. > > So the problem is not the difference between Buffer and Window Size, but the > Size itself. > > With 100 lines it works. But with 300 lines it might fail. > > It seems to me like a trivial OVERFLOW problem. > The libs (ncurses, slang) probably use only nibbles (4 Bit = 128) > or bytes (8 Bit = 256) to store screen coordinates in text mode. > > That means any resolution (true, or only buffer) that exeeds 128x128 (or > 256x256 resp.) might fail with programs that modify the screen buffer > directly. > This might be a W2K thing. I have 80 columns by 2500 rows of buffer. I'm using NT4sp4. Cheers, ===== --- <http://earniesystems.safeshopper.com> --- Earnie Boyd: <mailto:ear...@ya...> __Cygwin: POSIX on Windows__ Cygwin Newbies: <http://gw32.freeyellow.com/> __Minimalist GNU for Windows__ Mingw Home: <http://www.mingw.org/> __________________________________________________ Do You Yahoo!? Send instant messages & get email alerts with Yahoo! Messenger. http://im.yahoo.com/ |
From: <fra...@gm...> - 2000-09-26 12:09:36
|
>This might be a W2K thing. I have 80 columns by 2500 rows of buffer. I'm >using NT4sp4. I experienced no difference so far. When I set the buffer to large Values on NT - MC crashed. The difference was only the default Value. Again, this can only affect Programs that directly change the position the Cursor throu libs like ncurses or slang. Filter programs (reading from stdin writing to stdout/stderr) should not be affected at all. Ciao, Franco -- Sent through GMX FreeMail - http://www.gmx.net |
From: Juan C. A. B. <jc...@ro...> - 2000-09-26 17:18:03
|
At 09:37 PM 9/25/2000 +0200, you wrote: > >I run the "zsh" using a shortcut from the desktop, and this includes > >So the problem is not the difference between Buffer and Window Size, but the >Size itself. > >With 100 lines it works. But with 300 lines it might fail. It doesn't work here (Win2K) with 50 lines for both, window and buffer. >It seems to me like a trivial OVERFLOW problem. Looks like. The first sign is random garbage in the line where the cursor is, running it interactive. Salutaciones, JCAB --------------------------------------------------------------------- Juan Carlos "JCAB" Arevalo Baeza | http://www.roningames.com Senior Technology programmer | mailto:jc...@ro... Ronin Entertainment | ICQ: 10913692 (my opinions are only mine) JCAB's Rumblings: http://www.metro.net/jcab/Rumblings/html/index.html |
From: Franco B. <fra...@gm...> - 2000-09-27 02:24:45
|
Am Die, 26 Sep 2000 schrieb Juan Carlos Arevalo Baeza: > Looks like. The first sign is random garbage in the line where the >cursor is, running it interactive. Now, that's a different story. Those garbage characters in zsh (Amol's? I don't remember) - I had them too. The crazy thing is - one one Machine it runs perfect - on the other there are those garbage chars on the screen. Both machines are equipped with NT4SP6. I didn't find out why. But the zsh works OK on both machines - it doesn't crash - scripts work as intended. The screen buffer overflow should affect mainly programs that use the entire console screen for input/output. (Like the Midnight Commander, maybe editors like emacs, vi or even the lynx web browser) > Salutaciones, > JCAB Ciao, Franco |
From: Paul G. <pga...@te...> - 2000-09-26 23:36:59
|
Hi folks, On 26 Sep 2000, at 4:45, the Illustrious Earnie Boyd wrote: > --- Franco Bez <fra...@gm...> wrote: > > >I run the "zsh" using a shortcut from the desktop, and this > > >includes the property settings "window size: 80 (columns) x 50 > > >(lines)" and "buffer size: 80 x 100" (the vertical scrollbar > > >at the right). > > > > > >So all I can say is that the "zsh" can deal with a buffer that > > >has more lines than the window, and that it is not limited to > > >the standard 25 lines. > > > > So the problem is not the difference between Buffer and Window > > Size, but the Size itself. > > > > With 100 lines it works. But with 300 lines it might fail. > > > > It seems to me like a trivial OVERFLOW problem. > > The libs (ncurses, slang) probably use only nibbles (4 Bit = > > 128) or bytes (8 Bit = 256) to store screen coordinates in text > > mode. > > > > That means any resolution (true, or only buffer) that exeeds > > 128x128 (or 256x256 resp.) might fail with programs that modify > > the screen buffer directly. > > > > This might be a W2K thing. I have 80 columns by 2500 rows of > buffer. I'm using NT4sp4. Let me encourage anyone that is using NT4 to update to the very latest SP (6a at this point...probably the last one that will ever be released given MS discontinuing cert support for NT4). Peace, Paul G. Nothing real can be threatened. Nothing unreal exists. |
From: Franco B. <fra...@gm...> - 2000-09-27 02:39:22
|
Am Mit, 27 Sep 2000 schrieb Paul Garceau: > Let me encourage anyone that is using NT4 to update to the very >latest SP (6a at this point...probably the last one that will >ever be released given MS discontinuing cert support for NT4). I recently had to reinstall two machines with NT4SP5, because the SP6a that worked really fine on all other machines in our company really did f... up those machines. Not a single CD-ROM based Setup program worked with SP6, but when reinstalled SP5 all went fine. There were also some less critical problems with SP6 on those machines. I still didn't find the exact reason, but here's my honest warning: DO NOT USE SP6, unless You are having problems with SP5. > Peace, > > Paul G. Ciao, Franco |
From: Paul G. <pga...@te...> - 2000-09-27 20:56:07
|
Hi folks, On 27 Sep 2000, at 4:40, the Illustrious Franco Bez wrote: > Am Mit, 27 Sep 2000 schrieb Paul Garceau: > > > Let me encourage anyone that is using NT4 to update to the very > > latest SP (6a at this point...probably the last one that will > >ever be released given MS discontinuing cert support for NT4). > > I recently had to reinstall two machines with NT4SP5, because the > SP6a that worked really fine on all other machines in our company > really did f... up those machines. > > Not a single CD-ROM based Setup program worked with SP6, but when > reinstalled SP5 all went fine. Hmm...doesn't make any sense. (Warning, jab at MS coming up: doesn't surprise me -- why fully test all installations when they can get much more money answering support phone calls...?) Now, back to the topic at hand; are you talking about cd-rom setup for SP6 or cd-rom setups for everything else (ie. not SP cd-rom setups)? (Incidentally, there is an assumed obligation here that MS is responsible for their screw-ups.) I guess I need to add, I did not pay to have any SP (1-6a) cd- roms shipped. (I won't spend my $$ on anything MS related if I can, within reason, avoid it.) I need to also add that in every SP update case (from sp1- >sp6a) I downloaded the files from the MS webpages. Sure, it took a little while to download the standard workstation updates, but they all ran and installed just fine. > > There were also some less critical problems with SP6 on those > machines. > > I still didn't find the exact reason, but here's my honest > warning: > > DO NOT USE SP6, unless You are having problems with SP5. Anyone know when Dx3 was finally fully integrated into NT4? I had thought it was SP6. Peace, Paul G. Nothing real can be threatened. Nothing unreal exists. |
From: Franco B. <fra...@gm...> - 2000-09-29 18:53:57
|
Am Mit, 27 Sep 2000 schrieb Paul Garceau: >Hi folks, >On 27 Sep 2000, at 4:40, the Illustrious Franco Bez wrote: >> I recently had to reinstall two machines with NT4SP5, because the >> SP6a that worked really fine on all other machines in our company >> really did f... up those machines. >> >> Not a single CD-ROM based Setup program worked with SP6, but when >> reinstalled SP5 all went fine. > > Hmm...doesn't make any sense. No, doesn't make sense at all. But that's why it took me so long to find out. A customer of a friend of mine had the same problems, too. So he gave me the hint. >(Warning, jab at MS coming up: >doesn't surprise me -- why fully test all installations when >they can get much more money answering support phone calls...?) Or sell Upgrades to Win2k ? > Now, back to the topic at hand; are you talking about cd-rom >setup for SP6 or cd-rom setups for everything else (ie. not SP >cd-rom setups)? (Incidentally, there is an assumed obligation >here that MS is responsible for their screw-ups.) Nearly all Setups of any Program started from CD-ROM failed with stupid messages like "Corrupted cab file" or "insufficient memory". Also strange, if I put the CD in another PC and networked the drive - the setup program ran without difficulties. So you might think the CD-Rom-Drive is bad, but now that SP6a is gone it works perfectly again. > > I guess I need to add, I did not pay to have any SP (1-6a) cd- >roms shipped. (I won't spend my $$ on anything MS related if I >can, within reason, avoid it.) > > I need to also add that in every SP update case (from sp1- >>sp6a) I downloaded the files from the MS webpages. Sure, it >took a little while to download the standard workstation >updates, but they all ran and installed just fine. I also downloaded the SPs, I have no SpP CD-Roms neither. Also most of our machines (we have some 100) run perfectly with SP6a installed. Must be some stupid bug that found it's way in one of the system files that SP6a replaces. A bug that only occurs on certain Hardware (maybe non Intel chipsets?). > Anyone know when Dx3 was finally fully integrated into NT4? I >had thought it was SP6. Sorry, No Idea. > Peace, > > Paul G. Ciao, Franco |
From: Paul G. <pga...@te...> - 2000-09-29 22:02:29
|
Hi folks, On 29 Sep 2000, at 20:43, the Illustrious Franco Bez wrote: > Am Mit, 27 Sep 2000 schrieb Paul Garceau: > >Hi folks, > >On 27 Sep 2000, at 4:40, the Illustrious Franco Bez wrote: > >> I recently had to reinstall two machines with NT4SP5, because > >> the SP6a that worked really fine on all other machines in our > >> company really did f... up those machines. > >> > >> Not a single CD-ROM based Setup program worked with SP6, but > >> when reinstalled SP5 all went fine. > > > > Hmm...doesn't make any sense. > > No, doesn't make sense at all. But that's why it took me so long > to find out. A customer of a friend of mine had the same > problems, too. So he gave me the hint. > > >(Warning, jab at MS coming up: > >doesn't surprise me -- why fully test all installations when > >they can get much more money answering support phone calls...?) > > > > Or sell Upgrades to Win2k ? I think we understand each other here...;-) > > > > Now, back to the topic at hand; are you talking about cd-rom > >setup for SP6 or cd-rom setups for everything else (ie. not SP > >cd-rom setups)? (Incidentally, there is an assumed obligation > >here that MS is responsible for their screw-ups.) > > Nearly all Setups of any Program started from CD-ROM failed with > stupid messages like "Corrupted cab file" or "insufficient > memory". Also strange, if I put the CD in another PC and > networked the drive - the setup program ran without difficulties. > So you might think the CD-Rom-Drive is bad, but now that SP6a is > gone it works perfectly again. This is beginning to sound more and more like an MS screwup... > > > > > I guess I need to add, I did not pay to have any SP (1-6a) cd- > >roms shipped. (I won't spend my $$ on anything MS related if I > >can, within reason, avoid it.) > > > > I need to also add that in every SP update case (from sp1- > >>sp6a) I downloaded the files from the MS webpages. Sure, it > >took a little while to download the standard workstation > >updates, but they all ran and installed just fine. > > I also downloaded the SPs, I have no SpP CD-Roms neither. > Also most of our machines (we have some 100) run perfectly with > SP6a installed. Must be some stupid bug that found it's way in > one of the system files that SP6a replaces. A bug that only > occurs on certain Hardware (maybe non Intel chipsets?). I think we are getting close here. It wouldn't be the first time that MS hasn't supported or desired to support a particluar system configuration...as I recall they discontinued support for a particular OS some years ago...no warning...just stopped providing such things which left those people with NT4 for that particular OS on their own...Of course, they (MS) were very quick to supply a new SP for Intel based PCs and the one system configuration they chose to continue to support outside of the Intel based systems. Anyway..back to the topic at hand... It sounds like the SP installation was flawed in the cases you are talking about. Not your fault, but the fault of MS. Hardware requirements changed somewhat with the advent of SP6, as did IIS support. SP6a was nothing more than a "fix" for SP6, primarily released because some Fortune 500 companies were pi*sed off that MS had screwed them by not supporting certain system configurations with the SP6 release (did someone say "lawsuit"?). Bottom line, add SPs only if you absolutely have to. Sometimes "things" will suddenly appear (GPFs crawling across your desktop, etc.) if you don't have the very latest SP release. I've seen this happen just prior to new SP updates on a number of ocassions. It is this reason that I asked if anyone knew "when" Dx3 was finally fully-integrated on NT4 (I think it was SP5). This means that if you want to do Dx stuff on NT4 using Mingw, you will need at least SP5. I am currently running SP6a. Peace, Paul G. Nothing real can be threatened. Nothing unreal exists. |
From: Paul G. <pga...@te...> - 2000-09-26 23:53:18
|
On 25 Sep 2000, at 21:37, the Illustrious Franco Bez wrote: > >I run the "zsh" using a shortcut from the desktop, and this > >includes the property settings "window size: 80 (columns) x 50 > >(lines)" and "buffer size: 80 x 100" (the vertical scrollbar at > >the right). > > > >So all I can say is that the "zsh" can deal with a buffer that > >has more lines than the window, and that it is not limited to > >the standard 25 lines. > > So the problem is not the difference between Buffer and Window > Size, but the Size itself. > > With 100 lines it works. But with 300 lines it might fail. This is mostly a suggestion, so feel free to ignore if you take a notion to... For NT4, I am running 400 lines w/o problems. If any further problems exist within the window implementation under Win2k, it most likely has to do with the way that MS enabled downward compatibility with Win9x or other legacy Operating Systems. In other words, the new MS-DOS window may be nothing more than a Win9x bolt-on and far less effective and flexible then NT4 cmd.exe shell. Try applying Win9x requirements/limitations for Win2k MS-DOS Window and see what happens... One final suggestion, if Win2k has a -x switch (as in "cmd.exe -x", try using that in your system autoexec file*). Peace, Paul G. *NT4 has autoexec.nt found in Winnt\system32. NT4 invokes this file when it starts up. Primarily this file is, afaik, defined for only a sinlge purpose: to configure MS-DOS command- prompt/virtual-dos-shell for NT4. Nothing real can be threatened. Nothing unreal exists. |