RE: End of support for 9x
It is a pity; I have applications utilizing cygwin on Windows 93 and 95. This is not a situation where I 'insist on using unsupported software', but where a vendor has written applications I must interface with that were written for those platforms and they will not upgrade, for reasons of their own. I hope there will be some spot out there that will keep the last compatible versions available. Terry Dabbs -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Trans-Mit Support Sent: Monday, August 25, 2008 2:42 AM To: cygwin@cygwin.com Subject: Fw: End of support for 9x Haven't had many bad experiences with Win98, and now being serious, I do use XP and cygwin, but still prefer Win98 performance cf. XP on same H/W Its just a pitty I won't be able to keep the CYGWIN up to date on my WIN98 Its bad enough having to use windows, but having to upgrade to XP or VISTA is just out of the question. I'm not surprised that you're having bad experiences with Windows if you insist on using obsolete, unsupported software that wasn't designed for modern hardware. I expect I'd have a lot of problems too if I reinstalled Version 4 of Suse which I first bought over a decade ago. The jury's still out when it comes to Vista - but for XP, many users have found it to be a highly stable OS. Personally, I find XP to be more stable than 64Studio which is easily the most stable of the (ten) Linux distros that I've tried. And Win2K is also excellent, as Derek suggested. Admittedly, XP's Fisher Price look is offputting but you don't need to use it. I prefer the 'classic' look which I've used ever since XP first came out. I've never once had any incompatibility problem with it. Give it a try - you might be pleasantly surprised. John - Original Message - From: Trans-Mit Support [EMAIL PROTECTED] To: cygwin@cygwin.com Sent: 25 August 2008 06:10 Subject: End of support for 9x Re:- Note that the official support for Windows 95, Windows 98, and Windows Me will be discontinued with the next major version (1.7.0) of Cygwin. Its bad enough having to use windows, but having to upgrade to XP or VISTA is just out of the question. Looks like I won't be using any new versions of cygwyn -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/ -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/ -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
RE: End of support for 9x
That should do it. Thanks... Terry -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Corinna Vinschen Sent: Monday, August 25, 2008 8:56 AM To: cygwin@cygwin.com Subject: Re: End of support for 9x On Aug 25 08:34, Terry Dabbs wrote: It is a pity; I have applications utilizing cygwin on Windows 93 and 95. This is not a situation where I 'insist on using unsupported software', but where a vendor has written applications I must interface with that were written for those platforms and they will not upgrade, for reasons of their own. I hope there will be some spot out there that will keep the last compatible versions available. It's fixed decided that we keep the entire 1.5.25 based net distro around for those user who are still running Cygwin on Windows 9x or users having very specific needs. However, there will probably be no new packages for the 1.5.25 based distro anymore. No package maintainer will be forced to support two separate distros. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/ -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
RE: Making the command console stay on top
I would like to thank you for your suggestions. Just to clarify: I have checked out a number of the simple solutions: WindowOnTop, AlwaysOnTop, LaunchOnTop, etc.,. The problem with each of these is that it requires the operator to physically select the window which is to remain on top, or with LaunchOnTop, it doesn't work with the windows console window (The command prompt). The point of this program is to have an operator at a pc that controls a manufacturing operation to use a scanner, scan a barcode, and the data they need shows up on the screen, with no other interaction with the program (the dirt simple approach...), so I will not make them fumble around with the mouse, which is required by the above mentioned programs. They are quite nice for what they do, however. The machines I am putting my application on, do not have cygwin installed as a package. What I do is put the compiled exe file and the cygwin1.dll only on the machine and use the windows console as the display window, because all the windows machines have it. I can have them start it with a short cut, and it requires zero support once it is set up. Previous applications I have made in this way automatically loaded the machine's programs for it, but this one requires the operator to read the program output and then enter it in the main application that covers the screen. What I will do: -Check out the run package and see what I can do with it. -See what other window manipulations are possible with gcc libraries. -Keep checking this mailing list for suggestions. This is one of the few lists that actually produces *really good* information. Terry original message:- I have an application written and compiled using gcc and ncurses (for the colors), in the cygwin environment. This application gets information from a database, and displays it to an operator running a machine telling them what program to input (among other things). The problem is that when they go to enter the program name, the console window immediately falls behind that of the application they are entering the data into, and they can't read it. I'm using a shortcut to start this, and the level of display of the window is not one of the options. Does anyone (that will answer) know a way to start this window with the attributes needed so it will not be covered when another application is touched by the mouse? Thanks, Terry Dabbs -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/ -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
RE: Making the command console stay on top
Thank you, Ehud!
You just saved me from writing a GUI that I didn't really have time to
do.
Yes, this one works on console windows, you can name the object you want
to float,
And limit it just to that, and it works if you start it before or after
the application.
Terry
-Original Message-
On Wed, 16 Nov 2005 10:44:21 -0600, Terry Dabbs wrote:
The problem with each of these is that it requires the operator to
physically select the window which is to remain on top, or with
LaunchOnTop, it doesn't work with the windows console window (The
command prompt).
so I will
not make them fumble around with the mouse, which is required by the
above mentioned programs.
Check the PowerMenu by Thong Nguyen. It is free of charge (but no
source) and has command line options that will do what you want.
It is at: http://www.veridicus.com/tummy/programming/powermenu/
Ehud
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem reports: http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ: http://cygwin.com/faq/
Making the command console stay on top
I have an application written and compiled using gcc and ncurses (for the colors), in the cygwin environment. This application gets information from a database, and displays it to an operator running a machine telling them what program to input (among other things). The problem is that when they go to enter the program name, the console window immediately falls behind that of the application they are entering the data into, and they can't read it. I'm using a shortcut to start this, and the level of display of the window is not one of the options. Does anyone (that will answer) know a way to start this window with the attributes needed so it will not be covered when another application is touched by the mouse? Thanks, Terry Dabbs -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
RE: Drop Win9x support? (was: Serious performance problems)
I have an application that is used in a manufacturing environment that runs only on '95 and '98. Our IT department thought, as you do, that it should always be possible to run every Win98/ME binary on XP, in spite of the fact that the company that wrote the application says it is not possible. Turns out, that it is not *always* possible. It will never be upgraded to a newer operating system, as they simply have no one that is buying the app, and we have not found anything that works better for the application. Since I do other things with cywin, I would need multiple, different, installations on my desktop. What fun that would be So, its not a matter of being too cheap, its just being stuck. If cygwin does drop the support for 9x, it would be a hassle, but not fatal, if 1.5.x were easily findable to reinstall when needed. Terry -Original Message- From: On Behalf Of Gerrit P. Haase Sent: Thursday, June 02, 2005 5:33 PM Subject: Re: Drop Win9x support? (was: Serious performance problems) Terry Dabbs wrote: No! I am supporting applications requiring cygwin on '95 and '98 that are not going away anytime soon. I have not seen any Win98/ME PC since about 5 years, we're using NT all over the place. As I started to work in this business NT4 was current, then W2K came up, now every new box is delivered with XP, all NT based systems. I cannot imagine why someone with a PC not older than 5 years doesn't want to spend 100$ to buy an XP license. It should always be possible to run every Win98/ME binary on XP. I was able to run some old PC Games on XP which I couldn't run for about 5 years because the lack of Win98 in my location. The XP system supports running those old binaries. And if you really need Cygwin for Win98, you may use 1.5.x forever. As I have heard, there are still people out there who are running NT4 Server, for about ten years now, using Cygwin B20 since 1999;) It is fitting their needs, so why should they upgrade? Gerrit -- =^..^= -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
RE: Drop Win9x support? (was: Serious performance problems)
No! I am supporting applications requiring cygwin on '95 and '98 that are not going away anytime soon. Terry Gerrit P. Haase wrote: Alternatively, we could drop Win98 support. Yes! The requirement made sense back when WinXP wasn't dominant yet. By now, the last machines still running Win9x are dying or being replaced at a fairly high rate. I'm glad Cygwin was available during the years it's taken for NT-based Windows to take over. It was good work, but it's time to move on. It's not like the current Cygwin totally sucks or anything. I can continue using 1.5 on my last Win9x machine indefinitely. The main reasons to update Cygwin are security fixes and new functionality, and neither is a serious concern on such legacy machines. The tricky part is figuring out how to continue to make Cygwin 1.5 available to those last souls who need Win9x support. Perhaps this could coincide with whatever Cygwin 2.0 will be. I imagine Cygwin 2.0 just being an opportunity to break the ABI, get rid of cruft, etc. This would naturally solve the Cygwin 1.5 availability problem: the new stuff would appear in a different directory on the mirrors, perhaps containing cygwin2 in the path name. Then the current setup.exe will look in the current place for Cygwin, and get only 1.5. Those wanting the new stuff would get a new setup.exe, which will look in the cygwin2 location. If there are still a few things people want to push into the last Cygwin 1.5 releases, that's fine, too. A little parallel development during a major version changeover never killed anyone. Even if some of you disagree with whether to discontinue Win9x support now, some of these issues still bear discussing. This day will come eventually. -- -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
FW: Bug in the /dev/ttySx handling code?
It appears you are using com1, with this command: stty -F /dev/ttyS0 -a But, your strace shows ttyS1, which is com2. Are you plugged into the proper port with your cable? T. Dabbs Subject: Bug in the /dev/ttySx handling code? I compiled a linux program, which uses the serial driver (and is working) under cygwin (winxp), but the communication was not working. For initializing the port, I use: fd = open (dev, O_RDWR | O_NOCTTY); tcgetattr (fd, t1); t1.c_cflag = B19200 | CS8 | PARENB | CLOCAL | CREAD; t1.c_iflag = IGNBRK | INPCK | ISIG; t1.c_oflag = 0; t1.c_lflag = 0; t1.c_cc[VTIME] = 1; t1.c_cc[VMIN] = 0; tcsetattr (fd, TCSAFLUSH, t1); Then normal read/write to the file descriptor follows. strace logged: 47 22132 [main] eibd 3124 fhandler_serial::open: fhandler_serial::open (/dev/ttyS1, 0x8002, 0xF78) 101 22233 [main] eibd 3124 fhandler_base::open_9x: (\\.\com2, 0x8002) 1415 23648 [main] eibd 3124 fhandler_base::set_flags: flags 0x8002, supplied_bin 0x1 59 23707 [main] eibd 3124 fhandler_base::set_flags: filemode set to binary 42 23749 [main] eibd 3124 fhandler_base::open_9x: 0x6C8 = CreateFile (\\.\com2, 0xC000, 0x7, 0x22E990, 0x3, 0x4080, 0) 44 23793 [main] eibd 3124 fhandler_base::open_9x: 1 = fhandler_base::open (\\.\com2, 0x8002) 97 23890 [main] eibd 3124 fhandler_serial::open: 0x1 = fhandler_serial::open (/dev/ttyS1, 0x8002, 0xF78) 45 23935 [main] eibd 3124 open: 5 = open (/dev/ttyS1, 0x8002) 85 24020 [main] eibd 3124 fhandler_serial::tcgetattr: vmin_ 0, vtime_ 0 41 24061 [main] eibd 3124 tcgetattr: iflag 4, oflag 0, cflag 930, lflag 0, VMIN 0, VTIME 0 75 24136 [main] eibd 3124 fhandler_serial::tcgetattr: vmin_ 0, vtime_ 0 46 24182 [main] eibd 3124 tcgetattr: iflag 4, oflag 0, cflag 930, lflag 0, VMIN 0, VTIME 0 57 24239 [main] eibd 3124 fhandler_serial::tcsetattr: action 1 55 24294 [main] eibd 3124 fhandler_serial::tcsetattr: flushed file buffers 210 24504 [main] eibd 3124 fhandler_serial::tcsetattr: vtime 100, vmin 0 42 24546 [main] eibd 3124 fhandler_serial::tcsetattr: ReadTotalTimeoutConstant 100, ReadIntervalTimeout -1, ReadTotalTimeoutMultiplier -1 56 24602 [main] eibd 3124 tcsetattr: iflag 0x11, oflag 0x0, cflag 0x9BE, lflag 0x0, VMIN 0, VTIME 1 43 24645 [main] eibd 3124 tcsetattr: 0 = tcsetattr (5, 1, 22EDF0) A printf of the return code of tcsetattr returned 0. I connected the program using a null modem cable to an other Linux machine. It turned out, that cygwin configured the serial interface to 9600 baud. With this configuration, I can send without any errors data on the linux PC to the cygwin program (and back): stty -F /dev/ttyS0 -a speed 9600 baud; rows 0; columns 0; line = 0; intr = ^C; quit = ^\; erase = ^?; kill = ^U; eof = ^D; eol = undef; eol2 = undef; start = ^Q; stop = ^S; susp = ^Z; rprnt = ^R; werase = ^W; lnext = ^V; flush = ^O; min = 1; time = 5; parenb parodd cs8 -hupcl -cstopb cread clocal -crtscts ignbrk -brkint -ignpar -parmrk -inpck -istrip -inlcr -igncr -icrnl -ixon -ixoff -iuclc -ixany -imaxbel -opost -olcuc -ocrnl -onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0 bs0 vt0 ff0 -isig -icanon -iexten -echo -echoe -echok -echonl -noflsh -xcase -tostop -echoprt -echoctl -echoke On cygwin, stty on the serial is not working (stty -F /dev/ttyS0 shows 0 baud; stty -F /dev/ttyS0 speed 9600 returns an error message). Is the serial driver emulation code not supporting this, or is there an bug in it? mfg Martin Kögler PS: Please CC me on replies -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
RE: Bug in the /dev/ttySx handling code?
Perhaps one of the gurus will chime in I am not an expert, but I produced the following code that works every day on a number of our production machines, using com2 to send data out. The comments are what I put at the time, and as far as I know thet describe accurately what is happening. One note: com_port_name below is the string /dev/com2, not /dev/ttyS1, if that makes a difference. /* We now have the name of the com port. The following opens the port for us to use.*/ rs232_fd = open(com_port_name, O_RDWR | O_NOCTTY ); /* In case this right after a reboot, windows */ /* may be unstable on the com ports. This is */ close(rs232_fd); /* wake it up you might say... */ rs232_fd = open(com_port_name, O_RDWR | O_NOCTTY ); /* Now for real. com_port_name is of the form*/ /* com1, com2, etc.; O_RDWR is open for */ /* read and write. O_NOCTTY indicates there */ /* is no controlling terminal (no tty).*/ /* Now we set the parameters using termios functions, these set the port parameters. Mucho importante! */ tcgetattr(rs232_fd,my_termios); /* Get the current port setup, such as it is. */ my_termios.c_cflag = B9600 | CS8 | CREAD | CLOCAL | HUPCL;/* Set the following communication flags: */ /* B9600 = 9600 Baud rate.*/ /* CS8 = character bits are 8. */ /* CREAD = Enable receiver. */ /* CLOCAL= Ignore modem control lines. No modem here. */ /* HUPCL = Release/close port when the process dies. */ my_termios.c_iflag = IXON | IGNBRK | IGNPAR ; /* Set the following input flags: */ /* IXON = Use XON/XOFF flow on output. */ /* IGNBRK= Ignore Break condition on input. */ /* IGNPAR= Ignore framing and parity errors. */ cfsetospeed(my_termios,B9600); /* Set Speed to 9600 Baud.*/ tcsetattr(rs232_fd,TCSANOW,my_termios); /* Make the my_termios values apply to rs232_fd NOW.*/ tcflush(rs232_fd,TCIOFLUSH); /* Flush any spurious IO data on the port.*/ /* The important opening and set up is done. */ /* Now go read and write. */ Good Luck, Terry -Original Message- Subject: Bug in the /dev/ttySx handling code? On Mon, May 09, 2005 at 12:46:55PM -0500, Terry Dabbs wrote: It appears you are using com1, with this command: stty -F /dev/ttyS0 -a But, you strace shows ttyS1, which is com2. Are you plugged into the proper port with your cable? Yes, I used the right port, as on the Linux PC cat /dev/ttyS0 showed the expected data (after adjusting the configuration of the port), which was send with my program (eibd) using cygwin. In the other direction, I did some echo /dev/ttyS0. With 9600 baud, I get for such a request a block of the same byte (I have not checked the hex code). I am using two PCs, one with Windows, where COM2 is used and a Linux PC with only one COM port. stty -F /dev/ttyS0 -a shows the configuration of the Linux PC. A mode COMx in cmd on a unused port shows a baud rate of 9600, so it looks like, the configuration of the serial port is not changed, although in the current CVS version of fhandler_serial.cc, I can not see any proof for it. At least, I understand, why stty -F /dev/ttyS0 under cygwin return 0 baud: tcgetattr returns 0 baud, if DTR is not set, which is different to the behaviour of Linux. I would like to track the problem down, but as the use of stty (and cat for doing IO) does not work, I have no idea, how to do it. mfg Martin Kögler -- -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
RE: X application fails
No, Exactly the same error. Unfortunately, the only information I got from Agilent was that they couldn't get it to work either, in the past. They said it DOES work on linux with their application (isn't it virtually the same?). In any case thanks for replying. If you have an idea for a direction I could go with this, that would be helpful, otherwise I'll have to try other Xservers. Terry -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Terry Dabbs Sent: Friday, April 08, 2005 12:29 PM To: cygwin-xfree@cygwin.com Subject: RE: X application fails Thanks, I won't be able to try it until Monday. On vacation today, so no direct access. I will let you know... Terry -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Alexander Gottwald Sent: Friday, April 08, 2005 3:41 AM To: cygwin-xfree@cygwin.com Subject: Re: X application fails On Thu, 7 Apr 2005, Terry Dabbs wrote: I'm new to cygwin/X. I installed the cygwin/X package, and an using it with the expectation it will provide a display for hpux clients. What does work: - I use either startxwin.bat -or- startxwin.sh, type xhost + in the shell, then go to the hpux machine and set the display, send xrdb commands, and xterm runs on my pc from the hpux client. Logging in with XDMCP works, it looks very good. What does not work: I have an X application, Agilent's HPSmarttest, which runs OK with reflections XDMCP, but with both methods above it gives the error message (in a window on the display server!) that it can not create background window. Since it works using Reflections, I assume there is some setting, or something that is not set by default. Maybe it's a problem with the missing 8bit colorplane on Cygwin/X server. You might try to run Cygwin/X in 8bit mode (XWin -depth 8 -fullscreen) bye ago -- [EMAIL PROTECTED] http://www.gotti.org ICQ: 126018723
RE: X application fails
Thank You all for your help. I Copied the fonts for HPUX to the fonts directory for Cygwin/X. It works very well now. Terry -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Mark Paulus Sent: Monday, April 11, 2005 2:57 PM To: cygwin-xfree@cygwin.com Subject: RE: X application fails Another option, if it's only 1 app you have problems with is to run an X VNC Server session on your hpux box and then run the VNC Client on your windows box to see the app. I was having some problems with Sun's Workshop Debugger under Cygwin/X, and that was my solution. On Mon, 11 Apr 2005 14:47:01 -0500, Terry Dabbs wrote: No, Exactly the same error. Unfortunately, the only information I got from Agilent was that they couldn't get it to work either, in the past. They said it DOES work on linux with their application (isn't it virtually the same?). In any case thanks for replying. If you have an idea for a direction I could go with this, that would be helpful, otherwise I'll have to try other Xservers. Terry -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Terry Dabbs Sent: Friday, April 08, 2005 12:29 PM To: cygwin-xfree@cygwin.com Subject: RE: X application fails Thanks, I won't be able to try it until Monday. On vacation today, so no direct access. I will let you know... Terry -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Alexander Gottwald Sent: Friday, April 08, 2005 3:41 AM To: cygwin-xfree@cygwin.com Subject: Re: X application fails On Thu, 7 Apr 2005, Terry Dabbs wrote: I'm new to cygwin/X. I installed the cygwin/X package, and an using it with the expectation it will provide a display for hpux clients. What does work: - I use either startxwin.bat -or- startxwin.sh, type xhost + in the shell, then go to the hpux machine and set the display, send xrdb commands, and xterm runs on my pc from the hpux client. Logging in with XDMCP works, it looks very good. What does not work: I have an X application, Agilent's HPSmarttest, which runs OK with reflections XDMCP, but with both methods above it gives the error message (in a window on the display server!) that it can not create background window. Since it works using Reflections, I assume there is some setting, or something that is not set by default. Maybe it's a problem with the missing 8bit colorplane on Cygwin/X server. You might try to run Cygwin/X in 8bit mode (XWin -depth 8 -fullscreen) bye ago -- [EMAIL PROTECTED] http://www.gotti.org ICQ: 126018723
RE: X application fails
Thanks, I won't be able to try it until Monday. On vacation today, so no direct access. I will let you know... Terry -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Alexander Gottwald Sent: Friday, April 08, 2005 3:41 AM To: cygwin-xfree@cygwin.com Subject: Re: X application fails On Thu, 7 Apr 2005, Terry Dabbs wrote: I'm new to cygwin/X. I installed the cygwin/X package, and an using it with the expectation it will provide a display for hpux clients. What does work: - I use either startxwin.bat -or- startxwin.sh, type xhost + in the shell, then go to the hpux machine and set the display, send xrdb commands, and xterm runs on my pc from the hpux client. Logging in with XDMCP works, it looks very good. What does not work: I have an X application, Agilent's HPSmarttest, which runs OK with reflections XDMCP, but with both methods above it gives the error message (in a window on the display server!) that it can not create background window. Since it works using Reflections, I assume there is some setting, or something that is not set by default. Maybe it's a problem with the missing 8bit colorplane on Cygwin/X server. You might try to run Cygwin/X in 8bit mode (XWin -depth 8 -fullscreen) bye ago -- [EMAIL PROTECTED] http://www.gotti.org ICQ: 126018723
X application fails
I'm new to cygwin/X. I installed the cygwin/X package, and an using it with the expectation it will provide a display for hpux clients. What does work: - I use either startxwin.bat -or- startxwin.sh, type xhost + in the shell, then go to the hpux machine and set the display, send xrdb commands, and xterm runs on my pc from the hpux client. Logging in with XDMCP works, it looks very good. What does not work: I have an X application, Agilent's HPSmarttest, which runs OK with reflections XDMCP, but with both methods above it gives the error message (in a window on the display server!) that it can not create background window. Since it works using Reflections, I assume there is some setting, or something that is not set by default. Any ideas? Thanks, Terry Dabbs Here's the log file: Welcome to the XWin X Server Vendor: The Cygwin/X Project Release: 6.8.2.0-1 Contact: XWin was started with the following command line: XWin -multiwindow -clipboard -silent-dup-error ddxProcessArgument - Initializing default screens winInitializeDefaultScreens - w 1024 h 768 winInitializeDefaultScreens - Returning (WW) /tmp mounted int textmode _XSERVTransmkdir: ERROR: euid != 0,directory /tmp/.X11-unix will not be created. (II) XF86Config is not supported (II) See for http://for more information (==) FontPath set to /usr/X11R6/lib/X11/fonts/misc/,/usr/X11R6/lib/X11/fonts/TTF/,/usr/X11R6 /lib/X11/fonts/Type1/,/usr/X11R6/lib/X11/fonts/CID/,/usr/X11R6/lib/X11/f onts/75dpi/,/usr/X11R6/lib/X11/fonts/100dpi/ winAdjustVideoModeShadowGDI - Using Windows display depth of 32 bits per pixel winAllocateFBShadowGDI - Creating DIB with width: 1024 height: 768 depth: 32 winInitVisualsShadowGDI - Masks 00ff ff00 00ff BPRGB 8 d 24 bpp 32 null screen fn ReparentWindow null screen fn RestackWindow InitQueue - Calling pthread_mutex_init InitQueue - pthread_mutex_init returned InitQueue - Calling pthread_cond_init InitQueue - pthread_cond_init returned winInitMultiWindowWM - Hello winInitMultiWindowWM - Calling pthread_mutex_lock () MIT-SHM extension disabled due to lack of kernel support XFree86-Bigfont extension local-client optimization disabled due to lack of shared memory support in the kernel (--) Setting autorepeat to delay=500, rate=31 (--) winConfigKeyboard - Layout: 0409 (0409) (--) Using preset keyboard for English (USA) (409), type 81 winMultiWindowXMsgProc - Hello winMultiWindowXMsgProc - Calling pthread_mutex_lock () (--) 3 mouse buttons found Could not init font path element /usr/X11R6/lib/X11/fonts/CID/, removing from list! winInitMultiWindowWM - pthread_mutex_lock () returned. winMultiWindowXMsgProc - pthread_mutex_lock () returned. winInitMultiWindowWM - pthread_mutex_unlock () returned. winMultiWindowXMsgProc - pthread_mutex_unlock () returned. winMultiWindowXMsgProc - DISPLAY=127.0.0.1:0.0 winInitMultiWindowWM - DISPLAY=127.0.0.1:0.0 winProcEstablishConnection - Hello winInitClipboard () winProcEstablishConnection - winInitClipboard returned. winMultiWindowXMsgProc - XOpenDisplay () returned and successfully opened the display. winInitMultiWindowWM - XOpenDisplay () returned and successfully opened the display. winClipboardProc - Hello DetectUnicodeSupport - Windows NT/2000/XP winClipboardProc - DISPLAY=127.0.0.1:0.0 winClipboardProc - XOpenDisplay () returned and successfully opened the display. winProcSetSelectionOwner - Clipboard not yet started, aborting. winProcSetSelectionOwner - Clipboard not yet started, aborting. AUDIT: Thu Apr 7 14:21:35 2005: 1892 XWin: client 5 rejected from IP 172.16.20.55
RE: Obscene content in cygwin file.
I have an incident from the early 90s that is very close to this discussion: I worked at a division headquarters of large company, where we had hundreds of people who would log into their email account on the VAX. When logging in you would see a message of the day. The guy administering this got tired of the same old boring messages and started rotating in messages very much like the ones in the limerick file. The first couple were only slightly off-color, and actually got positive responses. Then the third, and last one, had to do with a guy in Nantucket who had some unusual practices. The effect this had in the local work place was fun to watch, having the computer pipe that stuff on the screen was about as imaginable as Bush saying it on TV, and created quite a stir. The end result was not so much fun, the employee was severly reprimanded (Andrew wouldn't work there...) and was weeded out in the first layoff (I wonder why...). I don't know if this was a related package, but the guy said he read the first one, and assumed the others were no worse. There was a lot of comment about this, but other than the general opinion the guy was a moron (he wasn't, just young), the overall consensus was who in the hell would provide a software package where such a thing is possible?. You can be sure that some scrutiny as to the supplier occurred. I am fairly sure my vote won't count. But, we need to protect the children, and from reading this thread, the ones that need protecting subscribe to this list. Choices are fine, and maybe immature sysadmins deserve what they get, but the folks that think nothing is wrong with it do not need a temtation like this to show how cool they are. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Christopher Faylor Sent: Friday, January 07, 2005 8:52 AM To: cygwin@cygwin.com Subject: Re: Obscene content in cygwin file. On Fri, Jan 07, 2005 at 01:22:32AM -0500, Brian Bruns wrote: Personally, I thought that them doing this was a sign of a more innocent time, where we didn't have to worry about every single word that came out of our mouth (or keyboard). Seriously guy, your type is one of the primary reasons why the internet is getting - its not quite there yet, but getting - to be *no fun*. It was built on freedom and free-thinking, and the very fact that this conversation is taking place is a testimony to how bitter it has become. rant I tend to agree with you on that. I was on the internet since the middle 90s, and even then, you could start to see new people/businesses forcing their own views on the rest of the Internet, that had been there long before them, and continue to be there long after they are bankrupt/dead/gone/kaput. I've been reading usenet since the early 80's and I find the notion that this kind of discussion is a recent phenomenon sort of amusing. This is *exactly* the type of fodder that has driven Usenet discussions for years. We do get the added spin of workplace lawsuites, yadda yadda, but that just adds more fuel to what would have been a very nicely burning flame. If Cygwin was a true business enterprise, this would be a no-brainer. We'd remove the content. The reason wouldn't be because we are cravenly caving to the PC majority. The reason would be that it might offend a customer who would take their business elsewhere. You can't have that unless you are in a position of not caring about losing a few customers. Not many businesses are in that position. Business issues are not the point here, though. My issue is that I grant others the right to be offended by the type of language we're talking about. It is a given that there are many people in our society who will be offended by it. These people do not buy Playboy or Hustler because they do not like what these magazines represent but they aren't out picketing those establishments, either. So, they are following the Just don't look at it then! scenario. We do not offer these people the same choice with Cygwin. When they innocently download fortune means that they are using hard drives to house unencrypted content that they consider objectionable. That is not fair to them. cgf -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/ -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
RE: FW: comport problem
Brian, You are correct. I used gcc-2 because that is what downloaded by default. Previously, I just used com2, and it was acceptable, and worked fine. I read the code in the some of the other emails in the forum and noted that it was in the form /dev/com2. I changed to format, and it now works great. Thanks, Terry Dabbs On Mon, 23 Aug 2004, Terry Dabbs wrote: I've used a version of cygwin from June of 2003. I've loaded a new version, and apparently gcc is now gcc-2. No, gcc-2 was a package of the old gcc-2.95.x compiler. It was pulled from the distribution because of bugs. gcc is currently version 3.3.3. The problem is that I can't open the comport with the program that previous worked well under the old cygwin/gcc. I noted references in my search for the solution about gcc-2 or cygwin not accepting the name com1, com2 etc. I' love some direction here. This is not a gcc problem at all. Cygwin will let you open COM1, COM2, etc., but it will treat them as regular files. If you are trying to use POSIX functionality (termios, etc.) with that file descriptor, please use the corresponding POSIX device name listed here instead: http://cygwin.com/cygwin-ug-net/using-specialnames.html#AEN825 to open the port. Doing so should eliminate your problem. HTH -- Brian Ford Senior Realtime Software Engineer VITAL - Visual Simulation Systems FlightSafety International the best safety device in any aircraft is a well-trained pilot... -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
FW: comport problem
-Original Message- From: Terry Dabbs Sent: Monday, August 23, 2004 6:58 PM To: [EMAIL PROTECTED] com (E-mail) Subject: comport problem I've used a version of cygwin from June of 2003. I've loaded a new version, and apparently gcc is now gcc-2. The problem is that I can't open the comport with the program that previous worked well under the old cygwin/gcc. I noted references in my search for the solution about gcc-2 or cygwin not accepting the name com1, com2 etc. I' love some direction here. Terry Dabbs -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: ncurses and terminal definitions
Thanks for the clarification. These are pretty standard MS workstations regardless of the task we are using them for (wish it was linux...), so I can't help but use the default drive. So, although it may be something to be aware of, it does appear it is hard to screw it up. Terry Dabbs Larry Hall wrote: Terry Dabbs wrote: Thanks for the help. Since your advice kept me from having to install cygwin on the machines I'm going to run this on, the mounting, I suppose defaults to what it was on my compiling machine, which is the C drive for cygwin in my case. Actually, no. I guess I wasn't clear. Whether the file is found or not depends on the current drive. If the user's current drive is C: and you've installed the file on the C drive, then the path will work. Otherwise, it will complain that the file isn't found. If you want to avoid this, you need to create the mount point I suggested or otherwise wrap your application to make sure that C: is always the current drive when it runs. -- Larry Hall http://www.rfk.com RFK Partners, Inc. (508) 893-9779 - RFK Office 838 Washington Street (508) 893-9889 - FAX Holliston, MA 01746 -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
ncurses and terminal definitions
I've been using gcc to compile some simple applications for NT win98 and win95 for automating machinery. I have a problem on one screen where you can't read the command.com screen (windows98) clearly, so I loaded ncurses, redid the application so it the text is very bright and colorful even on the poor screen. Very nice. The problem is, I was up to now only needing to place the cygwin1.dll on each machine I put a program on, and that's all, with the exception of the executable and miscellaneous setup files. I thought I would only have to place the cygncurses7.dll on the machines as well. I moved the executable and placed cygncurses7.dll on a machine, tried it, and got Error opening terminal: cygwin. I read references to this in the mailing lists, which say do an install on each machine with multiple packages using setup. For a number of reasons I wish to avoid this, the least of which is they are not on the net. What is the least amount of files I need, and where should I put them for ncurses to identify the terminal on the machines I need to put my executable? Can you help? Thanks Terry Dabbs -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: ncurses and terminal definitions
Larry, I just copied the path so the file is c:\usr\share\terminfo\c\cygwin directly from the machine I compile with. This does work, and cygwin, yet again, has made my little project happier. I do note that the laptop running win98 I tried this on took a good 20 seconds to give up the terminal to the program. Is this just because the lap top is slow (it is...) or is win98 simply that poor compared to NT in performance. The delay on NT, if any, is not perceptable Thanks, Terry Dabbs Larry Hall wrote: Terry Dabbs wrote: I've been using gcc to compile some simple applications for NT win98 and win95 for automating machinery. I have a problem on one screen where you can't read the command.com screen (windows98) clearly, so I loaded ncurses, redid the application so it the text is very bright and colorful even on the poor screen. Very nice. The problem is, I was up to now only needing to place the cygwin1.dll on each machine I put a program on, and that's all, with the exception of the executable and miscellaneous setup files. I thought I would only have to place the cygncurses7.dll on the machines as well. I moved the executable and placed cygncurses7.dll on a machine, tried it, and got Error opening terminal: cygwin. I read references to this in the mailing lists, which say do an install on each machine with multiple packages using setup. For a number of reasons I wish to avoid this, the least of which is they are not on the net. What is the least amount of files I need, and where should I put them for ncurses to identify the terminal on the machines I need to put my executable? Can you help? It's just looking for the 'cygwin' terminal database. You can find that in /usr/share/terminfo/c/cygwin. -- Larry Hall http://www.rfk.com RFK Partners, Inc. (508) 893-9779 - RFK Office 838 Washington Street (508) 893-9889 - FAX Holliston, MA 01746 -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/ -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: ncurses and terminal definitions
Thanks for the help. Since your advice kept me from having to install cygwin on the machines I'm going to run this on, the mounting, I suppose defaults to what it was on my compiling machine, which is the C drive for cygwin in my case. Thanks. Larry Hall wrote: Christopher Faylor wrote: On Thu, Jul 31, 2003 at 04:47:13PM -0400, Larry Hall wrote: Hi Terry, Don't know exactly what accounts for the performance drain you see with 98. Like you say, could be just a slow machine. You'd have to debug it to know for sure. One point. /usr/share/terminfo/c/cygwin == c:\usr\share\terminfo\c\cygwin only if the Cygwin root mount point (/) == c:\. As you can see, you get this for free if your current drive is c: but that's not guaranteed. You may want to add one step and one binary to your installation procedure. That is, after plopping the files down where you want them, invoke the following: mount -s c:/ / This will require privileges to write to the system hive of the registry. If you don't have this right or can't get it, you can omit the '-s' flag, but the mount will only be available for the current user. You will need to repeat the command (minus the '-s') for all the users that need your application on that machine. You don't need to leave 'mount' on the machine after installation. Larry - mount defaults to -s these days. If you want user-mode mounts, you need to use -u. Heh. Right. Sorry about that. I will always consult the documentation before posting. I will always consult the documentation before posting. I will always consult the documentation before posting. . . . (Good advice for new users too. ;-) ) -- Larry Hall http://www.rfk.com RFK Partners, Inc. (508) 893-9779 - RFK Office 838 Washington Street (508) 893-9889 - FAX Holliston, MA 01746 -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/ -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
gcc using termios.h and -mno-cygwin
I am new and may really get flamed on this I need to do serial port IO on Windows98 and NT using com1 and com2. I have seen some nice examples which compile and execute without using -mno-cygwin in the archives. When I use the -mno-cygwin option I get the error termios.h not found. this is true using #include sys/termios.h and #include termios.h. (1) Should this work with termios.h and -mno-cygwin together? (2) If not, does anyone have some sample code showing a good method to read/write com1 without termios.h functions? Thanks, Terry Dabbs -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
