The death of Microsoft

http://www.youtube.com/watch?v=p92QfWOw88I
How does /prog/ feel about this?

>>35
>DLLs will be gone along with all dynamic libraries when 16-32gb of RAM will be standard on entry level computers.
>16-32gb
>Not writing GiB

wat

The day that shared libraries and dynamic linking & loading dies will be the day that Ulrich Drepper got hit by a bus.

But I like DLLs. I hate having to see the same code when I'm disassembling some closed source software, and I hate seeing many extra megabytes of library code appended to a few kilobytes of actual code. Of course, I can make signatures for statically linked libraries, but that's not the point.
The major issue with them is properly dealing with versioning, but there are multiple working solutions to this.

>>43
That is why static code analysis sucks and it cant solve halting problem. Use emulator and debug code interactively.

>>44
You don't need to solve halting problems to implement adequate static code analysis. Go see the other thread where a wrench was thrown into your proposed problem. You need only consider the worst case path, and therefore you can collapse all conditional logic and determine an upper bound.

>>45
You don't need to solve halting problems to implement adequate static code analysis.
I packed my code using GZIP. Try ANALysing it, faggot.

>>44
I do both actually. A mix of static RCE and debugging yields best results. However, this is only because it's the fastest way of acquiring information (only disassembling can take too long, especially if the code overuses indirection, only debugging can get you to some specific targets, but if there are no obvious things to look into at runtime, it can end up wasting time while being not very productive, however mixing both techniques yields best results - you can gain a large overview of the code using static code analysis and then inform your debugging with the information you gained statically, which will usually yield more information which can then be used to clarify whatever parts were unclear statically - both techniques complement each other, and using either by itself makes you spend a lot more time to achieve your goals).

>>44
I do both actually. A mix of static RCE and debugging yields best results. However, this is only because it's the fastest way of acquiring information (only disassembling can take too long, especially if the code overuses indirection, only debugging can get you to some specific targets, but if there are no obvious things to look into at runtime, it can end up wasting time while being not very productive, however mixing both techniques yields best results - you can gain a large overview of the code using static code analysis and then inform your debugging with the information you gained statically, which will usually yield more information which can then be used to clarify whatever parts were unclear statically - both techniques complement each other, and using either by itself makes you spend a lot more time to achieve your goals).

>>44
I do both actually. A mix of static RCE and debugging yields best results. However, this is only because it's the fastest way of acquiring information (only disassembling can take too long, especially if the code overuses indirection, only debugging can get you to some specific targets, but if there are no obvious things to look into at runtime, it can end up wasting time while being not very productive, however mixing both techniques yields best results - you can gain a large overview of the code using static code analysis and then inform your debugging with the information you gained statically, which will usually yield more information which can then be used to clarify whatever parts were unclear statically - both techniques complement each other, and using either by itself makes you spend a lot more time to achieve your goals).

>>44
I do both actually. A mix of static RCE and debugging yields best results. However, this is only because it's the fastest way of acquiring information (only disassembling can take too long, especially if the code overuses indirection, only debugging can get you to some specific targets, but if there are no obvious things to look into at runtime, it can end up wasting time while being not very productive, however mixing both techniques yields best results - you can gain a large overview of the code using static code analysis and then inform your debugging with the information you gained statically, which will usually yield more information which can then be used to clarify whatever parts were unclear statically - both techniques complement each other, and using either by itself makes you spend a lot more time to achieve your goals).

>>47-50
Oops, sorry about that, it appeared as if posting failed, when it didn't.

>>51
I do both actually. A mix of static RCE and debugging yields best results. However, this is only because it's the fastest way of acquiring information (only disassembling can take too long, especially if the code overuses indirection, only debugging can get you to some specific targets, but if there are no obvious things to look into at runtime, it can end up wasting time while being not very productive, however mixing both techniques yields best results - you can gain a large overview of the code using static code analysis and then inform your debugging with the information you gained statically, which will usually yield more information which can then be used to clarify whatever parts were unclear statically - both techniques complement each other, and using either by itself makes you spend a lot more time to achieve your goals).

>>52
I do both actually. A mix of static RCE and debugging yields best results. However, this is only because it's the fastest way of acquiring information (only disassembling can take too long, especially if the code overuses indirection, only debugging can get you to some specific targets, but if there are no obvious things to look into at runtime, it can end up wasting time while being not very productive, however mixing both techniques yields best results - you can gain a large overview of the code using static code analysis and then inform your debugging with the information you gained statically, which will usually yield more information which can then be used to clarify whatever parts were unclear statically - both techniques complement each other, and using either by itself makes you spend a lot more time to achieve your goals).

>>53
I do both actually. A mix of static RCE and debugging yields best results. However, this is only because it's the fastest way of acquiring information (only disassembling can take too long, especially if the code overuses indirection, only debugging can get you to some specific targets, but if there are no obvious things to look into at runtime, it can end up wasting time while being not very productive, however mixing both techniques yields best results - you can gain a large overview of the code using static code analysis and then inform your debugging with the information you gained statically, which will usually yield more information which can then be used to clarify whatever parts were unclear statically - both techniques complement each other, and using either by itself makes you spend a lot more time to achieve your goals).

>>54
I do both actually. A mix of static RCE and debugging yields best results. However, this is only because it's the fastest way of acquiring information (only disassembling can take too long, especially if the code overuses indirection, only debugging can get you to some specific targets, but if there are no obvious things to look into at runtime, it can end up wasting time while being not very productive, however mixing both techniques yields best results - you can gain a large overview of the code using static code analysis and then inform your debugging with the information you gained statically, which will usually yield more information which can then be used to clarify whatever parts were unclear statically - both techniques complement each other, and using either by itself makes you spend a lot more time to achieve your goals). oh and check my doubles

>>55
I do both actually. A mix of static RCE and debugging yields best results. However, this is only because it's the fastest way of acquiring information (only disassembling can take too long, especially if the code overuses indirection, only debugging can get you to some specific targets, but if there are no obvious things to look into at runtime, it can end up wasting time while being not very productive, however mixing both techniques yields best results - you can gain a large overview of the code using static code analysis and then inform your debugging with the information you gained statically, which will usually yield more information which can then be used to clarify whatever parts were unclear statically - both techniques complement each other, and using either by itself makes you spend a lot more time to achieve your goals). oh and nice doubles

>>56
I do both actually. A mix of static RCE and debugging yields best results. However, this is only because it's the fastest way of acquiring information (only disassembling can take too long, especially if the code overuses indirection, only debugging can get you to some specific targets, but if there are no obvious things to look into at runtime, it can end up wasting time while being not very productive, however mixing both techniques yields best results - you can gain a large overview of the code using static code analysis and then inform your debugging with the information you gained statically, which will usually yield more information which can then be used to clarify whatever parts were unclear statically - both techniques complement each other, and using either by itself makes you spend a lot more time to achieve your goals).

>>57
I do both actually. A mix of static RCE and debugging yields best results. However, this is only because it's the fastest way of acquiring information (only disassembling can take too long, especially if the code overuses indirection, only debugging can get you to some specific targets, but if there are no obvious things to look into at runtime, it can end up wasting time while being not very productive, however mixing both techniques yields best results - you can gain a large overview of the code using static code analysis and then inform your debugging with the information you gained statically, which will usually yield more information which can then be used to clarify whatever parts were unclear statically - both techniques complement each other, and using either by itself makes you spend a lot more time to achieve your goals).

>>58
I do both actually. A mix of static RCE and debugging yields best results. However, this is only because it's the fastest way of acquiring information (only disassembling can take too long, especially if the code overuses indirection, only debugging can get you to some specific targets, but if there are no obvious things to look into at runtime, it can end up wasting time while being not very productive, however mixing both techniques yields best results - you can gain a large overview of the code using static code analysis and then inform your debugging with the information you gained statically, which will usually yield more information which can then be used to clarify whatever parts were unclear statically - both techniques complement each other, and using either by itself makes you spend a lot more time to achieve your goals).

>>59
I do both actually. A mix of static RCE and debugging yields best results. However, this is only because it's the fastest way of acquiring information (only disassembling can take too long, especially if the code overuses indirection, only debugging can get you to some specific targets, but if there are no obvious things to look into at runtime, it can end up wasting time while being not very productive, however mixing both techniques yields best results - you can gain a large overview of the code using static code analysis and then inform your debugging with the information you gained statically, which will usually yield more information which can then be used to clarify whatever parts were unclear statically - both techniques complement each other, and using either by itself makes you spend a lot more time to achieve your goals).