From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Carsten Mattner Newsgroups: gmane.emacs.devel Subject: Re: gnutls for lose32 Date: Mon, 2 Jan 2012 14:06:25 +0100 Message-ID: References: <87aa68dfao.fsf@lifelogs.com> <4F0154F1.6000002@cs.ucla.edu> <4F01A04C.4090201@cs.ucla.edu> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Trace: dough.gmane.org 1325509599 3450 80.91.229.12 (2 Jan 2012 13:06:39 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Mon, 2 Jan 2012 13:06:39 +0000 (UTC) Cc: Eli Zaretskii , rms@gnu.org, nmav@gnutls.org, emacs-devel@gnu.org To: Paul Eggert Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Jan 02 14:06:35 2012 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([140.186.70.17]) by lo.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1Rhhb0-0000md-IO for ged-emacs-devel@m.gmane.org; Mon, 02 Jan 2012 14:06:34 +0100 Original-Received: from localhost ([::1]:49609 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Rhhaz-0001vH-UT for ged-emacs-devel@m.gmane.org; Mon, 02 Jan 2012 08:06:33 -0500 Original-Received: from eggs.gnu.org ([140.186.70.92]:49001) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Rhhaw-0001v0-WB for emacs-devel@gnu.org; Mon, 02 Jan 2012 08:06:31 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Rhhav-0004qN-Mr for emacs-devel@gnu.org; Mon, 02 Jan 2012 08:06:30 -0500 Original-Received: from mail-iy0-f169.google.com ([209.85.210.169]:48883) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Rhhar-0004pI-UZ; Mon, 02 Jan 2012 08:06:26 -0500 Original-Received: by iacb35 with SMTP id b35so32020835iac.0 for ; Mon, 02 Jan 2012 05:06:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=nP9ljilAGL/kocs4v9dtIQCp6yuggz/n+wF6B3vMYvw=; b=LCRPiT6az2YfV+iKzX6q/J1dDfOO6tfQIRFnL1MImtQ2SOELxnC5iSQdriSA3y8Q78 sntdXhMJ/nc7e5mFw1GT/MtcFCos29W71XERbO2hDIUZjfQ/r6FqgitoTuMOG5TDfkUW Dssm61Zw0DNEm6SE2wEinnVKEggd3Zm0L7JmI= Original-Received: by 10.50.186.226 with SMTP id fn2mr58199174igc.25.1325509585163; Mon, 02 Jan 2012 05:06:25 -0800 (PST) Original-Received: by 10.50.106.132 with HTTP; Mon, 2 Jan 2012 05:06:25 -0800 (PST) In-Reply-To: <4F01A04C.4090201@cs.ucla.edu> X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 2) X-Received-From: 209.85.210.169 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:147172 Archived-At: On Mon, Jan 2, 2012 at 1:17 PM, Paul Eggert wrote: > On 01/02/12 02:46, Carsten Mattner wrote: > >> "win32" is used in the same way as "posix" to refer to a set of >> platform APIs. > > That's one name, but it's not the only one and it's not necessarily > even the most common one in practice. =A0As discussed in > , > Microsoft prefers the name "Windows API" to "Win32 API", I have a hard time to decipher/interpret the following unambiguously: "(Note that this was formerly called the Win32 API. The name Windows API more accurately reflects its roots in 16-bit Windows and its support on 64-bit Windows.)" > and "Windows API" is quite commonly used. =A0Using this common > name to talk about the API helps us to avoid the problem with "win". It's the same imprecise definition as for posix. > For Emacs's own identifiers, common practice is to use "w32_" > as a prefix; perhaps that should be changed to something else > at some point (when 64-bit Windows takes over?), but this should > be an independent issue. =A0The proposed patch by and large > leaves "w32" alone, since "w32" doesn't run afoul of the "win" > issue. I never understood what win64 is with the same code written for "win32" compiled for x86_64 being a "win64" binary. win32 was probably introduced during the Windows 95/Windows NT move to differentiate 16-bit APIs. They shouldn't have introduced a new name in the first place, but it's one of the companies which strives to give stuff a new name and sell it as something brand new. A preprocessor definition or compiler switch would have been enough. This is probably what you get when marketing is involved when naming internal technical stuff.