From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: =?utf-8?Q?=C3=93scar_Fuentes?= Newsgroups: gmane.emacs.devel Subject: Re: Windows 9X compatibility Date: Sun, 28 Mar 2010 21:57:02 +0200 Message-ID: <87iq8g2p9t.fsf@telefonica.net> References: <83634jglab.fsf@gnu.org> <831vf7ge57.fsf@gnu.org> <83y6hfeyzw.fsf@gnu.org> <83vdcig87f.fsf@gnu.org> <87k4sywpvv.fsf@stupidchicken.com> <83tys2fbxs.fsf@gnu.org> <87hbo1iubm.fsf@home.jasonrumney.net> <83ljddg0w9.fsf@gnu.org> <4BAE867D.3030404@gmail.com> <4BAE9ED4.6070900@t-online.de> <4BAEA525.20709@gmail.com> <83iq8ggbcp.fsf@gnu.org> <87mxxs3311.fsf@telefonica.net> <83eij430fc.fsf@gnu.org> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: dough.gmane.org 1269806258 30879 80.91.229.12 (28 Mar 2010 19:57:38 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Sun, 28 Mar 2010 19:57:38 +0000 (UTC) To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sun Mar 28 21:57:34 2010 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1Nvybz-00020X-K2 for ged-emacs-devel@m.gmane.org; Sun, 28 Mar 2010 21:57:31 +0200 Original-Received: from localhost ([127.0.0.1]:50195 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Nvybz-0000vw-5G for ged-emacs-devel@m.gmane.org; Sun, 28 Mar 2010 15:57:31 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1Nvybn-0000qu-Aj for emacs-devel@gnu.org; Sun, 28 Mar 2010 15:57:19 -0400 Original-Received: from [140.186.70.92] (port=48522 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Nvybl-0000q5-BE for emacs-devel@gnu.org; Sun, 28 Mar 2010 15:57:18 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1Nvybk-0004S4-37 for emacs-devel@gnu.org; Sun, 28 Mar 2010 15:57:17 -0400 Original-Received: from lo.gmane.org ([80.91.229.12]:36480) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1Nvybj-0004Rl-Hf for emacs-devel@gnu.org; Sun, 28 Mar 2010 15:57:16 -0400 Original-Received: from list by lo.gmane.org with local (Exim 4.69) (envelope-from ) id 1Nvybh-0001pf-RW for emacs-devel@gnu.org; Sun, 28 Mar 2010 21:57:13 +0200 Original-Received: from 83.32.114.13 ([83.32.114.13]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sun, 28 Mar 2010 21:57:13 +0200 Original-Received: from ofv by 83.32.114.13 with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sun, 28 Mar 2010 21:57:13 +0200 X-Injected-Via-Gmane: http://gmane.org/ Original-Lines: 68 Original-X-Complaints-To: usenet@dough.gmane.org X-Gmane-NNTP-Posting-Host: 83.32.114.13 User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.1.93 (gnu/linux) Cancel-Lock: sha1:YKsdNGN4igx5xQU98Nu/tOVUuvc= X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 3) X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:122809 Archived-At: Eli Zaretskii writes: >> Maybe the fact that there are no more active maintainers of the >> MS-Windows port is somewhat related to the pain in the rear that W9X >> compatbility is? > > Who said there are no more active maintainers? "no more" in the sense "more than we have today". I was not saying that there are no people working on the Windows port. >> First, I don't have a machine for testing. > > Neither do I. There's no requirement to test the code on Windows 9X, > only not to use code that we _know_in_advance_ will break W9X. ... and precisely gaining this information is difficult, because you must read the documentation for every API call and even then you can hit a bug, which is not rare in W9X (and before you say that any API has this problem, well, yes, but not to the extent of W9X). > There's no requirements to use W9X-specific APIs. Sorry, but do you have experience writing Windows raw API code on its successive incarnations since Windows 95? I'm starting to think you have not. Looking at the set of functions that makes the Windows API, those available on W95 are, for the most part, a proper subset of those available on XP. So, in theory, and unless you use certain obsoleted parts of the API (shell interaction, for instance, which is not part of the proper Windows OS API anyways) you are fine developing for W95. BUT there are two problems: quite a few W9X functions were extended on successive Windows versions with new features, so checking that the function is available on W9X is not enough, you must check that the way you intend to use the function is supported by W95. Often those differences are so fundamental that you must split the usage of the API call, one instance for W9X and another for NT (if you are lucky). Second, bugs are so frequent in the W9X API that, to all practical uses, quite a few functions have a non-documented behaviour that you must be aware of. There are certain areas where the problem is not serious enough to notice (mostly GDI) but threading, networking and I/O in general is a minefield. [snip] >> which greatly adds to the maintenance burden. > > True, there is some maintenance burden, but I personally find it > insignificant. The code to load a library safely and invoke functions > that may not exist is very simple, almost boilerplate, and each > additional API that needs this treatment just needs more-or-less > copy-pasted more of the same. This is no solution at all for the general problem. A pure W32 API application made for W95 will build fine with modern versions of the SDK, and XP (or Windows7) will execute it without complaining. But chances are that it will not behave as it did on W95. > Once again, I'm bewildered by the intense reaction to this issue, > given the facts. If current Windows maintainers are fine with this scenario, they are the people who keep the Emacs port on a great shape *now* so they have the right to set the policy. OTOH, it would be a good thing for the Emacs project to lower the entry barrier as much as possible, as I previously said discussing other topics. Is future W9X support important enough to risk the loss of just *one* prospective contributor?