
不知什么时候开始(严重怀疑是某次Windows 11更新后),OneDrive在“此电脑”中突然出现了两个一摸一样的快捷链接图标,虽然我基本也不怎么用MS的这个网盘吧,但每次打开我的电脑都看到这么个神奇的存在,着实有点碍眼,于是决定“处理”一下这个问题。
Continue reading…欢迎留言、转载请注明出处

不知什么时候开始(严重怀疑是某次Windows 11更新后),OneDrive在“此电脑”中突然出现了两个一摸一样的快捷链接图标,虽然我基本也不怎么用MS的这个网盘吧,但每次打开我的电脑都看到这么个神奇的存在,着实有点碍眼,于是决定“处理”一下这个问题。
Continue reading…
最近趁着国补+以旧换新优惠,更新了下显示器,换掉了用了8年的傻多戴U2518DR(现在看当年真的是傻多了,2500的价格,只为一个2k,没有高刷,所谓的HDR还是个假的) ,改投了国产泰坦军团的高性价比型号P275MV PLUS。4K 160HZ,1080 320HZ双模切换,Mini LED 1152分区HDR1000,还带TYPE-C PD 65W快充和USB集线器,光感自动亮度,内置音箱等功能,可以看到这8年显示器技术有了多大的提升,可以说是鸟枪换了炮。其实这款型号当初刚上的时候就关注到了,那时本来想买败家之眼XG27UCG,但刚需PD快充一直没下手,同时泰坦这款上市后价位和UCG差不多,对于国产品牌来说感觉还是有点贵。但这不最近国补一上,性价比就出来了,以旧换新出了Dell后也就1000出头,没啥好说的,果断换了!
这次记录的是换后折腾高刷,Windows 11 DRR(动态刷新率),DSC(Display Stream Compression),G-Sync(VRR,对应到这款显示器的是Adaptive Sync技术)的一些总结:
Continue reading…之前写过一篇基于WSL编译windows版FFmpeg的博文:使用Win10 + WSL编译FFmpeg时的依赖库处理 – https://blog.k-res.net/archives/2771.html,记录了一些基本构建操作和一些问题,但是当时的configure并没有开启很多其他依赖项来激活相关功能,这次要记录的是通过开启openssl的方式,增加如https,rtmps等协议的支持,虽然有WSL的加持,大大简化了windows下编译FFmpeg的复杂度,但到了某些依赖,如这次要说的openssl时,还是有些需要注意的地方的,毕竟WSL的方式实际的本质是在一个同时有linux命令但又能执行windows执行程序的特殊环境下执行构建操作,带来方便的同时也带来了一些特有的麻烦:
Continue reading…这个问题发现于这么一种操作,首先是用Powershell脚本进行快捷方式(SymbolicLink)创建:
New-Item -ItemType SymbolicLink -Path d:\share_folder\ -Name latest -Target d:\share_folder\v1000 -Force
此命令在d:\share_folder文件夹中创建名叫latest的快捷方式,并指向同级文件夹中的v1000目录,然后将share_folder开启网络共享,从另一台机器通过 \\xxx.xxx.xxx.xxx\share_folder方式访问这个快捷方式latest时,发现会提示:“无法遵循符号链接,因为其类型已禁用”的错误信息,百度一下,查到原因,参考:Windows 挂载磁盘错误 ‘无法遵循符号链接,因为其类型已禁用’ 解决方案 https://www.zywvvd.com/notes/system/windows/symlink-disabled/symlink-disabled/
原来Windows默认对符号链接的跟随跳转仅限本地,远程到本地(共享里的快捷方式指的本地路径),远程到远程(共享里的快捷方式指的是另外的共享路径)都是禁止的,于是参考上面的解决方案,fsutil behavior set SymlinkEvaluation R2L:1 打开远程到本地的遵循,结果再次访问时发现提示目标文件夹不存在!
Continue reading…Windows 10的Linux子系统WSL安装过程就不做赘述了,网上资料很多。
之前一直认为WSL只是以类似虚拟机或容器化的方式使得能在Windows上运行原生Linux程序,当然,也在WSL上做过如使用ndk交叉编译Android原生程序、动态库的操作,用起来还是挺方便的。直到最近研究FFmpeg的Windows版编译时才发现(参考自:https://www.bilibili.com/read/cv7058269/),原来WSL还有一个“大杀招”:直接运行Windows执行程序exe,如下图所示:

可以看到,在WSL内直接执行VS 2019的编译器程序cl,也是完全没有问题的,基于这种方法,FFmpeg官网上所说的用cygwin,mingw,msys之类的桥接环境构建Win版FFmpeg的麻烦就不复存在了,而且新版FFmpeg源码(博主用的4.3)的configure也做好了对这种编译方式的支持,参考上面的链接,制定上toolchain=msvc等相关参数,剩下的事和nix系统上构建一样就可以顺利完成了,简单方便!
不过,今天要记录的并不是WSL下编译Win版FFmpeg的问题,而是编译时如何引入其它依赖,如openssl,xml2等以获取更多功能支持,尤其是在Win环境下,这些其它依赖库的位置很有可能是一个很随意的位置,而在WSL环境下处理这种依赖的头文件、库文件搜索路径时是有坑的…
Continue reading…问题情况如题所述,之前买过Office 365的账号用在Windows 7系统上时一直没什么问题,直到最先有一天突然提示账号登录失败,然后全套Office程序就都无法使用了,查看了下是账号无法正常登录导致的,一直提示“很抱歉,遇到一些临时服务器问题”,如下:

百度了很多方法,什么清注册表的,改DNS的,重新安装的,甚至是使用魔法的,统统不管用,最后找到了这篇简书上的参考:https://www.jianshu.com/p/9a37cca37374,才意识到原来是Win7系统上的https兼容问题(也有可能不是Win7而是这个365登录网站的问题吧,反正在Win10上没遇到过这种情况),于是…
Continue reading…最近发现宽带IPv6通了, https://ipv6-test.com 测试可以正确检测出公网IPv6地址(检测到的是Win10 DHCP出来的临时地址),但是又发现ICMP一直不通,于是找了个也有v6地址的朋友帮忙测试一下,发现果然是ping不通,但是连接功能正常,于是想到是系统自带防火墙(Win10 1903,不确定其它版本是否也有此问题…)的问题,结果在防火墙设置里怎么都改不好,后来在microsoft官方上看到了这个: https://answers.microsoft.com/en-us/windows/forum/windows_10-networking/windows-10-firewall-filtering-icmp/527551d0-e477-4dd6-a0a0-eae724940ba3 ,于是照做:
netsh firewall set icmpsetting type=all mode=enable
完事后再测,ICMPv6就能通了,特此记录,以备后需。
最近发现Win10推送了1903更新,迫不及待的装上后还没来得及体验各种变化就发现了一个令人恼火的bug,用远程桌面RDP连接1903版Win10时会出现黑屏卡死的问题!具体状态是RDP服务器是一台CPU比较旧的电脑(G1610 B75 GPU为核显),更新1903之前没任何问题,更新1903后用另一台1903的Win10自带的RDP客户端连接,第一次可以正常连接,断开再重连就必出现黑屏卡死的问题!(同时测试了Android、iOS、Mac OSX上的微软官方RDP客户端连,不会出现卡死的问题!)。搜索了下发现微软官方已经确认了这个问题: https://docs.microsoft.com/en-us/windows/release-information/status-windows-10-1903#534msgdesc ,而目前的状态还是 Investigating ,没有解决方法。
Continue reading…首先,发现问题的arcanist版本如下:
arc version
arcanist d92fa96366c0ed50e4257508148aa75192d4fb1f (20 Jun 2019)
libphutil b416093386a225b1d9a2de906899b94cbf4babcb (8 Jul 2019)
错误现象为执行arc feature或arc branch时,提示:
[2019-07-20 13:30:05] ERROR 8: Undefined offset: 1 at [D:\phabricator\arcanist\src\repository\api\ArcanistGitAPI.php:1094]
arcanist(head=master, ref.master=d92fa96366c0), phutil(head=master, ref.master=b416093386a2)
#0 ArcanistGitAPI::getAllBranches() called at [<arcanist>\src\workflow\ArcanistFeatureWorkflow.php:89]
#1 ArcanistFeatureWorkflow::run() called at [<arcanist>\scripts\arcanist.php:394]
[2019-07-20 13:30:05] ERROR 8: Undefined offset: 2 at [D:\phabricator\arcanist\src\repository\api\ArcanistGitAPI.php:1094]
arcanist(head=master, ref.master=d92fa96366c0), phutil(head=master, ref.master=b416093386a2)
#0 ArcanistGitAPI::getAllBranches() called at [<arcanist>\src\workflow\ArcanistFeatureWorkflow.php:89]
#1 ArcanistFeatureWorkflow::run() called at [<arcanist>\scripts\arcanist.php:394]
[2019-07-20 13:30:05] ERROR 8: Undefined offset: 3 at [D:\phabricator\arcanist\src\repository\api\ArcanistGitAPI.php:1094]
arcanist(head=master, ref.master=d92fa96366c0), phutil(head=master, ref.master=b416093386a2)
#0 ArcanistGitAPI::getAllBranches() called at [<arcanist>\src\workflow\ArcanistFeatureWorkflow.php:89]
#1 ArcanistFeatureWorkflow::run() called at [<arcanist>\scripts\arcanist.php:394]
[2019-07-20 13:30:05] ERROR 8: Undefined offset: 4 at [D:\phabricator\arcanist\src\repository\api\ArcanistGitAPI.php:1094]
arcanist(head=master, ref.master=d92fa96366c0), phutil(head=master, ref.master=b416093386a2)
#0 ArcanistGitAPI::getAllBranches() called at [<arcanist>\src\workflow\ArcanistFeatureWorkflow.php:89]
#1 ArcanistFeatureWorkflow::run() called at [<arcanist>\scripts\arcanist.php:394]
[2019-07-20 13:30:05] ERROR 8: Undefined offset: 5 at [D:\phabricator\arcanist\src\repository\api\ArcanistGitAPI.php:1094]
arcanist(head=master, ref.master=d92fa96366c0), phutil(head=master, ref.master=b416093386a2)
#0 ArcanistGitAPI::getAllBranches() called at [<arcanist>\src\workflow\ArcanistFeatureWorkflow.php:89]
#1 ArcanistFeatureWorkflow::run() called at [<arcanist>\scripts\arcanist.php:394]
Usage Exception: No branches in this working copy.
最近在测试亲加的语音聊天SDK(版本:gotyeapi_ex_v3.0_20170121_u3d.zip),由于直接提供了Unity版本的插件实现,简化了用Unity引擎开发的App集成时的难度,尤其还提供了Windows平台的实现,可在Editor环境下直接测试大部分功能,这是大部分平台相关SDK所不具备的!在实际测试中,发现了一些官方文档中没有说明的小问题,特记录于此。
首先,下载的zip并没有像官方文档中描述的一样,只有一个unitypackage,这点影响不大,直接解开zip中的内容,复制所有cs文件到项目中即可,后面根据官方文档上的指引,windows平台需要将对应32位或64位版本的Plugins中的dll复制到Unity安装路径的Editor下,也就是Unity编辑器执行文件所在的位置。这点要注意并不是常规的项目中的Plugins路径!操作完成后,项目中加入初始化代码,然后运行,出现了官方文档中提到的“win64下的U3D的DLL找不到”的问题:
DllNotFoundException: gotyeapi
gotye.GotyeAPI..ctor () (at Assets/gotye/GotyeAPI.cs:52)
(wrapper remoting-invoke-with-check) gotye.GotyeAPI:.ctor ()
gotye.GotyeAPI.GetInstance () (at Assets/gotye/GotyeAPI.cs:122)