windows

[续]Win10 + WSL编译FFmpeg开启openssl依赖时的坑

之前写过一篇基于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…

Windows的符号链接SymbolicLink(快捷方式)在网络共享访问时的跟随跳转问题

这个问题发现于这么一种操作,首先是用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…

使用Win10 + WSL编译FFmpeg时的依赖库处理

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账户在Win7系统无法登录的解决办法

问题情况如题所述,之前买过Office 365的账号用在Windows 7系统上时一直没什么问题,直到最先有一天突然提示账号登录失败,然后全套Office程序就都无法使用了,查看了下是账号无法正常登录导致的,一直提示“很抱歉,遇到一些临时服务器问题”,如下:

百度了很多方法,什么清注册表的,改DNS的,重新安装的,甚至是使用魔法的,统统不管用,最后找到了这篇简书上的参考:https://www.jianshu.com/p/9a37cca37374,才意识到原来是Win7系统上的https兼容问题(也有可能不是Win7而是这个365登录网站的问题吧,反正在Win10上没遇到过这种情况),于是…

Continue reading…

解决Windows 10 1903下IPv6地址无法ping通问题

最近发现宽带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就能通了,特此记录,以备后需。

Windows 10 1903更新后RDP远程桌面黑屏卡死问题的临时解决方法

最近发现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…

Phabricator的arcanist在windows下执行arc feature(branch)异常问题的hack修正方法

首先,发现问题的arcanist版本如下:

arc version
arcanist d92fa96366c0ed50e4257508148aa75192d4fb1f (20 Jun 2019)
libphutil b416093386a225b1d9a2de906899b94cbf4babcb (8 Jul 2019)

错误现象为执行arc featurearc 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.
Continue reading…

64位Unity集成亲加(gotye)即时通讯SDK时的editor动态库设置DllNotFoundException

最近在测试亲加的语音聊天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)

Continue reading…

从Win8.1升级到Win10后WOL网络唤醒失效的解决方法

之前的Win10各种预览版泄漏版的,虽然也有下过的但一直没来得及安装,最近Win10正式版发布了,而且符合条件的Win7、Win8Win8.1等都收到了更新推送,终于还是强迫症发作,点了下载更新到Win10,更新过程很顺利,但是还没来得及体验就发现了问题:升级之前Win8.1下没问题的WOL网络唤醒功能不能用了!
一度怀疑是路由器上的唤醒设置出错了,但转念一想最近也没修改过设置…后来在关掉Win10后仔细观察了下路由器上的LAN口提示灯发现:原本会有一个低速待机状态的连接提示现在没有了!本来开机的时候是千兆连接的提示灯,关机时是100/10速度连接的提示灯,也就是网卡并没有完全关闭,这是受到唤醒广播包时是可以顺利开机的,而现在连接提示灯是完全熄灭的!
于是开始找原因,发现果然有很多类似案例,升级Win10后WOL不能用了,但大部分是说从Win7升级后出现的,解决方法有关闭“快速启动”、睡眠关机等等,想想我又不是从Win7升级的,解释之前那些解决方法的原因是说Win8以后关机状态的电源模式从S4改成了S5什么的(没记错的话),所以影响了WOL功能。但我升级前在Win8.1下WOL是完全正常的,也没改过什么快速启动等等的设置。最后在远景论坛上看到有人说是Win10更新的“最新驱动”问题,恍然大悟,看了下设备管理器里网卡驱动被更新成了15年4月的一个版本,于是找回主板原配驱动,更新了回去:
QQ截图20150806223752
再次关机,LAN指示灯恢复了低速待机状态,尝试WOL唤醒成功!

在Windows下删除Mac系统硬盘中的200mb EFI分区

把一块曾经装过Mac系统的硬盘挂到Win上用,在设备管理中可以删除默认200mb EFI分区以外的其他分区,虽然这200mb也不算多,但看着还是别扭,查了下发现可以通过如下操作进行删除

打开cmd命令行,运行命令diskpart,进入提示符后先执行list disk,然后看下显示出得列表中哪个编号的硬盘是这个包含EFI分区的,然后执行 select disk N,把N替换为刚才查到的对应磁盘的索引号,选中磁盘后,执行clean,清除掉整个磁盘的分区,然后再次打开磁盘管理工具,会提示进行初始化操作,选MBR还是GPT,选好后就可以使用完整硬盘空间了!