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 C705D42B6A for ; Tue, 26 Apr 2022 08:33:47 +0000 (UTC) Received: from [127.0.1.1] (localhost [127.0.0.1]) by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTP id E9D6D68B2E6; Tue, 26 Apr 2022 11:33:44 +0300 (EEST) Received: from server6.ceeqoo.com (server6.ceeqoo.com [178.77.101.243]) by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTPS id 05D4D68A4C3 for ; Tue, 26 Apr 2022 11:33:38 +0300 (EEST) Received: from mailix (www.noaport.de [109.90.164.154]) by server6.ceeqoo.com (Postfix) with ESMTPA id DCEF7BD752 for ; Tue, 26 Apr 2022 10:33:36 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=noa-archive.com; s=default; t=1650962017; bh=Ug9PY2ScXnv8goybwUu9VXXRRCqxp3C9/RHwdeq533k=; h=Received:Subject:To:From; b=fQhTJO1/vsNd2vsWOVjMZFQL/aaePz8VtUHJECLBsaPlc/XM1ZYypW/+hd99mrPpf QLGk4efn3T6Lin05+U5UJHItQL/6sqRlAaX4iU+sDt025CRmIjjuo4PGC+OaZDIdoA RBKTh82WdTEyS4397ykm8dP8G7PVawbff0Za+w98= Authentication-Results: server6.ceeqoo.com; spf=pass (sender IP is 109.90.164.154) smtp.mailfrom=t.rapp@noa-archive.com smtp.helo=mailix Received-SPF: pass (server6.ceeqoo.com: connection is authenticated) Received: from [192.168.0.125] (Unknown [192.168.0.1]) by mailix with ESMTPSA (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128) ; Tue, 26 Apr 2022 10:33:36 +0200 Message-ID: <35fb10c3-cadb-e7c0-40f4-3524ad04cd22@noa-archive.com> Date: Tue, 26 Apr 2022 10:33:35 +0200 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101 Thunderbird/91.8.1 Content-Language: en-US To: ffmpeg-devel@ffmpeg.org References: <20220423205626.39039-1-nil-admirari@mailo.com> <20220423205626.39039-5-nil-admirari@mailo.com> From: Tobias Rapp Organization: NOA GmbH In-Reply-To: X-PPP-Message-ID: <165096201739.12378.15731989380454180984@server6.ceeqoo.com> X-PPP-Vhost: noa-archive.com 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-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Errors-To: ffmpeg-devel-bounces@ffmpeg.org Sender: "ffmpeg-devel" Archived-At: List-Archive: List-Post: On 26/04/2022 09:29, Hendrik Leppkes wrote: > 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. Alright then, thanks for the clarification. Regards, Tobias _______________________________________________ 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".