64位Delphi应该测试什么 [英] What should be tested in 64-bit Delphi

查看:30
本文介绍了64位Delphi应该测试什么的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

Delphi 64 位编译现在处于 Beta 版,但只有受邀 Beta- 测试人员将掌握此版本.

Delphi with 64 bit compilation is now in Beta, but only invited beta-testers will get their hands on this version.

beta 测试人员应该测试什么?

What should be tested by the beta testers?

推荐答案

Embarcadero 可能会为 Beta 测试人员提供测试人员指南.但是,这里有一些想法:

Embarcadero will probably provide a tester's guide for the beta testers. But, here are some ideas:

  • 内存分配、对齐、堆和堆栈. 32 位在带有 /LARGEADDRESSAWARE 开关的 64 位版本的 Windows 上,最多可以使用 4GB(好吧,3.5)的地址空间:Delphi64 应该能够使用更多.尝试分配 8、16 和 32 GB.(即使您的 RAM 较少,分配也应该有效,因为它是一个虚拟地址空间.)现在在某个位置读取和写入值:检查您的分配和指针是否正常.查看 Process Explorer 为应用程序报告的内容.检查您的堆栈:它自上而下运行,与堆不同 - 它看起来像什么,它使用什么地址?16 字节对齐是什么样的?这种对齐是为所有内部 Pascal 函数保留的,还是只为那些调用外部代码的函数保留?在 32 位 VCL 中,有些代码对于大于 2GB 的地址是不安全的.那些修好了吗?当它被分配到你的程序地址空间的第 53 GB 时,是否会出现任何问题?(尝试分配大量资源,然后动态创建表单、控件等 - 它们可能会使用高地址创建.)内存管理器是否碎片化?内存移动和复制的速度有多快?

  • Memory allocation, alignment, heap and stack. 32-bit could use up to 4GB (well, 3.5) of address space on a 64-bit version of Windows with the /LARGEADDRESSAWARE switch: Delphi64 should be able to use much more. Try allocating 8, 16, and 32 GB. (Even if you have less RAM, the allocation should work since it's a virtual address space.) Now read and write values into it a certain spots: check your allocation and pointers all work. Have a look at what Process Explorer reports for the app. Inspect your stack: it runs top-down, unlike the heap - what does it looks like, what addresses is it using? What does the 16-byte alignment look like? Is that alignment kept for all internal Pascal functions, or only those that call external code? In the 32-bit VCL, there were some bits of code that weren't safe for addresses larger than 2GB. Have those been fixed? Does anything break when it's allocated in, say, the 53rd GB of your program's address space? (Try allocating a huge amount, and then dynamically creating forms, controls etc - they'll probably be created with high addresses.) Does the memory manager fragment? How fast are memory moves and copies?

编译器警告.(这一点很重要.) 升级您的程序 - 无需更改即可编译它们,并查看您收到哪些警告/错误;修复任何;然后修复即使您没有收到警告也会发生的错误.你遇到了哪些问题?编译器是否应该警告过您,但没有警告?在转换为整数时截断指针时是否收到警告?更复杂的问题呢:如果您使用 Single 浮点类型,会发生什么?警告,还是默默地表示为 double?如果您将一个参数传递给一个不同大小的方法 - 例如,PostMessage 并且您将一个 32 位大小的值传递给 handle 参数 - 会怎样?编译器足够聪明,可以猜测如果大小错误,您的代码可能是错误的,即使将较小的类型传递给较大的参数通常是有效的?在什么情况下应该这样做?(另一件事:如果你在一个需要指向 64 位类型的指针的方法中传递一个指向 32 位类型的 64 位指针怎么办 - 类型安全应该大声喊叫,但是是吗?一个用例是阅读二进制文件中的块,这很容易导致错误大小的类型出现问题.) ...等.

Compiler warnings. (This one is important.) Upgrade your programs - compile them without changes, and see what warnings / errors you get; fix any; and then fix bugs that occur even though you weren't warned. What issues did you encounter? Should the compiler have warned you, but didn't? Do you get warnings when truncating a pointer when casting to an integer? What about more complex issues: if you use the Single floating-point type, what happens? Warning, or is it silently represented as a double? What if you pass in a parameter to a method that's a different size - for example, PostMessage and you pass in a 32-bit-sized value to the handle parameter - will the compiler be smart enough to guess that if the size is wrong, your code might be wrong, even though it's often valid to pass a smaller type to a larger parameter? Under what circumstances should it do so? (Another thing: what if you pass a 64-bit pointer to a 32-bit type in a method expecting a pointer to a 64-bit type - the type safety should yell loudly, but does it? A use case for that is reading blocks from a binary file, something that could easily cause problems with the wrong-sized types.) ...etc.

编译器警告可能是升级人员最有用的工具之一,因此编译器应该在尽可能多的情况下产生尽可能多的警告,并尽可能减少误报.请记住,Delphi 被广泛的程序员使用 - 即使编译器处于沉默状态,您也可能知道警告的含义或识别错误代码,但任何对新手(或心情不好的优秀程序员)有帮助的东西都很重要.

Compiler warnings are probably one of the most useful tools for people who upgrade, so the compiler should produce as many as possible, in as many situations as possible, with as few false positives as possible. Remember Delphi is used by a wide range of programmers - you may know what a warning means or recognize bad code even if the compiler is silent, but anything that will help novices (or good programmers having a bad day) is important.

自定义控件和WinAPI.您可能有一些自定义控件或一些代码,它们大量使用 Windows API 而不是 VCL.是否存在任何特定于 Windows API 的问题?

Custom controls & WinAPI. You probably have a few customs controls or bits of code that make heavy use of Windows APIs instead of the VCL. Are there any Windows API-specific issues?

语言兼容性.旧的文件 IO 代码是否有效 - AssignFile 等?RTTI?如果您有一个 Integer 类型的事件签名,并且事件处理程序是由 IDE 自动创建的,它是生成为 Integer 还是特定于大小的整数类型,具体取决于当前设置的平台?如果事件是 NativeInt 呢,那又怎样呢?(我以前在事件处理程序方法签名生成中看到过错误,尽管只是在 C++ 方面.)

Language compatibility. Does the old file IO code work - AssignFile, etc? RTTI? If you have an event signature with an Integer type, and an event handler is auto-created by the IDE, is it generated as Integer or a size-specific integer type depending on the platform that's currently set? What if the event is NativeInt, what then? (I've seen bugs in event handler method signature generation before, though only on the C++ side.)

不同类型的应用程序.我们可以假设 GUI 程序已经过测试.控制台和服务应用程序呢?

Different types of application. We can assume GUI programs have been tested well. What about console and service applications?

C++Builder 兼容的文件生成. C++Builder 在 XE2 中不会是 64 位的,但希望在 XE3 中会.不过,Delphi 可以为 Pascal 代码生成 ..hpp 和 .obj 文件.在 64 位平台上会发生什么?你能生成那些文件,即使它们没用吗?编译器是在 64 位模式下生成特定于 C++ 的警告,还是放弃而不让您这样做?在 32 位模式下,您是否可以为 64 位兼容性做些什么来生成构建 C++ 标头的警告?

C++Builder compatible file generation. C++Builder won't be 64-bit in XE2, but hopefully will in XE3. Delphi can produce ..hpp and .obj files for Pascal code, though. What happens in for a 64-bit platform? Can you produce those files, even though they're useless? Does the compiler generate C++-specific warnings in 64-bit mode, or does it give up and not let you do it? In 32-bit mode, is there anything you can do for 64-bit compatibility that will generate a warning building the C++ header?

链接器.您可以链接使用其他编译器创建的 .lib 和 .obj 文件吗?(我希望 .lib 是,.obj 否.)链接器是否使用 COFF 或 OMF 用于 64 位 - 它们是否已更改?该主题暗示了 ELF 格式.32位也改了吗?这是否会影响 DCU 格式,我们还会获得超快的编译/链接吗?

Linker. Can you link .lib and .obj files created with other compilers? (I'd expect .lib yes, .obj no.) Does the linker use COFF or OMF for 64-bit - have they changed? This thread implies an ELF format. Has it changed for 32-bit too? Does this affect the DCU format, will we still get ultra-fast compiling / linking?

COM 和 64 位插件.有任何编组问题吗?您现在可以为 Explorer 构建 64 位插件吗?

COM and 64-bit plugins. Are there any marshalling issues? Can you build a 64-bit plugin for Explorer now?

调用约定. Safecall 应该是唯一的调用约定"(如果 safecall 算...)那仍然不同 - 它仍然有效吗?函数和过程指针,以及闭包(对象方法指针):它们有效吗?它们在调试检查器中是什么样子的?鉴于所有调用约定现在都相同,如果您在方法声明和调用指针中混合调用约定,会发生什么?是否有任何遗留的东西会破坏或透明地工作?它现在是否给您一个(错误的)警告,指出类型不兼容?

Calling conventions. Safecall's supposed to be the only 'calling convention' (if safecall counts...) that's still different - does it still work? Function and procedure pointers, and closures (object method pointers): do they work? What do they look like in the debug inspector? Given all calling conventions are now the same, if you mix calling conventions in your method declaration and your calling pointer, what happens? Is there any legacy stuff around that will break or does it transparently work? Does it now give you an (erroneous) warning that the types are incompatible?

浮点数学.Delphi 64 预览版 表示浮点数只有双精度.Delphi 可以处理 long double 吗?是否有任何兼容例程来处理旧的 Real(我认为是 48 位??)类型?编译器生成 SSE 或 SSE2 代码还是混合代码,效果如何?

Floating point math. The Delphi 64 preview said floating point would be double only. Can Delphi handle long doubles? Are there any compatibility routines for handling the old Real (48 bits, I think??) type? Does the compiler generate SSE or SSE2 code or a mix, and how good is it?

性能.这是他们第一次使用 64 位编译器;在接下来的几个版本中可能会对其进行改进.但是是否存在任何明显的性能问题,例如:

Performance. This is their first go at a 64-bit compiler; it will probably be refined over the next few releases. But are there any obvious performance problems, with:

  • 编译;链接;IDE 洞察力?

  • compiling; linking; IDE insight?

生成的代码:您的程序是更快还是更慢?FP 数学是更快还是更慢?inline 是否有效,它是否会围绕内联方法生成任何不必要的页眉/页脚位?

Generated code: are your programs faster or slower? Is FP math faster or slower? Does inline work, and does it generate any unnecessary header/footer bits around inlined methods?

调试.在测试其他所有内容的整个过程中,这可能是最容易测试的,但是 64 位调试器的工作情况如何?它是否具有 32 位的所有功能?IDE 调试可视化插件仍然有效吗?如果您调试非 Delphi 64 位程序或附加到进程,而不是正常运行怎么办?

Debugging. This is probably easiest to test through the whole process of testing everything else, but how well does the 64-bit debugger work? Does it have all functionality of the 32-bit one? Do IDE debug visualiser plugins still work? What if you debug a non-Delphi 64-bit program or attach to a process, instead of running normally?

杂项 Delphi 本身是否编译为 64 位程序?如果没有,为什么不呢?(他们吃自己的狗粮"吗?)代码检查新的 VCL(假设预览随附 VCL 源.)他们做了什么使 VCL 32/64 兼容?是否有任何错误,或者如果您已经从其他 IDE 中熟悉 64 位代码,他们是否可以采用更好的方法来替代?

Misc Is Delphi itself compiled as a 64-bit program? If not, why not? (Are they "eating their own dogfood"?) Code inspect the new VCL (assuming the preview comes with VCL source.) What have they done to make the VCL 32/64 compatible? Are there any errors, or if you already know 64-bit code well from other IDEs, are there better approaches they could take instead?

...等等.我可以连续打几个小时,但我认为这是一个好的开始:)

...etc. I could keep typing for hours, but I think that's a good start though :)

这篇关于64位Delphi应该测试什么的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆