From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from ffbox0-bg.mplayerhq.hu (ffbox0-bg.ffmpeg.org [79.124.17.100]) by master.gitmailbox.com (Postfix) with ESMTP id C6E6742B57 for ; Tue, 26 Apr 2022 07:29:37 +0000 (UTC) Received: from [127.0.1.1] (localhost [127.0.0.1]) by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTP id 3E8A668B2AA; Tue, 26 Apr 2022 10:29:35 +0300 (EEST) Received: from mail-pj1-f53.google.com (mail-pj1-f53.google.com [209.85.216.53]) by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTPS id DB15E68B15E for ; Tue, 26 Apr 2022 10:29:28 +0300 (EEST) Received: by mail-pj1-f53.google.com with SMTP id fv2so2216496pjb.4 for ; Tue, 26 Apr 2022 00:29:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=gmJJ5j9XtUj3CfA5ZFtIf3EVcfaXj5oyex6VruY9D3I=; b=IqgmTbkv7n1nSa3K3maMnIZD5MJbz8FoBzRAGlGMZ4CkbfcxJ0dICdlUsBzE/r5EBr IL0yciHrQ8SOmfECvUElgWjUFwwuT/gKyRc5LE8F9jdewiL9Smor8K+ed3VUCNf5O8vS CluSmTPPm22fp3dD2qiZcWVHZ+JOXy6rQfjZ8rL6i+YJGQjDVk7i1fAkfu7SJW7JgGCX NJnksuKtOVmN/SPrTwFsNh4Tz/ATzR0xKRExPuGv0JEEh7ZVjt3qPuXvTb5Lq4Kx5Tzw CANo+rEktUU7hzeh20vHwiqzYL0Phdc1er05ruWQZAsBZyX3rIDHu93hPf3S+F2MUAXE zCkg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=gmJJ5j9XtUj3CfA5ZFtIf3EVcfaXj5oyex6VruY9D3I=; b=kJERwy8nFAAMDbTIkrRY424p8jlGLyft5DZQ5q7DT1IzM2pxZLZ3PhAxtZENpFV+Bf 6mlyGgsEEhnDjOICi0HoEVKgz0MQNm+Ck8p0xKpKjoU2KsjcT7IBWtPbiTjM3Jf0XBwz ILMPF1gj/KpR/MEZSyET73ETmsC2I1CLVTyNZNafJKIM5fpcP49fbL1UI0uWiyTwOxHw yoZisjVQIcM8++Us1X7jspTE9Z+b+zmETKOA+lk5oBdhkANTHwg2Ggd8eUIvxmTO8Jyg CPbi+wvzC5mb0Rgl1sroMBO/egsYKGaxH4eJ0o69YndOyRdEehp59bjNJcAAUu9bfsp6 D3Gw== X-Gm-Message-State: AOAM533ORA0tcfQfsjPLu39HFDlsM9br9AB+CN3Q0eQA44RKuEB+oWDD Y9gUaSgxy3mOgo1LcHCljkjrWf7SGTy5fUu9hIqh8UY5 X-Google-Smtp-Source: ABdhPJxAgNyCN+rK9tkphZuMEcelGeb2qDUquJMSSE3j5N7LJ4wSmwP/+o/9/CMg4F0eOTuYfP9qFkyIm7kTOq06ZO8= X-Received: by 2002:a17:903:20d3:b0:15b:153c:6f79 with SMTP id i19-20020a17090320d300b0015b153c6f79mr21729538plb.157.1650958166825; Tue, 26 Apr 2022 00:29:26 -0700 (PDT) MIME-Version: 1.0 References: <20220423205626.39039-1-nil-admirari@mailo.com> <20220423205626.39039-5-nil-admirari@mailo.com> In-Reply-To: From: Hendrik Leppkes Date: Tue, 26 Apr 2022 09:29:14 +0200 Message-ID: To: FFmpeg development discussions and patches Subject: Re: [FFmpeg-devel] [PATCH v11 5/6] fftools: Enable long path support on Windows (fixes #8885) X-BeenThere: ffmpeg-devel@ffmpeg.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: FFmpeg development discussions and patches List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Reply-To: FFmpeg development discussions and patches Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: ffmpeg-devel-bounces@ffmpeg.org Sender: "ffmpeg-devel" Archived-At: List-Archive: List-Post: On Tue, Apr 26, 2022 at 9:08 AM Tobias Rapp wrote: > > On 23/04/2022 22:56, Nil Admirari wrote: > > Newer versions of Windows (Windows 10 1607 and newer) can support path > > names longer than MAX_PATH (260 characters). To take advantage of that, an > > application needs to opt in, by including a small manifest as a resource. > > > > Application must be prepared to handle filenames greater than MAX_PATH. > > Additionally, the path length limitation is only lifted for file APIs that > > pass paths as wchar_t. Therefore, the preceding patches have refactored a > > few remaining cases where: > > 1. filename length was restricted to MAX_PATH > > 2. files were opened using ANSI functions. > > > > On older versions of Windows, the newly added manifest has no effect. > > --- > > fftools/Makefile | 5 +++++ > > fftools/fftools.manifest | 10 ++++++++++ > > fftools/manifest.rc | 3 +++ > > 3 files changed, 18 insertions(+) > > create mode 100644 fftools/fftools.manifest > > create mode 100644 fftools/manifest.rc > > > > diff --git a/fftools/Makefile b/fftools/Makefile > > index 81ad6c4f..105ae5cc 100644 > > --- a/fftools/Makefile > > +++ b/fftools/Makefile > > @@ -15,6 +15,11 @@ OBJS-ffmpeg += \ > > fftools/ffmpeg_mux.o \ > > fftools/ffmpeg_opt.o \ > > > > +# Windows resource files > > +OBJS-ffmpeg-$(HAVE_GNU_WINDRES) += fftools/manifest.o > > +OBJS-ffplay-$(HAVE_GNU_WINDRES) += fftools/manifest.o > > +OBJS-ffprobe-$(HAVE_GNU_WINDRES) += fftools/manifest.o > > + > > define DOFFTOOL > > OBJS-$(1) += fftools/cmdutils.o fftools/opt_common.o fftools/$(1).o $(OBJS-$(1)-yes) > > $(1)$(PROGSSUF)_g$(EXESUF): $$(OBJS-$(1)) > > diff --git a/fftools/fftools.manifest b/fftools/fftools.manifest > > new file mode 100644 > > index 00000000..30b7d8fe > > --- /dev/null > > +++ b/fftools/fftools.manifest > > @@ -0,0 +1,10 @@ > > + > > + > > + > > + > > What is the effect of the version attribute here? Would it be meaningful > to replace the static dummy value with something more realistic like > "5.1.n" or similar? > > Just asking as I'm not very familiar with manifest resources. > The assembly version does not have any important meaning, not for assemblies used in this manner. It would only matter if you were to reference other assemblies across files, which is not done for these application settings - and even then the only real importance would be to increment it when its changed in an incompatible manner, not necessarily linked to the application version, which is stored in a resource file instead of the assembly. - Hendrik _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe".