• Re: MD5运算多次能不能显著增加安全性?

    1、优先用强的hash算法(sha256以上),而不是变着花样用弱的hash算法。因为你不知道后者的暴力穷举空间到底是增大了、增大了多少,还是减小了。即便是同时碰撞md5 + sha1,穷举空间也不一定有想象中那么大的增长。

    2、即使用强的算法,能用salt也尽可能用salt。不过文件hash这个一般不用salt,salt主要用在password hash上。

    今天 01:17
  • Re: 如何写基于SDK对话框的代码

    《Programming Windows》,从这本书里抄例子就行

    今天 00:57
  • Re: linux内核,hotspotJVM,mysql,g++复杂度怎么排序

    没人敢回答,挖坑失败,哈哈

    【 在 greenonline 的大作中提到: 】

    : 不知道,有人都做过吗

    前天 21:21
  • Re: 电脑上有360产品,ie就不能用网银了

    去360的论坛联系360的客服解决,他们搞定不了的话,会找对应的开发人员帮你搞定。

    【 在 bjlawyer 的大作中提到: 】

    : 首先,装360之前没有这个问题,当然也不是刚装上就出来的,但这个我认为是它的高明之处

    : 其次,多个网银都出现这种情况,很明显是有软件有针对性搞的。同时只有ie出问题,360浏览器正常,只能怀疑它了。没法100%确定,但八九不离十

    : 最后,记得以前登录网银弹出过360的提示,用它的什么安全服务,针对所有网银提升安全

    前天 18:08
  • Re: 哪个技术的exe可以不用安装依赖运行于win7以上

    最近在看imgui,这个在游戏行业用得多。有兴趣的可以搜来玩玩

    【 在 mingtong (。。。) 的大作中提到: 】

    :  要做一个小东西,几个图片,几个按钮,几乎纯显示作用。

    :  或者依赖可以打进单独的exe,但是要求体积最小。

    前天 16:00
  • Re: 360浏览器劫持网站内容网站加广告的行为违法吗?

    先在360浏览器中把全部插件都禁用,看问题是否还存在。界定一下是不是插件捣鬼

    【 在 tangliang (唐亮工场) 的大作中提到: 】

    :  360浏览器太坏了

    :  打开网站。右下角悬浮、顶部悬浮、底部悬浮全都是360浏览器自己给网站加的广告,同时还会篡改网站链接,链接到360自己的网站,这样的行为太没底线了,也太不要脸了,这样的行为在美国和欧洲可以起诉吗?

    :  --

    前天 15:56
  • Re: 电脑上有360产品,ie就不能用网银了

    你这咋能证明是360捣鬼呢?好玩

    【 在 bjlawyer (北京律师) 的大作中提到: 】

    :  最开始发现用ie登录光大网银,密码不能输入了。有人提示是360搞鬼我还不太信

    :  直到后来发现工商,中信,民生都不行了,不是登不上就是里面功能受限,而360浏览器却能正常使用

    :  流氓本性不得不服。同时360浏览器还不稳定,动不动来个停止响应

    前天 15:54
  • Re: 一个工程,每个目录编译一个.a

    1楼和6楼都指出要点了

    跨模块的优化,微软称为LTCG(Link Time Code Generation),gcc和clang可能叫做LTO(Link Time Optimization)。

    如果单独编译出.a中的每个.o时,都指定了LTCG参数,那么生成的.o文件中带有用于跨模块优化的信息,按说和全部工程代码放在同一个.c文件中编译是一样的效果。

    MSVC

    https://docs.microsoft.com/en-us/cpp/build/reference/gl-whole-program-optimization?view=vs-2019

    https://docs.microsoft.com/en-us/cpp/build/reference/ltcg-link-time-code-generation?view=vs-2019

    GCC

    https://gcc.gnu.org/wiki/LinkTimeOptimization

    LLVM

    https://llvm.org/docs/LinkTimeOptimization.html

    Qt

    https://www.qt.io/blog/2019/01/02/qt-applications-lto

    04月04日
  • Re: win下有什么绿色的cpp编译器?

    地中、地老都知道Borland的哈

    Borland的那个可能不支持最新的c++标准。

    编译器toolchain中的工具一般都是命令行参数驱动的,很少有读取注册表、配置文件来决定怎么干的,所以都能绿色化。

    【 在 Z5boy 的大作中提到: 】

    : 传说的那个Borland?

    04月04日
  • Re: win下有什么绿色的cpp编译器?

    Visual Studio中的c++ build tools理论上可以绿色化,执行它的一个vcvars.bat之类的就设置好环境了。build tools可以单独下载,只安装其中的c++部分。

    https://devblogs.microsoft.com/cppblog/introducing-the-visual-studio-build-tools/

    Borland的应该也可以

    https://www.embarcadero.com/free-tools/ccompiler

    其实理论上所有的c++编译器应该都行,无非是设置PATH、INCLUDE、LIB。

    04月04日
  • Re: 咨询MinGW编译UTF-8 BOM代码的问题

    据下面这个,gcc在2008年改了UTF-8 with BOM的问题,看看mingw里的gcc版本

    https://gcc.gnu.org/bugzilla/show_bug.cgi?id=33415

    04月02日
  • Re: aligned_allocator到底做了什么?

    有些场景下不仅仅要求2/4/8/16字节对齐,可能是要求按磁盘扇区大小对齐、按内存页面大小对齐等等。

    比如外设的DMA数据传输、文件的direct I/O(win/linux都有这种模式,linux可以搜一下O_DIRECT,win下搜FILE_FLAG_NO_BUFFERING)

    楼主这个在上面回答了,是和FPGA外设的bulk数据传输。

    【 在 hongdiao 的大作中提到: 】

    : LZ的例子是vector<int>, 奇怪的是对于int的动态内存(数组)分配还能是不对齐的? 一般来说对齐都是对齐到int类型的长度吧比如4字节对齐。

    04月02日
  • Re: 一个进程用不同版本的.so库

    隐约记得好像之前也有人问过OpenCV的不同版本能否在同一个进程中共存

    能共存的前提是同一个库的不同版本没有使用进程内(乃至进程间)全局的OS对象。

    比如都去修改同一个环境变量,而且改出来的是不同的值。如果只是读取环境变量,应该没关系。

    或者去读写同一个名字的共享内存、写入同一个文件。

    04月02日
  • Re: aligned_allocator到底做了什么?

    这两个资料可以进一步参考一下

    Intel编译器的对齐优化(普通变量对齐主要是为了cpu bus和cache优化)

    https://software.intel.com/en-us/articles/coding-for-performance-data-alignment-and-structures

    windows kernel driver对于应用层传递来的参数的地址对齐检查

    https://docs.microsoft.com/en-us/windows-hardware/drivers/kernel/avoiding-misalignment-of-fixed-precision-data-types

    04月02日
  • Re: aligned_allocator到底做了什么?

    比如,有些操作需要页面对齐,假如内存页面大小是4096字节,那么传递给API(或者说成传给os/硬件)的buffer首地址必须是4096的整数倍。这就是内存地址对齐。

    【 在 happybamboo 的大作中提到: 】

    : 你好,对齐的内存地址怎么理解?vector本身就是连续内存,int又是32bit,我不太理解还需要怎么对齐。

    04月02日
  • Re: 头条面试需要刷算法题吗

    头条不是不招比张一鸣年纪大的码农?

    04月02日
  • Re: aligned_allocator到底做了什么?

    可以单步跟进去看的。

    顾名思义,就是返回对齐的内存地址。有些API或者OS机制需要提供对齐的地址,不然就会返回失败。

    通常是调用编译器提供的intrinsic函数。或者多分配一点内存,在分配的这段内存中从头开始找到对齐的那个地址,返回那个地址即可。

    参考:https://johanmabille.github.io/blog/2014/12/06/aligned-memory-allocator/

    04月02日
  • Re: 问一下,这是什么加密算法? (转载)

    padding不唯一,但是是有限的可能取值。

    padding就是寻找m、n,使得table] == table[4n](这样才有table] ^ table[4n] == 0),然后用m、n分别作为低4位、高4位拼凑出a,用a跟密钥key[i]异或就得到padding字节了。

    为了方便寻找满足table] == table[4n]的m、n,给table新建一个查找表就行了,保证从这个新表里(随机)查找出来的m、n一定满足table] == table[4n]。

    新表是两个集合,第一个是{ x | table[4x] = 0},第二个是{y | table[4y] = 1}

    每次从第一或者第二个集合中任取两个数作为m、n(m和n可以相同)。

    嫌麻烦的话,直接令m = 1, n = 2就行了,去掉随机性(是否会增加已知明文攻击的可能请自行判定)

    table] = table[4] = 1

    table[4n] = table[8] = 1

    04月02日
  • Re: 关于逆向修改小工具的问题

    单就文件分割这个访问模式来说,内存映射应该无法提速。

    “内存映射有性能优势”这个(不一定正确的)观点在不少地方都有,比如

    《Code Quality: The Open Source Perspective》这书的memory mapping相关章节:

    https://books.google.com/books?id=vEN-ckcdtCwC&pg=PA241&lpg=PA241&dq=createfilemapping+buffer&source=bl&ots=sI7od62UsI&sig=ACfU3U3EZ07tJMaPnqXW4DgYHkHuZOS4lQ&hl=zh-CN&sa=X&ved=2ahUKEwj8gfnX0MfoAhXhoFsKHZarAoUQ6AEwCHoECAsQLQ#v=onepage&q=createfilemapping%20buffer&f=false

    下面这个分析和结论我觉得不错:哪种方式性能好是取决于访问文件的模式的。

    而且他有个观点跟你的一致,就是内存映射方式写代码简单 :)

    https://unix.stackexchange.com/questions/474926/how-does-memory-mapping-a-file-have-significant-performance-increases-over-the-s/475014

    如果是文件分割操作,在windows平台上,读取大文件时最好加上FILE_FLAG_SEQUENTIAL_SCAN这个优化的标志,虽然不一定保证能提速。

    windows文件操作的另一个标志FILE_FLAG_NO_BUFFERING(亦即所谓的direct I/O)也是被误解的。这个标志虽然越过了文件系统的cache,但不一定能提速。具体的分析可以参考:

    https://devblogs.microsoft.com/oldnewthing/20140306-00/?p=1583

    https://stackoverflow.com/questions/4574996/using-file-flag-no-buffering-will-return-noticeable-speed-gain

    比较好的文件操作方式是异步,这是下面这个对比帖子说的方案。

    因为可以尽可能腾出cpu干别的事情,但文件分割这个需求也不需要腾出cpu干别的事情。

    至于耗费cpu进行压缩解压,就不在讨论之列了。

    https://www.gamasutra.com/view/feature/1565/fast_file_loading_pt_1.php?print=1

    【 在 puke 的大作中提到: 】

    : 用内存映射就是图个简单,提速这个说法不知道是谁猜的。

    : 如果还要不停的手动映射文件不同区域,这还不够费事的。

    04月02日
  • Re: 文件分割测试工具PK

    赞实证精神!

    Windows下的也有人做过测试了,也是一样的性能(针对DVD的那点提速感觉不能算),仅限于特定的文件访问模式。

    https://www.gamasutra.com/view/feature/1565/fast_file_loading_pt_1.php?print=1

    楼主那个split每次用的buffer的大小,也会影响到性能。

    【 在 ArchLinux 的大作中提到: 】

    : 我在我的系统下也自己写了个版本:https://paste.debian.net/1137584/

    : 操作系统是 Arch (Linux 5.4.28). 分割一个 4.6G 的文件,大小30M,读入和写出的文件都在同一块 SSD 上。测试了一下硬盘速度,读入这个文件大约需要 11s. 运行程序前先运行 sync; echo 1 > /proc/sys/vm/drop_caches 把系统缓存的文件清掉。用 time 记录时间。

    : split(1):

    : ...................

    04月02日