千城真人✨的个人资料

Laxuhub v1.0 绿色多计算机语言开发环境快速切换和管理工具绿色多计算机语言开发环境快速切换和管理工具解压即用，建议D盘根目录，结构D:\Laxuhub。如果装在别的目录，首次启动选中的python版本后，运行pipreset.bat重置pip 或pipsafeup.bat更新并重置内有说明文档。用途： python,nodejs,go,java等语言的学习，教学，轻运维。绿色便携，开包即用，按格式修改json文件可随意扩充新的语言环境下载地址 http://tieba.baidu.com/mo/q/checkurl?url=https%3A%2F%2Fgithub.com%2Fashi876%2FLaxuhub%2Freleases%2Fdownload%2Fv1.0.0%2FLaxuhub20250912.7z&urlrefer=8614d4b0b0fe8f1715743824b1c2c1f6 上不了github可以用http://tieba.baidu.com/mo/q/checkurl?url=https%3A%2F%2Fgh-proxy.com%2F&urlrefer=9a498129849e489420a356f6d9c50be2镜像下载通过网盘分享的文件：Laxuhub20250912.7z 链接: http://tieba.baidu.com/mo/q/checkurl?url=https%3A%2F%2Fpan.baidu.com%2Fs%2F1pECXVQ7nqd2dLexDTzmB1g%3Fpwd%3Dwd4k&urlrefer=4c94a83b66d7a257272702ff4d49d3b1 提取码: wd4k 复制这段内容后打开百度网盘手机App，操作更方便哦

test 1 test

foobar最新版的dsp快捷调用真是方便极了好久没更新了，今天用上了1.6.2版 dsp终于变成了我希望的样子，甚至比我想到的还要更好这功能真的盼了好多年了

很好用的版本ltsc2019企业办公版很喜欢吻妻的这个作品，没有乱七八糟的精简本就是ltsc，有些版本精简的太厉害，不知道啥时候就不能用了。集成的四个软件，office基本上必要的，另外三个不喜欢也可以很方便的删除该要的库都集成了，运行老游戏都很正常删除的项目也都作了说明：原生无应用商店、小娜、OneDrive、Edge浏览器移除SmartScreen 筛选器、Windows 安全中心移除Xbox及其相关组件移除零售演示内容和绝大部分可选功能

[科普]MinGW vs MinGW-W64及其它幻之帝球发的原，贴好象被删掉了这是一篇介绍mingw,mingw64_gcc的扫盲贴，git有原文链接 http://tieba.baidu.com/mo/q/checkurl?url=https%3A%2F%2Fgithub.com%2FFrankHB%2Fpl-docs%2Fblob%2Fmaster%2Fzh-CN%2Fmingw-vs-mingw-v64.md&urlrefer=72da00b51bdf90b6107140895fc00117 [科普][FAQ]MinGW vs MinGW-W64及其它　　部分参照备忘录原文。　　试试问答体。首先得绕个远路，从 Win32 开始说起，否则之后容易乱…… 什么是 Win32 ？　　嘛，32 自然是指 32 位了？不一定。　　正式地说， Win32 主要是指跑在 Windows NT 内核上的 Win32 子系统。现在 x64 的 Windows 上的大部分程序也是跑在这个子系统上的，system32 目录也没叫成 system64 。　　尽管 32 的语源的确来自于“32 位”。那么为什么还有 Win64 ？　　这倒可以肯定，这里的 64 是指 64 位目标平台，因为没有上面的那种歧义。　　有一点值得注意，在 MSVC 中， 32 位环境（当然是说跑的 Intel 兼容CPU的PC）预定义宏 _WIN32 ，但 64 位环境同时预定义了 _WIN32 和 _WIN64 。　　顺便，通常 64 位主要指 x86_64 （微软称为 AMD64 ，这个兼容 x86 的基础架构一开始的确是AMD先搞出来的，后来才有 Intel EM64T ）。　　64 位 Itanium 也有 _WIN64 ，不过一般见不到且跟MinGW没什么关系且现在都不正式支持了，不管了…… 　　对于 MinGW 来说，这里也有类似的坑：预定义宏得先优先检查 64 位的。实际情况更加复杂，另说。 MinGW 和 MinGW-W64 有什么区别？　　这是个关键问题，但是……是个很长的故事。没有铺垫不好回答。　　首先， MinGW 是 GNU 工具（包括编译器 GCC 和 GNU binutils 和调试器 GDB 等）在 Win32 上的一个移植，是从 Cygwin 里 fork 出来的。当初只考虑 32 位。和 Cygwin 相比，不强调 POSIX 兼容性而相对强调性能和减小依赖。　　具体来说 MinGW 除了以上工具外，还提供了一个适配于 Win32 的运行时环境。其中 C 标准库实现的二进制文件直接用微软随 Windows 分发的 MSVCRT 。 MinGW 自己的运行时库依赖于MSVCRT和其它系统库。　　而 MinGW GCC 依赖于 MinGW 运行时以及 libgcc 和其它系统库。编译出来的程序一般也要依赖这些库，所以才会写死在默认 specs 里（可以用 gcc -dumpspecs 查看）免得用户随便编译链接个程序还得手动指定一大堆 -l 选项。　　用三元组表示目标平台，当年的 MinGW 是指 i386-pc-mingw32 。这里 i386 也可以是 i486 等等……总之是 32 位 x86 指令集架构的名称；中间的 pc 可选，表示厂商名； mingw32 表示系统名。特别注意，事实上成为标准的“专有名词” mingw32 里的 32 是固定的；另外，所有这些大小写一般也是固定的。 GCC 等的源码配置里面也有硬编码进去。　　然后，因为只支持 32 位，有人觉得不够用。这里的一个主要人物，就是现在 MinGW-W64 的主要维护者 Kai Tietz 。因为工作需要重新实现提供 x64 支持的 MinGW 后提交到上游但被拒绝，于是 fork 为单独的项目，这就是 MinGW-W64 的由来。　　可见， MinGW-W64 和原版 MinGW 有所渊源，但是独立的两个项目。　　W64 虽然用意是Win64，但是也算是个专有名词，在三元组里占据厂商名，例如常见的：i686-w64-mingw32。（在GCC源码的配置文件中， *-w64-mingw32 和 *-pc-mingw32 是分别对待的。）　　MinGW-W64 是同时支持 32 位和 64 位的，甚至还支持 32 位和 64 位的交叉编译（启用 multilib 支持的 MinGW 发行版例如 mingw-builds 可以用 -m32 或 -m64 指定）。　　显然， W64 和支持的架构无关。上面 i686 就不是 64 位的平台（而且可以看出这里的 32 也和架构没关系）。支持 64 为的对应三元组是x86_64-w64-mingw32。（另外 w32 是 GNU 惯用的对 Win32 的略称，也沿用到包括 MinGW 在内的一些项目中——如 w32api ，可能造成一些额外的混乱。）　　……容易让人头疼的是，这两个项目现在都没死，偏偏还很容易因为这些字面上的原因搞错。为了下文描述方便，原版 MinGW 称为 MinGW.org 。　　这里有一点非常重要：只有 MinGW-W64 是 GCC 官方支持的（尽管 mingw32 平台是二等公民）。在很长一段时间内 Kai Tietz 拥有 GCC 官方 repo 的提交权限（虽然当前已不再活跃而被移除）。　　所以，使用 MinGW-W64 的 GCC 一般比 MinGW.org 有更新更全面的支持，所以现在一般推荐 MinGW-W64 发行版。　　说到这里……维护 mingw.org 的 Keith Marshall 还和 Kai Tietz 等GCC官方人员在 bugzilla 上对噗过。其中 Keith Marshall 对 MinGW-W64 使用 MinGW 一名造成混淆表示愤慨。嘛，这倒也是事实。　　当然，也不是说 MinGW.org 就一无是处了。 *-w64-mingw32 原则上向后兼容 *-pc-mingw32 ，不过也有一些接口上的差别。 BSD 流的 DT_* 在 MinGW.org 上能用，在 MinGW-W64 的就没有。（虽然 DT_* 也不怎么推荐用就是了……）什么是 MinGW 发行版(distribution) ？　　这个说法习惯上可以说是从 Linux 等软件中借用过来的。　　类似 Linux 内核，不管 MinGW.org 还是 MinGW-W64 ，本身都是相对集中于特定软件包（ MinGW 运行时库）开发的项目，并不着力于提供整个开箱即用的环境。　　因此除了官方的一些编译版本外，有很多人基于 MinGW 运行时上进行定制封装供用户下载整个环境，有的还提供包管理服务等。这就是发行版。一般提供直接解压加上 PATH 就能用的环境和/或安装包。　　早期比较著名的有 TDM-GCC 、 rubenvb 等。以前用的 MinGW.org ，不过现在主要转到 MinGW-W64 上来了。　　比较新的发行版，一开始就着眼于 MinGW-W64 。最著名的发行版之一应该是 mingw-builds ，基本上近年来（ GCC4.7 以后） Windows 上能用支持最新版本最快的，支持交叉编译。　　mingw-builds 一开始在 sf.net 上有自己的项目，不过后来表示要求加入 MinGW-W64项目作为 official builds ，所以停更了，更新都在 MinGW-W64 里面，不过残念的是好像到现在 MinGW-W64 看来都不提供唯一的官方发行版，所以还是叫做 personal builds 。　　另外提一下还有微软 VC++ 标准库（ Dinkumware 生产）维护者之一 Mr.STL(Stephan T. Lavavej) 个人的发行版，很早就在默认 specs 里加了 -std=c++11 ，而GCC 5 改用 -std=c++14 。（官方 GCC 6 会用 -std=gnu++14 。）　　还有 MSYS2 项目的 MinGW 发行版（这里可能有新的混乱，下文再说），也是 mingw-builds 一伙人搞的， 4.9.1 比 mingw-builds 更新还快几个小时。　　详细的发行版列表可以参照下文。　　最后，不嫌闲着**也可以自己编译。不过迫不得已外最好别这样做（ GCC 的编译过程和 hacking 实在无力吐槽）。重复一遍，非常不推荐。有哪些发行版可以选择？本机环境（直接在 Windows 下运行） MinGW-w64 提供若干工具链的下载 mingw-builds 旧站点 MSYS2 （使用包管理器 pacman 安装 mingw-w64-i686-toolchain 或 mingw-w64-x86_64-toolchain） TDM-GCC nuwen.net MinGW distro 仅提供 Win32 线程模型 GCC-MCF 仅提供 MCF 实现交叉构建环境 Arch Linux MinGW-w64 GCC MSYS2 （使用包管理器 pacman 安装 mingw-w64-cross-toolchain） MinGW 发行版支持什么本机语言编译器？　　对于 C/C++ ，主要是 GCC 。 GCC 也提供 FORTRAN 和 Ada 等语言的编译器。　　除此之外，某些发行版（如 MSYS2 的 MinGW 环境）也带有兼容的 LLVM/Clang 工具链，但可用性差强人意；其中标准库实现仍然依赖 GCC 的 libstdc++ ，而不是 libc++ 。但一些可能提供的 Clang 附带的工具（如 clang-format ）可用性基本不受限制。上面为什么要强调更新呢？　　如果不想使用新的特性生成更高质量的代码，其实也没必要盯着上面这么多版本混乱的 MinGW 了。即便要兼容性，也可以用古董嘛（逃…… 　　对于 C++ 前端来说 MinGW 尤为重要，现阶段根本没有能顶替的。作为系统默认 ABI 新锐代表的 MSVC2015 Update n ——前端还是残的……各种 bug 。　　GCC 也有各种傻缺 bug ，不过至少在前端来说，程度上绝逼打不过 cl （ Microsoft C&C++ Optimizing Compiler ）。　　VC++ 调试支持当然好得多，但是编译器一坑爹集成调试再好也没用了。　　嘛， Clang++ ？ libc++ 什么时候能在 Windows 上跑顺再说——即便这样 MinGW 兼容的还是得依赖 MinGW 的 libgcc 。至于和 VC++ 兼容的 clang-cl ，看起来还在折腾微软的坑爹ABI黑箱（这没像大部分平台上 GCC 用的 Itanium ABI 公开文档），一年半载别指望了。什么是异常模型和线程模型，用哪种比较好？　　这两个都是对于 C++ 实现（ G++ 、 libgcc 、 libsup++ 等等）而言的。　　首先，异常模型。 C++ 标准没规定异常怎么实现。 MinGW GCC 使用的 Itanium ABI 也没规定必须怎么实现（但规定了一些公共接口），这部分由实现自行考虑。　　GCC 一般提供了 SjLj （ C 的 setjmp/longjmp ）实现的 stub 。对于 x86 ，允许使用 Dwarf2 调试信息的实现。两者的区别在于 sjlj 比较通用，但是即便不抛出捕获异常而只是使用异常中立的风格隐式传递异常，也有运行时开销。而 Dwarf2 兼容性（考虑多层 C++ 和 C 的 DLL 互相调用来看）相对较差，但没有这种开销。　　两者 ABI 并不兼容（知道 C++ 坑爹了吧，不仅不同实现不兼容，同一个编译器同一个平台自己都能跟自己不兼容……）——前者依赖类似 libgcc_s_sjlj.dll 这样的 DLL ，后者则是类似 libgcc_s_dw2.dll 这样的。旧一点的可能也没有这种后缀差异。　　另外， libstdc++ 作为 C++ 标准库实现显然依赖异常，但名字一样的 DLL 可能依赖的不是同一种。所以混用多个版本 MinGW GCC 且没把 PATH 清理干净的时候容易出现找不到符号定义导致链接失败。这还不是最坑的，有时候 gdb 载入不同位置的 DLL 在运行时挂掉，还不只是一个 PATH 的问题……这种情况下先拿 Sysinternals 的 Process Exporler 之类的工具看看进程加载的 DLL 是不是预期的再说。　　为什么说要有这么坑爹不兼容的，像 VC++ 一样用一种不就好了……其实 Win32 x86 上最理想的应该是和 VC++ 一样基于 SEH （ Windows 结构化异常处理）的实现，但是 Borland 关于这个的专利才没过期几天……所以你懂的。　　x64 上没专利的麻烦，有 SjLj 和 SEH 的实现，一般还是 SEH 。　　第二，线程模型。　　主要有两个， Win32 和 POSIX ，对标准库线程的支持不一样。　　Windows 线程 API 和 POSIX(pthread) 有很大不同，而 ISO C++ 的 std::thread 为代表的接口是很接近 pthread 的。　　所以在 libstdc++ 上实现这些接口，首先依赖的是 pthread 在 Win32 上的移植 libwinpthread ，也就是使用 POSIX 线程模型。因此发布的时候需要带上 libwinpthread-1.dll 之类的dll。　　至于 Win32 线程模型， GCC mailing list 是有提过，不过到现在还是没实现。也就是说 ISO C++ 的实现是残的，没法用。如果只打算用 Win32 多线程 API 倒是的可以用。　　所以取决于具体需要。要兼容性好点的一般还是 POSIX 。　　最近有新的基于 mcfgthread 实现的 MCF 线程模型可以替代 POSIX 线程模型，在 Windows 7 和更新的系统有较好的性能。　　最后，还有单线程的 single 模型…… Windows 上应该没啥必要用。什么是 MSYS ，和 MinGW 有什么区别？　　MSYS(minimal system) 原本是 MinGW.org 项目的一个组件，旨在 Windows 上提供一套类 UNIX shell 为基础的“系统”。它本身不提供编译器或者大小写敏感的文件系统支持（其实 NTFS 倒是支持这里的“ POSIX 语义”，但基本没看见有谁用……）。　　和作为原生 Win32 程序的 MinGW 不同， MSYS 环境下编译的本机程序依赖于额外的特定的 MSYS 运行时，更接近 Cygwin （强调 POSIX 兼容性），会有性能损失（但一般意义上比 Cygwin 轻量）。对应的三元组是 *-pc-msys （通常其中的 pc 可以省略即缩写为 *-msys ）。 MSYS 提供了一个 sysroot 环境（下面有 /bin 和 /etc 等），因此移植 POSIX 环境的程序一般更方便。　　所以常规的实践是，如果只是开发 Windows 程序，能用 MinGW 就不要用 MSYS 原生的编译器来构建。当然，使用 MSYS 上的 sh 等工具还是没问题，跟 GNU 工具配套怎么说比 cmd 好用。（虽然也有不少琐碎的兼容性问题。）什么是 MSYS2 ， MSYS2 上的 MinGW 发行版是怎么回事？　　字面意思，MSYS 2.0 。比起 1.0 来说更加像 Cygwin （例如 /etc/fstab 配置）。项目在 sf.net 上托管。　　其中的一个特色是基础系统附带 ArchLinux 移植的包管理器pacman，可以同时独立部署 /mingw32 (i686-w64-mingw32) 和 /mingw64(x86_64-w64-mingw32) 下的开发和运行环境。注意和 mingw64 并列时 mingw32 自然指的不只是三元组的最后一项了。　　下载依赖相当方便（就是没有靠谱的镜像时网速可能非常拙计）。具体使用参考 Arch Linux Wiki。对应的交叉编译环境在 Arch Linux 上也有官方的包支持。　　虽然 MSYS2 提供的 MinGW 上主要的编译器不直接支持交叉编译，不过可以同时装不同的目标平台的编译器（现在也有交叉编译器的包，没测试）所以不是什么问题，一定程度上比 mingw-builds 的 -m32 和 -m64 来说更加稳定靠谱。（现在也另外提供支持交叉编译的包。）　　只提供 Dwarf2 异常模型和 POSIX 线程模型对于成套系统也不是什么大问题。包虽然比不上 ArchLinux 那么丰富不过常用的很多都有，免去自己编译的麻烦。打算长期使用 MinGW 和相关工具的，推荐使用。　　　虽然滚挂了也没多大事，不过版本是个问题。如果需要特定版本的 GCC 就不适用（比如规避GCC 4.9的坑爹bug……），除非有耐心自己找到 .xz 手动安装。　　相关配置（包括 pacman 的一些中国大陆镜像）可以看这里。部署程序需要提供哪些文件？　　Windows 默认安装自然不带 MinGW 运行时环境，所以除了编译出来的程序和可能附带的数据，一些dll是要准备好的——除非有耐心折腾全部静态链接。　　不同版本不同语言不同编译器编译出来的东西都不太一样。最简单暴力也可靠（？）的方法就是复制可执行程序到没装环境的白板测试机上看少了哪些东西（不过未必一目了然）。　　简单可靠的方式是用 Dependency Walker 等工具查看依赖。　　对于 C++ 程序，除非不用 POSIX thread 可以省掉 libwinpthread ，一般至少得确保上面异常模型和线程模型讨论中提到的三个 DLL （注意就算不显式使用标准库，编译器生成的代码也可能用到——典型的如默认 ::operator new ，所以得带上 libstdc++ ）。　　使用 MCF 线程模型需要部署对应的 mcfgthread 动态库（如 mcfgthread-9.dll ）。还有什么其它问题？LTO 　　GCC 4.9的 LTO （链接时优化）默认使用新的目标文件格式，生成的文件不包含冗余的二进制代码。但是 LTO 有特定的 phase （内部会调用 make 多编译几个 pass ），传统的静态链接器(ar) 不知道这里的约定，所以原来好好的东西，升级 4.9 以后开了 -flto 就可能找不到符号链接失败。　　许多 MinGW 发行版仍然没实现 gcc-ar （运行会提示没支持 linker plugin ）。兼容旧版本的行为还得加上 -ffat-lto-objects 编译选项。　　较新版本可能解决了这个问题。　　此外，内联 vtable 开启 LTO 导致链接失败。此时应保证非内联的虚函数，使 vtable 在特定翻译单元内生成；这样也有利于编译性能。

一款不错的代码编辑器cudatext 先上图

很不想在本吧谈正制，关于np++ 一切的开始都从二楼说起这个贴子的起因是因为有些朋友出于高尚的爱国主义情操一再私聊我一些关于np++的事

目前几个mingw64-gcc的发行版状况 MinGW Distro - nuwen.net把gcc更新到9.2.0了，当然了还有系列的扩展库，详细可以去其网站上看看。（据这家伙说被老婆缠住了所以一年都没空更新） builts小组的更新我估计以后可能不会有了现在推荐的几个版本最推荐的当然是msys2，更新方便，库依赖也全部帮你搞定。其次是http://tieba.baidu.com/mo/q/checkurl?url=https%3A%2F%2Fgcc-mcf.lhmouse.com%2F&urlrefer=1e76b9e44605d8187f17bfff268fbb96的版本，更新快下载速度也快。而Distro - nuwen作为一个老牌的个人发行版还是很可靠的。 http://tieba.baidu.com/mo/q/checkurl?url=http%3A%2F%2Fwww.equation.com&urlrefer=4908dbf20f500208030c175dce233410的版本更新很快，但是下载速度在我这实在是不靠谱。

很多人喜欢的tinyc 有些人会误以为这个东西不更新了。米迦尔这次憋了个大招

每周一次吐槽说好的指定二吧三吧功能没了，郁闷。度娘这个每周一贴的规定更郁闷集成包编译环境镇楼图：

msys2终于更新到了9.1gcc了 builts小组好久没更新了，我也一直认为msys2更方便点有很多静态库还是认不同异常性版本的gcc的，显然全交给msys2处理更方便一点

puts("190527水一贴"); 应贴吧要求，对广告贴和垃圾回复要进行严格的管理。嗯，很好很好死度娘，我要是真的这样干了你可不要封我

偶尔发个长篇会不会被删 //gcc -Wall -O3 -Os -s 音量闪换.c -I. -L. -lwinmm -lmingw32 -lgdi32 -lole32 -loleaut32 -luuid -lmsimg32 -lShlwapi -lKernel32 -lcomdlg32 -luser32 -lws2_32 -lcomctl32 -limm32 -o "音量闪换" #include <stdio.h> #include <stdlib.h> #include <windows.h> #include <ob**ase.h> /** Utlizar Mingw-w64 para obtener referencia a cada interfaz **/ #include <mmdeviceapi.h> #include <endpointvolume.h> typedef HRESULT(CALLBACK* CoInit)(void*); typedef void(CALLBACK* CoUnit)(void); typedef HRESULT(CALLBACK* CoCrIn)(CLSID*, LPUNKNOWN, DWORD, IID*, void**); /** Declaramos las GUID's de cada interfaz a utlizar **/ const CLSID CLSID_MMDeviceEnumerator = {0xBCDE0395, 0xE52F, 0x467C, {0x8E,0x3D, 0xC4,0x57,0x92,0x91,0x69,0x2E}}; const IID IID_IMMDeviceEnumerator = {0xA95664D2, 0x9614, 0x4F35, {0xA7,0x46, 0xDE,0x8D,0xB6,0x36,0x17,0xE6}}; const IID IID_IAudioEndpointVolume = {0x5CDF2C82, 0x841E, 0x4546, {0x97,0x22, 0x0C,0xF7,0x40,0x78,0x22,0x9A}}; int function_volume(IAudioEndpointVolume* control); void bucle_function_volume(IAudioEndpointVolume* control); int main(int argc,char **argv) { HANDLE getDll = LoadLibrary("Ole32"); CoInit coInit = (CoInit)GetProcAddress(getDll, "CoInitialize"); CoUnit coUnit = (CoUnit)GetProcAddress(getDll, "CoUninitialize"); CoCrIn coCreateIns = (CoCrIn)GetProcAddress(getDll, "CoCreateInstance"); HRESULT resp; IMMDeviceEnumerator* i_deviceEnum = NULL; IMMDevice* i_device = NULL; IAudioEndpointVolume* i_audioend = NULL; /** Iniciar libreria COM **/ if((resp = coInit(NULL)) == S_OK) { /** Obtener la interfaz MMDeviceEnumerator **/ if((resp = coCreateIns((GUID *)&CLSID_MMDeviceEnumerator, NULL, CLSCTX_INPROC_SERVER, (GUID *)&IID_IMMDeviceEnumerator, (void**)&i_deviceEnum)) == S_OK) { /** Mediante interfaz MMDeviceEnumerator llamamos al metodo GetDefaultAudioEndpoint para obtener la interfaz MMDevice **/ if((resp = i_deviceEnum->lpVtbl->GetDefaultAudioEndpoint(i_deviceEnum, 0, 0, &i_device)) == S_OK) { /** Mediante interfaz MMDevice llamamos al metodo Activate para obtener la interfaz IAudioEndpointVolume **/ if((resp = i_device->lpVtbl->Activate(i_device, &IID_IAudioEndpointVolume, CLSCTX_ALL, NULL, (void**)&i_audioend)) == S_OK) { if(function_volume(i_audioend) == 1) { printf("Error en opciones de volumen"); return 1; } } else { printf("Error al obtener interfaz IAudioEndpointVolume"); return 1; } } else { printf("Error al obtener interfaz IMMdevice"); return 1; } } else { printf("Error al obtener interfaz IMMDeviceEnumerator"); return 1; } } else { printf("Error al iniciar libreria COM"); return 1; } /** Liberar recursos **/ coUnit(); FreeLibrary(getDll); return 0; } /** Opciones para el control de volumen **/ int function_volume(IAudioEndpointVolume* control) { int resp; HRESULT ok; float volumen,volumen1,volumen2; resp = 1; volumen1=atoi(__argv[1]); volumen2=atoi(__argv[2]); if(__argc==1){ puts("音量快速切换工具 ver beta1.0"); puts("命令格式(音量取值范围0~100):"); puts("命令名参数1"); puts("命令名参数1 参数2(在参数1~2之间切换)"); } //指定单个音量 if(__argc==2&&volumen1 >= 0 && volumen1 <= 100 && (ok = control->lpVtbl->SetMasterVolumeLevelScalar(control, volumen1*0.01, NULL)) == S_OK) { printf("当前音量值: %.f \n", volumen1); resp = 0; } //两个值切换 if(__argc==3&&volumen1 >= 0 && volumen1 <= 100){ control->lpVtbl->GetMasterVolumeLevelScalar(control, &volumen); //printf("获取未修改前系统音量值%f",volumen*100); if(volumen*100 <= volumen1){control->lpVtbl->SetMasterVolumeLevelScalar(control, volumen2*0.01, NULL);} if(volumen*100 > volumen1){control->lpVtbl->SetMasterVolumeLevelScalar(control, volumen1*0.01, NULL);} } resp = 0; return resp; }

关于集成包的更新说明20190422 有些朋友误以为集成包不更新了，其实一直在更新的~ 吧盘里一直在更新无编译器版，因为对新人而言，次新的gcc编译器足够用了（支持各种成熟标准）。我曾经发贴说过下载解压无编译器版后，用junction命令指定自己的mingw目录就可以（对于老手，这个mingw建议用msys2内的mingw64,安装更新扩展库和工具都很方便）当然了当官方builts小组有大的编译器更新时，我也会顺手更新一下含编译器的集成包

notepad++主程序即将更新20190105 np++7.6.2黄背心版更新有些日子了官方对法国政治好象很关注的样子，不过这次支持作者的观点。gov就是为了大多数人服务，如果有这种环境让%1占有%80+的社会财富，那么这种这种环境下的政策一无是处，这种政府应该gun j8蛋~ 好了不谈国事，哪怕是国外的。这里还是聊一聊，np++数月来不断更新。从7.6.0版开始不断更新插件管理。起因还是因为曾经的插件管理这一插件的作者在插件是放了一个广告的连接。不得不说<插件管理插件>的作者是劳苦功高的，但是显然np官方十分不买帐，对np++这样一个免费并且开源的程序来说，放广告啥的是不能忍的。于是这个曾经被默认内置的插件管理插件被官方删掉了~ 然后官方自己写了个插件管理插件。很显然，这一事件影响对np++的影响很大的。不过从目前的结果来看，还好还还好~我曾经也认为官方这一行为有点过火，不过后来一想，这恐怕就是理念的不同。如果国内软件业能多一点这样较真的精神，也许，可能也只是也许会好一点点

mingw环境下python的诸多大坑从心里喜欢mingw这个平台，就算是python下的诸多大坑浪费了很多无谓的时间二楼来说一说我碰到的诸多坑

mingw64下pyinstaller的打包 mingw64环境下的python3.7对mingw64环境有依赖，目前发现的有zlib1.dll 在不同版本的mingw64上,可能对winpthread也有依赖除此之外对sjlj.seh.libgcc等，pyinstaller是可以找到并打包的

提前两年多达成目标没什么可说的，纯属自娱自乐庆祝一下

mingw64大版本更新啦

备份下我的7z打包命令不得不说某度到无用的东西越来越多，随着互联网的发展，感觉这个问题会越来越严重。无用的信息大量充斥着网络，搜索引擎的算法明明可以改进的更好一点的

npmingw64调用msys2的mingw64包及python环境如果装有msys2.那么直接可以下载npmingw集成包的无编译器版。然后junction命令把msys2的mingw64目录链接为npmingw64下的mingw目录。命令例： junction C:\npMingw64\mingw C:\msys2\mingw64 junction.exe已经内置在集成包conemu命令行里

关于ln>mklink>junction linux下的ln命令可以软链接和硬链接，非常好用在win7下有mklink.exe这个类似的工具，但mklink的软链接有点毛病，不能在命令行用cd命令进入，对于一些有相对目录结构的程序不能运行而junction.exe可以实现ln的软链接功能。

msys2的gcc版本更新到8.2.0 官方小组的还停在8.1. 其实觉得这两个项目完全可以合并，msys2还是要方便一点

不至于吧发贴请遵守贴吧协议及“七条底线” 目前的情况真的有点过分了

分享一个mingw64使用的gtk3一体包纯64位，从msys2提取在mingw64的gcc8.1上实测通过理论上支持7.1gcc以后的版本。之前的版本支持情况未知

gtk3一体包下载纯64位，从msys2提取在mingw64的gcc8.1上实测通过理论上支持7.1gcc以后的版本。之前的版本支持情况未知

提取一个gtk3的开发包已经放在网盘里了，需要的自取因为在win下不能直接使用pkg-config命令。这个我在另一篇中《手动编译gtk3》里曾有过说明。本包集成了pkg-config程序，可以使用该命令，楼下详说

对于被删贴和封一天的贴子的随机说明这种贴子我会经常性的随机发送，实在不想一个个给申诉解释，太麻烦了~ 虽然目前暂不删贴，但作为大吧我对小吧们对伸手党的删贴行为表示赞成。伸手问作业，没有任何自己的算法的伸手行为，在吧规中是禁止的。置顶都有说明，被删正常！至于其它的伸手行为，看小吧们对吧规的个人理解吧

[问题贴]桌面右键菜单在哪添加呢百度了一下不是太旧的内容就是失效的内容。 xfce版的，更新到17.1.11后桌面右键菜单里的thunar root和终端选项没了，不太方便。终端还好，只要点一下[应用程序]的子菜单还能出来，thunar root菜单要到打开主文件夹才能右键看到了本来以为是我的升级姿式不对，后来直接下载了最新的17.1.11的iso重装才发现是这个菜单项没有了想请教下老司机们在哪里改动添加呢？

msys2下的gtk3配置和编译(纯手动参数展示) 好久没写点东西。因为最近多次的被度娘封号，所以实在是没心情。今天值班没事，顺便写点，不知道会不会被再次封号

教程安装:推荐一个最好用的linux发行版manjaro 这是一个archlinux的发行版。在学习c语言吧主试过多个发行版本的linux,因为不知道该干什么基本上就是为了用linux而用。在之前试过的archlinux是我感觉更新最爽的版本，当然deepin也很有特色吧主是在用集成包编程学习c语言后，然后试用了msys2. msys2下的pacman管理深深地打动了我。之后吧主才开始试用archlinux. 但是arch的安装是在是让人淡淡的忧伤直到，我开始用manjaro

mingw64官方更新了 Version 5 has been released v5.0.4: 2018-06-04 Fix gcc-8.1.0 compatibility regarding _xgetbv %e printf specifier will now produce at least 2 digits for the exponent.

吧友们对随机数有什么好办法么．一下午都在考虑随机数的问题．srand和rand组合的伪随机非常严重，1秒种子的限制考虑了好久．后来发现就算是用了毫秒也只是小有改善而已

出乎意料.官方小组gcc8.1.0更新了～

暂时放弃脚本语言的学习了生活上有了很大的变动．没心思学习新的知识，暂时只能维持在Ｃ语言上的学习了一直想学习python或lua.看了点入门，实在不知道该在哪门深入．既然不知道干脆就不深入好了．暂时把Ｃ语言当脚本语言用好了． tiny c 是一种既能编译Ｃ为运行程序．也能不编译直接运行c的编译器（解释器？）．既然有了这个那么我干脆就继续学习Ｃ好了

官方能重新编译下基于的mingw64的纯64位库么？目前mingw的实际官方网已经是mingw64 现在的ege64库只能在sjlj异常的mingw64下使用．但是可以看到mingw64官方包括大部分的mingw64发行版都已经转向了seh异常．那么官方能否重新编译一下能支持seh异常的x64位库呢

吹的是个心情，借用下吧主的图

大改版即将完工虽然也不会有太多人关心这种事的说。不过还是希望能努力做好，目前集成包下载量已达到2500次，我当初的愿望〉达成万次看来是可以实现的。能为开源做点事真的是很开心。从使用上基本感觉不到变化。只是集成包的整合结构基本重来一次，可算定义性和集成环境健壮性大大增加.目前基本完功，测试两日上传，也许等不急会上传个alpha版模块化的组合形式，编辑环境（np++），命令控制环境(coemu)，编译器(mingw64) 这样做的目的是可以灵活的选用编译器(基本可以选用官方任意版本的编译器，seh,posix,sjlj,win32,dw) 当然了一切弄好仍然是集成包的形式给大家，但方便了以后自己可以升级的玩家。sourceforge上有很多发行版，基本上可以随意的挑选自己喜欢的编译器，而编辑和控制环境不变。这样好爽

装了个可以**的gdbinit 老实说目前这东西对我用处不大，只是看上去蛮好． mingw64下的gdb可以工作的很好，当然了，要配置好才

20180512重大ＢＵＧ关于gdb 被这个bug折磨了有些时间了．估计没什么人用的，所以连个反馈的都没有～今天研究数个版本的mingw64和一些发行版的mingw,以及tdm-mingw 官方的posix-sjlj版的带的gdb有很多不爽，最糟糕的就是输错命令会死机～以及一些命令会死机．我在dgn版和distro mingw两个流行的发行版也发现了这一现象，而这两个版本分别用的是win32 seh和posix seh.太尴尬了目前发现的官方posix seh版本自带的（通常就是这个版本编译的）gdb使用正常．

Black Rooster的VLA压缩器又更新了好久没发贴了最近Black Rooster的VLA压缩器又更新了

gcc8.1出来了 gcc9.0也在快速开发中．好期待．不知道mingw64小组什么时候会跟进感觉现在的ming64编译出来的程序性能已经很好了，体积也够小中国啊！唉．再一次赞叹伟大的开源

分享一个命令行的颜色工具 tcolor.exe 64位版16k大小 32位版12k大小用法如楼下

对网络上收费调音师的看法首先要说的是吧主个人不喜欢交费请人调音的行为．所以对吧里很多为了调音加ＱＱ我直接拉黑了．吧主曾经干过一年多的调音师，老实说这行你不仔细学一学，很多基础的你都不懂．对网络上特别是很多变声贴吧，学了一两款软件就出来收钱的很是不以为然．但从另一方面来看，不是每个有调音需要的人都能自己学习调音，那么交钱请人帮忙也无可厚非．老实说，真正人家调的好，收个几百也不算多，一个认真学习的调音师学习成本也不少．

今天真是out了．upx是开源的原来upx竟然也是一个开源软件，一直都没注意的说．话说用了这个软件NN年了．今天想给自己编的程序打个压缩包，顺手一搜，发现这东东在git上有家～．现在好象杀软对upx这种常用壳基本不杀了，使用方便，而且现在有点喜欢有命令行，太方便了命令: upx -1(可选1-9压缩率) 文件名.exe 也可以这样好记: upx --best 文件名.exe 这么一搞我都想仔细看看源码了解一下压缩壳技术了～向开源的大佬们致敬～

关心常用编译器是程序员的必备功课么？标题只是吐槽．反正吧主不是程序员，业余爱好玩玩就好． 730gcc用了有一个多月了控制台编译高量显示这个蛮好的还有一些系统函数的头文件变化了：如果碰到In file included from XXX.h这种警告，很可能就是你以前要定义的一些调用系统参数的函数在新版中被默认加入了可以在源码直接调用，在源码中重复定义了它可能就会产生警告～所以说去官方看看更新内容报告还是有必要的．多嘴一句：吧主对c99 c11的新特性用的很少，而很明显的一些吧友在使用这些特性．希望有更多的吧友能提供相关的测试信息，百度关于这方面的中文内容本来就少．有心得的吧友请多多发贴，让后来的朋友们少走点弯路

吐个槽每次心中忿忿不平的时候技术就涨了生气的时侯果然是有气啊。气息比平时不稳，但明显更足了。气颤音也容易发出来了。吹它个半小时气也平了。箫果然是古代君子陶冶情操的好东西。

np++及其插件有重大更新[20180317] np++本身的版本更新了，不过这一版对程序编译帮助不大，暂不打算更新其主程序．倒是nppexec插件有重大更新了．实测其自带的环境变量（引入系统变量）稳定了许多，这可以让现集成包内的编译代码便宜至少三成．有了内设环境变量可就方便多了～

最好的winapi源码教程首先要说一下，当使用wWinMain()之类的函数时，在编译正常情况下需要加上-municode，如果没用当然就不能加，加了会出错，同样的你用了不加也会因为找不到入口而出错～好了绕口令结束． zetcode.com是一个很好的网站．在它的首页可以看到Windows API tutorial这个winapi教程，吧主英文不好，在这里不说它的教程有多好，我领会不到，关键是这个教程所带的源码太棒了．非常完整的例子．我会把这个包传到传到百度盘，包名为［WindAPI-examples-zetcode.com］

难怪那么多linux下的程序员不愿意用IDE IDE都有一个猪脑子，所以用ＩＤＥ的得有一个＂好脑子＂－－－－－－－－－－－－－－－－－－－－－－－mingw吧主语 npmingw64集成包说到底还是一款命令行接近批处理方式运行的＞命令行编译想怎么编译随心所欲这两天一直想给吧友整一个codeblock 汉化集成包，非常适合用来作IDE入门的那种，事实上也整好了，可是我觉得这种东西毛病太多，太Ｔ妹的不自由了．本人几个月前入坑开始就是用的codelite，用了三个晚上就去整记事本了．因为感觉ＩＤＥ这东西太恶心，随后用了两晚上选择了不同的文本编辑器＞最后当然是np++.实际上觉得codelite在环境配置的易用上已经远远超过codeblock的．只是cb在debug上目前还是强于cl.但是cl是一个64位编辑器，这什么年代了你ＣＢ还要整32位的！在win下任意编辑器＋批处理已经可以很方便的c编程了，实在看不出有用IDE的必要．大点的工程直接makefile,学习makefile三个晚上可以掌握的工程，对于业余来说一辈子也用不了啊！就算是github上好样的个人软件，我也没看出有几个用makefile解决不了的． mingw吧当然不能是npmingw吧，还在犹豫着，肯定还要弄个ＩＤＥ集成包充充门面～

c语言吧新人引导，入门必看！新人请仔细阅读本贴，问本贴中叙述过的内容可能会遭到吧务和众吧友的反感和鄙视，请自重！Ｃ入门必备三样东东,楼下详说

npmingw64集成包加入ege库，可直接编译

准备加入ege库，集成压缩包体积再次增大210K 从对新人友好的角度来说，短时间内可能不会加入新的三方库了其实入门图形库类似的还有一个ACLLib，但至少ege一直有人维护，而且用的人也多一些有多次有人让我加入这库了，感觉学校里用这库入门的还是蛮多的，反正不大，加就加吧

宣告，本吧即将进入有序状态20180211 支持度娘　，支持贴吧管理团队感谢@贴吧管理团队->让本吧重新进入有序状态本人将在暂代吧主期间做好本小吧主的工作，协助好贴吧团队对本吧的管理

关于rc编辑器本来是不太想开新贴的，不过这几天一直在研究这个．一款能够建立和修改rc窗体，支持拖放控件的小程序就是这几天一直想想的．先是找了一个7Ｍ大小的vc6 然后找到了几个诸如resed,resedit,resetitor等几个小软件最后觉得ResEd这个还不错，这是radmasam内置的资源编辑器，一个独立的小文件

vc6制作窗体程序后用mingw编译成64位程序 vc6制作窗体程序后用mingw编译成64位程序既然能用mingw生成，那么使用带有64位mingw的codeblock,codelite,cfree,devc++等都没问题了 vc弄个小程序的确是方便的．这一方法可以让舍不得丢开vc6的伙伴们可以直接编译出64位程序了也可以让使用mingw64的小伙伴们也能方便的进行win下的窗体制造了．好了实验成功．不知道这方法有人用过没，自己想出来的办法，我觉得好有成就感． ---------------------------------------------------百度mingw吧千城真人原创

吧资源贴开放msys2下载 sourceforge网站改版前就经常登不上，改版后下载也变的更困难了弄了官方包放在吧资源贴里了，方便需要的人下载．精品贴(c进阶资源)自己找 sourceforge网站的msys2包尽然比msys2官网的包还更加新，我也是醉了．开源这些家伙能认真点干事么

［原创教程］mingw64调用bass库 BASS音频库是一款对非商业用户免费的音频处理类库。功能强大，支持几乎所有音频的解码编码等处理。以及强大的扩展功能！ foobar,aimp3,千千静听．这些知名音频软件都有用到bass库以前观注这个东西的时候吧主还不会编程，那时候bass库还不能编译６４位程序．这两天又逛了一下bass网，发现更新了～能够使用bass库做一个自己喜欢的小播放器本就是吧主学习程序的初衷之一

辅助编程工具集合（综合介绍贴）专门开一贴，介绍那些可以让计算机编程时更顺手的东东欢迎各位吧友补充

昨天吧主差点就被永封了后怕，虽然封不封的无所谓，但是一月多来就白忙了，也是很心酸的～