Mailing-List: contact cygwin-help AT sourceware DOT cygnus DOT com; run by ezmlm List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-owner AT sourceware DOT cygnus DOT com Delivered-To: mailing list cygwin AT sourceware DOT cygnus DOT com From: Chris Faylor Date: Wed, 19 Apr 2000 13:05:14 -0400 To: cygwin AT sourceware DOT cygnus DOT com Subject: Re: Cygwin 1.1.0 gdb troubles Message-ID: <20000419130514.B15213@cygnus.com> Reply-To: cygwin AT sourceware DOT cygnus DOT com Mail-Followup-To: cgf AT cygnus DOT com, cygwin AT sourceware DOT cygnus DOT com References: <7703 DOT 000419 AT is DOT lg DOT ua> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.1.8i In-Reply-To: <7703.000419@is.lg.ua>; from paul-ml@is.lg.ua on Wed, Apr 19, 2000 at 04:53:38PM +0300 On Wed, Apr 19, 2000 at 04:53:38PM +0300, Paul Sokolovsky wrote: > If no cygwin people will agree with you, then at least me will. >IMHO, win32 is undoubtfully POSIX by spirit, only having somewhat >twisted upbringing. Almost any POSIX feature maps one-to-one to win32 >one and difference is only in some idiosyncratic details. As an >example, DeleteFile() does exactly what remove() does with one >difference: remove() explicitly states possibility of removing opened >file, while DeleteFile() explicitly prohibits it. I can't believe >there's some adequate reasoning behind DeleteFile()'s behaviour. I >just can imagine some win32 architect reading POSIX spec and time to >time exclaiming: 'And *here*, we'll do vice-versa!' ;-) So, how do you work around this tiny little flaw then? How does your magic wand work? > Well, what idiosyncratic features of native pids would harden >their usage as POSIX pisd as-is? > >1. While NT's pids are rather POSIX-correct as-is, 9x's ones are >negative values, large (up to 10 dec digits) by module. >2. There's no documented way to get ppid on NT. >3. It's impossible to overlay image of current process. This means, >when performing usual fork-exec chain, there will be three processes: >parent, exec() implementer stub and execed child. So, between child >and parent in POSIX terms there will be other process. > > While these problems may seem denying original idea, they hardly >do. The workarounds for them exist, working and confidently may be >called more robust than maintaining additional superstructures, >moreover shared between all processes. I'd like to hear your workaround for these problems. Really. I'm eager to incorporate your advanced thinking into cygwin's design. Or are you just here to poke fun and jeer? >Well, *that*'s not most annoying feature of cygwin. Just net version >ago there might arise problems with just having cygwin work properly >after installation, mostly because ungrounded default mount table >setup. But look - this version now takes care to ask user where he >wants having root mount. So, all consistently improving and maybe one >day other areas also will be addressed. Probably the most annoying feature of cygwin for me is that people seem to be compelled to criticize it while offering only vague generalities and smug assertions that they could do it better. It is astounding to me that this is an open source project for which patches have always been accepted but people like you find it acceptable to criticize the way things are done. If you don't like the way cygwin handles things, feel free to redesign and improve. As I stated, I would be quite fascinated to see patches which illustrate your ideas. Before you offer the standard response of "I'm too busy", just take a moment to reflect on what that statement means. If you are too busy to actually investigate these "problems" and offer concrete solutions, then why should I believe that your ideas have any merit whatsoever? How can you adequately criticize something that you don't understand? Ah. The next argument will be that you have already implemented your own POSIX-on-Windows and know everything that Cygwin did wrong. So, ok. I'm willing to listen to how you mapped UNIX signals onto what Win32 offers. I'll be interested in hearing how you got exec() working. You probably have implemented a fork. I'd be interested in hearing how it differs substantially from what cygwin offers. Hmm. You disparage the cygwin mount table. Let's hear how you have tackled this problem. I don't consider any of this off-topic for this mailing list. I envision that you will probably want to enlighten us all with a series of articles on how it could all be done better, complete with actual code samples. Since this will be a substantial work, I guarantee that I will set aside a portion of my day, every day to read and analyze what you post. In fact, I'm quite looking forward to your submissions. Although you're probably too busy to provide cygwin patches, I expect that your insightful articles will still provide substantial fodder for future cygwin development. cgf -- Want to unsubscribe from this list? Send a message to cygwin-unsubscribe AT sourceware DOT cygnus DOT com