Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-owner AT cygwin DOT com Mail-Followup-To: cygwin AT cygwin DOT com Delivered-To: mailing list cygwin AT cygwin DOT com To: cygwin AT cygwin DOT com Subject: RE: Ctrl-Z fails to suspend Windows programs From: John Cooper Date: Tue, 15 Jun 2004 16:11:41 +0100 Message-ID: <87ekogc0uq.fsf@eu.citrix.com> User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-imss-version: 2.5 X-imss-result: Passed X-imss-scores: Clean:64.32068 C:35 M:2 S:5 R:5 X-imss-settings: Baseline:4 C:4 M:4 S:4 R:1 (1.0000 4.0000) X-IsSubscribed: yes > The point is that it's not about cygwin-vs-windoze apps. It's about > apps-that-use-console-stdin-and-stdout vs. apps-that-display-a-gui; those > that show a gui could usefully be detached, but those that read their input > from stdin will break if the shell detaches them. Yes, you're right, the old "native" zsh option was specifically to do with GUI apps rather than "Windows" apps per se - here's the doc to for enabling the option (it was off by default): winntwaitforguiapps: When set, makes the shell wait for win32 GUI apps to terminate instead of spawning them asynchronously. > I don't think there's a reliable enough mechanism by which a shell could > detect one case from the other. Below is the code it used to determine if a program is a GUI program or not. I don't know how well it works under all conditions; however it did work fine for me. Even if not perfectly reliable, could something like this be added but disabled by default? I for one would find it useful. --- John /* How To Determine Whether an Application is Console or GUI [win32sdk] ID: Q90493 CREATED: 15-OCT-1992 MODIFIED: 16-DEC-1996 */ #include #define xmalloc(s) HeapAlloc(GetProcessHeap(),HEAP_ZERO_MEMORY,(s)) #define xfree(p) HeapFree(GetProcessHeap(),0,(p)) #define XFER_BUFFER_SIZE 2048 int is_gui(char *exename) { HANDLE hImage; DWORD bytes; DWORD SectionOffset; DWORD CoffHeaderOffset; DWORD MoreDosHeader[16]; ULONG ntSignature; IMAGE_DOS_HEADER image_dos_header; IMAGE_FILE_HEADER image_file_header; IMAGE_OPTIONAL_HEADER image_optional_header; hImage = CreateFile(exename, GENERIC_READ, FILE_SHARE_READ, NULL, OPEN_EXISTING, FILE_ATTRIBUTE_NORMAL, NULL); if (INVALID_HANDLE_VALUE == hImage) { return 0; } /* * Read the MS-DOS image header. */ if (!ReadFile(hImage, &image_dos_header, sizeof(IMAGE_DOS_HEADER), &bytes,NULL)){ CloseHandle(hImage); return 0; } if (IMAGE_DOS_SIGNATURE != image_dos_header.e_magic) { CloseHandle(hImage); return 0; } /* * Read more MS-DOS header. */ if (!ReadFile(hImage, MoreDosHeader, sizeof(MoreDosHeader), &bytes,NULL)){ CloseHandle(hImage); return 0; } /* * Get actual COFF header. */ CoffHeaderOffset = SetFilePointer(hImage, image_dos_header.e_lfanew, NULL,FILE_BEGIN); if (CoffHeaderOffset == (DWORD) -1){ CloseHandle(hImage); return 0; } CoffHeaderOffset += sizeof(ULONG); if (!ReadFile (hImage, &ntSignature, sizeof(ULONG), &bytes,NULL)){ CloseHandle(hImage); return 0; } if (IMAGE_NT_SIGNATURE != ntSignature) { CloseHandle(hImage); return 0; } SectionOffset = CoffHeaderOffset + IMAGE_SIZEOF_FILE_HEADER + IMAGE_SIZEOF_NT_OPTIONAL_HEADER; if (!ReadFile(hImage, &image_file_header, IMAGE_SIZEOF_FILE_HEADER, &bytes, NULL)){ CloseHandle(hImage); return 0; } /* * Read optional header. */ if (!ReadFile(hImage, &image_optional_header, IMAGE_SIZEOF_NT_OPTIONAL_HEADER,&bytes,NULL)) { CloseHandle(hImage); return 0; } CloseHandle(hImage); if (image_optional_header.Subsystem ==IMAGE_SUBSYSTEM_WINDOWS_GUI) return 1; return 0; } int is_9x_gui(char *prog) { char *progpath; DWORD dwret; char *pathbuf; char *pext; pathbuf=xmalloc(MAX_PATH); progpath=xmalloc(MAX_PATH<<1); if (GetEnvironmentVariable("PATH",pathbuf,MAX_PATH) ==0) { goto failed; } pathbuf[MAX_PATH]=0; dwret = SearchPath(pathbuf,prog,".EXE",MAX_PATH<<1,progpath,&pext); if ( (dwret == 0) || (dwret > (MAX_PATH<<1) ) ) goto failed; dprintf("progpath is %s\n",progpath); dwret = is_gui(progpath); xfree(pathbuf); xfree(progpath); return dwret; failed: xfree(pathbuf); xfree(progpath); return 0; } --- John -----Original Message----- From: Dave Korn [mailto:dk AT artimi DOT com] Sent: 15 June 2004 15:40 To: 'John Cooper'; cygwin AT cygwin DOT com Subject: RE: Ctrl-Z fails to suspend Windows programs > -----Original Message----- > From: cygwin-owner On Behalf Of John Cooper > Sent: 15 June 2004 15:05 > To: cygwin > Subject: RE: Ctrl-Z fails to suspend Windows programs > > The old native (non-cygwin) port of zsh would somehow detect if it was > about to exec a Windows app, and run it as a background process, thus > returning a zsh prompt immediately. Could something like this be > added to cygwin bash/zsh? AFAICS the ability is already there. Just enter "windows_app.exe &" at a bash shell. > This was very useful. With the cygwin zsh, I often find myself > invoking a Windows app and not being able to get back to the shell > window without first terminating the Windows app. Well, the same goes if you run a cygwin app: you don't get the prompt back until it exits. The point is that it's not about cygwin-vs-windoze apps. It's about apps-that-use-console-stdin-and-stdout vs. apps-that-display-a-gui; those that show a gui could usefully be detached, but those that read their input from stdin will break if the shell detaches them. I don't think there's a reliable enough mechanism by which a shell could detect one case from the other. Try starting insight (gui version of gdb) from the bash prompt. You also won't get a shell back until it exits. cheers, DaveK -- Can't think of a witty .sigline today.... -- 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/