level 8
官方新闻通讯81期！
原文地址：
http://www.reactos.org/zh/newsletter_81.html
level 8
acat1433
楼主
C++ Mangling
Those with any experience using third party libraries while writing C++ applications should quickly recognize the topic I am about to go over and can skip down to paragraph three for the ReactOS specific miseries. Those that are not familiar with the issues or want a refresher should continue. The C++ standard outlines behavior for C++ code when compiled. To be considered a compliant compiler requires following the specifications laid out, though no compiler that I am aware of actually implements 100% of the entire standard. Template related parts of the standard are notoriously fickle, for one. There are however behaviors the standard does not specify, leaving it up to compiler developers to come up with their own methods. Two big ones are exception handling and name mangling. Name mangling mainly has to do with how C++ compilers assign unique signatures to functions, classes, and class functions to ensure there is no collision when linking together multiple modules. Linkers tend to get confused if they see two functions named "foo" with no way of distinguishing which one was being called by code. Exception handling is mostly a matter of deciding where to put the information one needs to provide when an exception is thrown in a function, and various compilers choose to store that information in varying ways. Some may be better than others, but it mostly comes down to what were the priorities of the developers when they came up with the design.
Between the major C++ compilers out there, very few handle name mangling the same way. The only major ones that do so are GCC and Intel's C++ compiler, both of which follow the Itanium ABI coventions for mangling. For that matter, GCC actually switched from another method to the IA-64 convention starting in its 3.x series. As such, name mangling between versions of the same compiler also is not guaranteed to be the same. This is why when one goes to download third party libraries, there are often different versions for GCC, Visual Studio, and whatever other compiler may be supported that uses a different convention. Even ignoring differences in exception handling, one already faces incompatibilities trying to link code compiled by different compilers.
On Windows, Microsoft set the de facto standard for the application binary interface that includes conventions on name mangling and exception handling. Thus most compilers that target Windows are at least capable of following the convention, to an extent. And this is where the pain for ReactOS starts to creep in. Because ReactOS has to implement libraries that all Windows applications ultimately link to, we have to match the way an exported function is mangled. Currently the methodology is to use a spec file that explicitly defines what the mangled form of a function should be. This is a manual process and can be rather time consuming to put together. The pain above could mostly be eliminated if the project used Microsoft's compilers to build ReactOS. The way names are mangled and exceptions are supported would then match that of Windows, helping reduce the probability of an error in specifying a mangled name breaking applications because suddenly the application calls a non-existent function. The recent fiasco uncovered in rbuild's handling of non-existent functions should serve as a warning that these issues are not always easily detected. At the very least a MSVC build of ReactOS could be used as a benchmark to make sure issues are due to a compile or link time cause instead of being in our code.
2011年03月15日 05点03分
3
Those with any experience using third party libraries while writing C++ applications should quickly recognize the topic I am about to go over and can skip down to paragraph three for the ReactOS specific miseries. Those that are not familiar with the issues or want a refresher should continue. The C++ standard outlines behavior for C++ code when compiled. To be considered a compliant compiler requires following the specifications laid out, though no compiler that I am aware of actually implements 100% of the entire standard. Template related parts of the standard are notoriously fickle, for one. There are however behaviors the standard does not specify, leaving it up to compiler developers to come up with their own methods. Two big ones are exception handling and name mangling. Name mangling mainly has to do with how C++ compilers assign unique signatures to functions, classes, and class functions to ensure there is no collision when linking together multiple modules. Linkers tend to get confused if they see two functions named "foo" with no way of distinguishing which one was being called by code. Exception handling is mostly a matter of deciding where to put the information one needs to provide when an exception is thrown in a function, and various compilers choose to store that information in varying ways. Some may be better than others, but it mostly comes down to what were the priorities of the developers when they came up with the design.
Between the major C++ compilers out there, very few handle name mangling the same way. The only major ones that do so are GCC and Intel's C++ compiler, both of which follow the Itanium ABI coventions for mangling. For that matter, GCC actually switched from another method to the IA-64 convention starting in its 3.x series. As such, name mangling between versions of the same compiler also is not guaranteed to be the same. This is why when one goes to download third party libraries, there are often different versions for GCC, Visual Studio, and whatever other compiler may be supported that uses a different convention. Even ignoring differences in exception handling, one already faces incompatibilities trying to link code compiled by different compilers.
On Windows, Microsoft set the de facto standard for the application binary interface that includes conventions on name mangling and exception handling. Thus most compilers that target Windows are at least capable of following the convention, to an extent. And this is where the pain for ReactOS starts to creep in. Because ReactOS has to implement libraries that all Windows applications ultimately link to, we have to match the way an exported function is mangled. Currently the methodology is to use a spec file that explicitly defines what the mangled form of a function should be. This is a manual process and can be rather time consuming to put together. The pain above could mostly be eliminated if the project used Microsoft's compilers to build ReactOS. The way names are mangled and exceptions are supported would then match that of Windows, helping reduce the probability of an error in specifying a mangled name breaking applications because suddenly the application calls a non-existent function. The recent fiasco uncovered in rbuild's handling of non-existent functions should serve as a warning that these issues are not always easily detected. At the very least a MSVC build of ReactOS could be used as a benchmark to make sure issues are due to a compile or link time cause instead of being in our code.
level 8
acat1433
楼主
Debug Page Heap
Over the years several tools have been developed to try and find memory corruptions in ReactOS, a not minor consideration due to the sad state of the memory manager. Aleksey Bragin wrote a pool integrity checker for the old pool implementation while Michael Martin came up with a new one using QEMU's built in memory watching functionality. Windows actually also has some built in support for detecting corruptions in the heap, the area of memory where dynamic memory allocations are made. This debug heap can be used by application developers to see if their programs are misusing memory and is a very useful tool for detecting corruptions and the like. Access to this debug pool can be turned on in the registry or using the gflags application Microsoft distributes.
When the debug heap is turned on for an application, its memory allocations are actually handled by a separate heap manager. This heap manager does away with the usual optimizations and actually adds some overhead by adding additional bookkeeping information for each allocated block of memory. One of these additions is the use of guard pages around each allocated block, which will trigger an exception if the application tries to access outside the bounds of the block. The overhead of this bookkeeping is however considerable, even ignoring the complete lack of optimizations. Aleksey spent about a week and a half implementing this second heap manager for ReactOS and it is now committed. The timing was quite fortuitious as the developers and testers have been running into a tremendous number of heap corruptions recently, a combination of the new, stricter standard heap manager and sloppy code in other parts of the operating system and applications that keep corrupting the heap. A steady stream of tests, patches, and retests have been taking place while preparing for the 0.3.13 release and hopefully most of the issues will be squashed.
2011年03月15日 05点03分
4
Over the years several tools have been developed to try and find memory corruptions in ReactOS, a not minor consideration due to the sad state of the memory manager. Aleksey Bragin wrote a pool integrity checker for the old pool implementation while Michael Martin came up with a new one using QEMU's built in memory watching functionality. Windows actually also has some built in support for detecting corruptions in the heap, the area of memory where dynamic memory allocations are made. This debug heap can be used by application developers to see if their programs are misusing memory and is a very useful tool for detecting corruptions and the like. Access to this debug pool can be turned on in the registry or using the gflags application Microsoft distributes.
When the debug heap is turned on for an application, its memory allocations are actually handled by a separate heap manager. This heap manager does away with the usual optimizations and actually adds some overhead by adding additional bookkeeping information for each allocated block of memory. One of these additions is the use of guard pages around each allocated block, which will trigger an exception if the application tries to access outside the bounds of the block. The overhead of this bookkeeping is however considerable, even ignoring the complete lack of optimizations. Aleksey spent about a week and a half implementing this second heap manager for ReactOS and it is now committed. The timing was quite fortuitious as the developers and testers have been running into a tremendous number of heap corruptions recently, a combination of the new, stricter standard heap manager and sloppy code in other parts of the operating system and applications that keep corrupting the heap. A steady stream of tests, patches, and retests have been taking place while preparing for the 0.3.13 release and hopefully most of the issues will be squashed.
level 8
acat1433
楼主
Temporary Files
One of the regressions testers and developers wanted squashed was the failure to install and use Adobe Flash. As reports poured in, Pierre Schweitzer began investigating as many of the testers claimed there was an issue in file creation during the install process. The problem was eventually discovered to be an issue in how ReactOS creates temporary files, or more specifically the code ReactOS imported from Wine for creating temporary files. The specific version ReactOS imported was broken, repeating the filename that was given to the function for the file it was supposed to create. A newer version had the problem fixed, but based on Pierre's investigation Wine's approach for generating filenames in the instance where one is not provided was different from how Windows does it. As such, Pierre decided to rewrite the function in question to better match Windows' behavior. While Pierre's patch allowed the Flash installer to succeed, Flash itself still remains stubbornly broken due to other regressions.
2011年03月15日 05点03分
5
One of the regressions testers and developers wanted squashed was the failure to install and use Adobe Flash. As reports poured in, Pierre Schweitzer began investigating as many of the testers claimed there was an issue in file creation during the install process. The problem was eventually discovered to be an issue in how ReactOS creates temporary files, or more specifically the code ReactOS imported from Wine for creating temporary files. The specific version ReactOS imported was broken, repeating the filename that was given to the function for the file it was supposed to create. A newer version had the problem fixed, but based on Pierre's investigation Wine's approach for generating filenames in the instance where one is not provided was different from how Windows does it. As such, Pierre decided to rewrite the function in question to better match Windows' behavior. While Pierre's patch allowed the Flash installer to succeed, Flash itself still remains stubbornly broken due to other regressions.