summaryrefslogtreecommitdiffstats
path: root/osdep/path-win.c
Commit message (Collapse)AuthorAgeFilesLines
* various: use correct PATH_MAX for win32sfan52023-12-271-6/+5
| | | | | | | | In commit c09245cdf2491211f3e0bfe47f28cc0e0a2e05c8 long-path support was enabled for mpv without actually making sure that there was no code left that used the old limit (260 Unicode chars) for buffer sizes. This commit fixes all but one case.
* ALL: use new mp_thread abstractionKacper Michajłow2023-11-051-5/+5
|
* path-win: move state directory to %LOCALAPPDATA%Kacper Michajłow2023-07-291-0/+2
| | | | %LOCALAPPDATA% is where the local application state belongs.
* path-win: add subdirectory for cacheKacper Michajłow2023-07-291-1/+1
| | | | To not polute %LOCALAPPDATA%/mpv as it may be used for other things too.
* path-win: implement cache directoriesDudemanguy2023-07-151-0/+9
| | | | | | | | | | | | 4502522a7aee093c923e79a65e4684ea2634af30 implemented cache directories but only on linux which meant other OSes continued to save this stuff in their config directory. Since we turned on cache by default, people are getting cache files in there which is understandably causing some confusion. Let's go ahead and implement a separate cache directory for windows since there seems to be some established conventions for this already. For people using the portable_path, the cache is saved in a subdirectory within the portable_path since the idea is for that to be completely self contained.
* path: do not use old_home for win32 exe dirwm42020-11-161-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | Apparently mpv supports loading config files from the same directory as the mpv.exe. This is a fallback of some sort. It used the old_home mechanism. I want to add a warning if old_home exists, but that would always show the warning on win32. Obviously we don't want that. Add a separate exe_dir entry to deal with that. Untested, but probably works. Mistakenly reverted as part of the default configuration directory location switch-back in aa18a8e1cde663caeabd93af7d57a745c1a76af6. Separation of the mpv executable directory from old_path is a good change now that we warn about the old_config directory also existing. Fixes #8232 Fixes #8244 Fixes #8262
* Revert "path: do not use old_home for win32 exe dir"Philip Langdale2020-10-161-1/+1
| | | | This reverts commit c3694f0acb7f71daac7606fafbadcb7b500ca35e.
* path: do not use old_home for win32 exe dirwm42020-06-251-1/+1
| | | | | | | | | | | | | Apparently mpv supports loading config files from the same directory as the mpv.exe. This is a fallback of some sort. It used the old_home mechanism. I want to add a warning if old_home exists, but that would always show the warning on win32. Obviously we don't want that. Add a separate exe_dir entry to deal with that. Untested, but probably works.
* win32: build with -DINITGUIDJames Ross-Gowan2016-09-281-1/+0
| | | | | | | | | | | | We always want to use __declspec(selectany) to declare GUIDs, but manually including <initguid.h> in every file that used GUIDs was error-prone. Since all <initguid.h> does is define INITGUID and include <guiddef.h>, we can remove all references to <initguid.h> and just compile with -DINITGUID to get the same effect. Also, this partially reverts 622bcb0 by re-adding libuuid.a to the build, since apparently some GUIDs (such as GUID_NULL) are not declared in the source file, even when INITGUID is set.
* Relicense some non-MPlayer source files to LGPL 2.1 or laterwm42016-01-191-7/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This covers source files which were added in mplayer2 and mpv times only, and where all code is covered by LGPL relicensing agreements. There are probably more files to which this applies, but I'm being conservative here. A file named ao_sdl.c exists in MPlayer too, but the mpv one is a complete rewrite, and was added some time after the original ao_sdl.c was removed. The same applies to vo_sdl.c, for which the SDL2 API is radically different in addition (MPlayer supports SDL 1.2 only). common.c contains only code written by me. But common.h is a strange case: although it originally was named mp_common.h and exists in MPlayer too, by now it contains only definitions written by uau and me. The exceptions are the CONTROL_ defines - thus not changing the license of common.h yet. codec_tags.c contained once large tables generated from MPlayer's codecs.conf, but all of these tables were removed. From demux_playlist.c I'm removing a code fragment from someone who was not asked; this probably could be done later (see commit 15dccc37). misc.c is a bit complicated to reason about (it was split off mplayer.c and thus contains random functions out of this file), but actually all functions have been added post-MPlayer. Except get_relative_time(), which was written by uau, but looks similar to 3 different versions of something similar in each of the Unix/win32/OSX timer source files. I'm not sure what that means in regards to copyright, so I've just moved it into another still-GPL source file for now. screenshot.c once had some minor parts of MPlayer's vf_screenshot.c, but they're all gone.
* path-win: include initguid.hKevin Mitchell2015-12-201-0/+1
| | | | cygwin was giving undefined reference to `FOLDERID_Desktop' at link time
* win32: path: use Known Folder IDsJames Ross-Gowan2015-12-201-7/+9
| | | | | | CSIDLs have been deprecated in Windows Vista and are not recommended for use in new code. They have been replaced with Known Folder IDs, which are pretty much the same thing, except they use GUIDs.
* win32: revert wchar_t changeswm42015-08-011-2/+2
| | | | | | | | | | | Revert "win32: more wchar_t -> WCHAR replacements" Revert "win32: replace wchar_t with WCHAR" Doing a "partial" port of this makes no sense anymore from my perspective. Revert the changes, as they're confusing without context, maintenance, and progress. These changes were a bit premature anyway, and might actually cause other issues (locale neutrality etc. as it was pointed out).
* win32: replace wchar_t with WCHARwm42015-07-291-2/+2
| | | | | | | | | | | | | WCHAR is more portable. While at least MinGW, Cygwin, and MSVC actually use 16 bit wchar_t, Midipix will have 32 bit wchar_t. In that context, using WCHAR instead is more portable. This affects only non-MinGW parts, so not all uses of wchar_t need to be changed. For example, terminal-win.c won't be used on Midipix at all. (Most of io.c won't either, so the search & replace here is more than necessary, but also not harmful.) (Midipix is not useable yet, so this is just preparation.)
* win32: add portable config modewm42015-07-271-9/+30
| | | | | | | | | | | See manpage additions. The main reason for adding this is that we can't guess whether the user wants his config in his Windows profile or not. The user basically has to tell mpv what should be done, and the "portable_config" directory does this implicitly. Fixes #2042 (approximately).
* path: make mp_path_join accept normal C stringswm42015-05-091-1/+1
| | | | | Instead of bstr. Most callers of this function do not need bstr. The bstr version of this function is now mp_path_join_bstr().
* win32: fix desktop directorywm42015-05-031-1/+1
| | | | The folder argument wasn't used, so it always returned the APPDATA dir.
* path: add resolving desktop path to platform-specific pathswm42015-05-011-2/+10
| | | | | | | | | win32 has a special function for this. I'm not sure about OSX - it seems ~/Desktop can be hardcoded, and the OSX GUI actually localizes the _displayed_ path in its UI. For Unix, there is not much to be done, or is there.
* path: refactorwm42015-05-011-9/+9
| | | | | | | | | | | | | | Somewhat less ifdeffery, higher flexibility. Now there are 3 separate config file resolvers for 3 platforms (unix, win, osx), and they can still interact with each other somewhat. For example, OSX for now uses most of Unix, but adds the OSX bundle path. This can be extended to resolve very specific platform paths, such as location of the desktop. Most of the Unix specific code moves to path-unix.c. The behavior should be the same - if not, it is likely a bug.
* win32: change config path prioritieswm42014-10-231-2/+2
| | | | | | | | | | | | | | | | | Assume mpv.exe is located in $mpv_exe_dir, then config files were preferably loaded from "$mpv_exe_dir/mpv". This was mostly traditional, and inherited from MPlayer times. Reverse the config path priority order, and prefer $CSIDL_APPDATA/mpv as main config path. This also fixes behavior when writing watch_later configs, and mpv is installed in a not-writable path. It's possible that this will cause regressions for some users, if the change in preference suddenly prefers stale config files (which may happen to longer around in the appdata config dir) over the user's proper config. Also explicitly document the behavior.
* config: use the same signature for win32/OSX specific path functionswm42014-06-261-1/+2
| | | | | | | | Seems like a good idea, even if it's basically unused (yet). Also document requirements on the functions (they're not obvious). OSX changes untested.
* config: make passing talloc context optional for some functionswm42014-06-261-7/+6
| | | | | | | | | | | | | | | | Until now, the config functions added various allocations to the user- provided talloc context. Make it so that they're all under the returned allocation instead. This allows avoiding having to create an extra temporary context for some callers, and also avoids adding random memory leaks by accidentally passing a NULL context. mp_find_all_config_files() has to be changed not to return a pointer into the middle array for this to work. Make it add paths in order (instead of reverse), and then reverse the array entries after that. Also remove the declarations for the win-specific private functions. Remove STRNULL(); it's barely needed anymore and the functions are not called with NULL filenames anymore.
* Basic xdg directory implementationKenneth Zhou2014-06-261-33/+26
| | | | | | | | | | Search $XDG_CONFIG_HOME and $XDG_CONFIG_DIRS for config files. This also negates the need to have separate user and global variants of mp_find_config_file() Closes #864, #109. Signed-off-by: wm4 <wm4@nowhere>
* win32: restore support for exe directory as config directoryelevengu2014-02-141-1/+5
| | | | | | | | Same rationale as b2c2fe7a but updated to work with path-win.c Signed-off-by: wm4 <wm4@nowhere> Merges/closes #543.
* Windows: use roaming AppData instead of localMartin Herkt2014-01-061-1/+1
| | | | Whatever. Fixes #458.
* Move options/config related files from mpvcore/ to options/wm42013-12-171-1/+1
| | | | | | | | | Since m_option.h and options.h are extremely often included, a lot of files have to be changed. Moving path.c/h to options/ is a bit questionable, but since this is mainly about access to config files (which are also handled in options/), it's probably ok.
* path, win32: redo user configfile path handlingwm42013-09-181-0/+74
Remove the ifdef hell from mp_find_user_config_file(). Move the win32 specific code (for MinGW and Cygwin) to path-win.c. The behavior should be about the same, but I can't be sure due to lack of testing and because the old path.c code was hard to follow. (I expect those who care about windows will fix things, should issues pop up - sorry.) One difference is that the new code will always force MPV_HOME. It looks like the old code preferred the mpv config dir in the exe dir if it exists. Also, make sure MP_PATH_MAX has enough space, even if the equivalent wchar_t string is not 0-terminated with PATH_MAX (because apparently the winapi doesn't require this). (Actually, maybe we should just kill all uses of PATH_MAX/MP_PATH_MAX.)
generated by cgit v1.2.3 (git 2.25.1) at 2024-05-02 17:43:52 +0000