Bugger - I didn't read the last source accurately enough - if I had, I would have discouraged you from this:Just when I thought I was out... they pull me back in.
There is a very good reason this is an extremely bad idea - as the x2 binary comes in two formats it is recommended that the portable-user carries both files as part of his setup - when on an x86 client system, he runs the x86 version, and x64 for x64, to accommodate programme shell extension compatibility, path-addressing, etc.
(As an x86 user you would not realise the many pitfalls which can arise from something which initially appears superficially simple. As an aside, this is one of the reasons it's almost unbelievable that your man has not moved heaven and earth to generate his own x64 version of xyplorer - compiler limitations or not - a file manager is not about any bland claims of "speed" or nonsense of memory-mapping (there is far more to x64 than memory); it is fundamentally important on the shell-level that the x64 integrity be respected and there simply is no excuse for not ensuring that. Any claim otherwise is misinformation: while an x86 process will indeed "run" just fine, it can't read the shell at all, and will also suffer the SYSWOW64 redirections on the path-resolution level which a power-user would find simply laughable. Reference this as an example where a user finds it difficult to understand even the explanation as to why he doesn't understand what he's actually looking at.)
Your previous method (of checking the OS bit-type) was perfectly acceptable as it would run the expected version appropriately. As it is now, if the user switches to an x86 system (and has both binaries as he should) it will always try to execute the x64 version and (if x86 OS) fail miserably. To circumvent this, the user would need to have two different runtime folders (and all that entails) with two different launch shortcuts, and he himself be aware of what the OS is beforehand (when most clients can't accurately tell you their own wive's true hair-colour, you can't trust what they might guess regarding OS bit-types).
Statistics: Posted by Enternal — 2013 Aug 13, 00:47
]]>
Just when I thought I was out... they pull me back in.
Bugger - I didn't read the last source accurately enough - if I had, I would have discouraged you from this:There is a very good reason this is an extremely bad idea - as the x2 binary comes in two formats it is recommended that the portable-user carries both files as part of his setup - when on an x86 client system, he runs the x86 version, and x64 for x64, to accommodate programme shell extension compatibility, path-addressing, etc.* Remove OSBit check and used a simpler more efficient check. It simply runs xplorer2_64.exe if found and otherwise, will just use xplorer2_UC.exe
(As an x86 user you would not realise the many pitfalls which can arise from something which initially appears superficially simple. As an aside, this is one of the reasons it's almost unbelievable that your man has not moved heaven and earth to generate his own x64 version of xyplorer - compiler limitations or not - a file manager is not about any bland claims of "speed" or nonsense of memory-mapping (there is far more to x64 than memory); it is fundamentally important on the shell-level that the x64 integrity be respected and there simply is no excuse for not ensuring that. Any claim otherwise is misinformation: while an x86 process will indeed "run" just fine, it can't read the shell at all, and will also suffer the SYSWOW64 redirections on the path-resolution level which a power-user would find simply laughable. Reference this as an example where a user finds it difficult to understand even the explanation as to why he doesn't understand what he's actually looking at.)
Your previous method (of checking the OS bit-type) was perfectly acceptable as it would run the expected version appropriately. As it is now, if the user switches to an x86 system (and has both binaries as he should) it will always try to execute the x64 version and (if x86 OS) fail miserably. To circumvent this, the user would need to have two different runtime folders (and all that entails) with two different launch shortcuts, and he himself be aware of what the OS is beforehand (when most clients can't accurately tell you their own wive's true hair-colour, you can't trust what they might guess regarding OS bit-types).
As I said, this is my fault for not looking closer at the code from the 08-Aug-13 - I did not notice that you had commented out the bit-factoring function, otherwise I would have copped it sooner. Apologies.
I strongly suggest you restore the previous handler.
Statistics: Posted by Kilmatead — 2013 Aug 12, 21:58
]]>
]]>
But considering that EndCleanup() is nothing more than a removal of the 7za.exe, it looks rather like the Wipe() is executed regardless of a successful integrity check or not. I haven't intentionally created a fail-state to check it yet (in case PB is sneakier than I thought), but it doesn't look right.
Oh! I forgot the END statement. Looks like my sleepiness got to me 
The END statement is going to be inside the EndCleanup() so it's going to be like the original END statement but also remove 7za.exe become actually ending.*sigh I did not even think about this lol. Got to add this now too heh.Also, just after that (when setup is complete), you conveniently re-launch the program to save the user the trouble of clicking the shortcut again, except you forgot to pass any initially given arguments. Ain't minutia fun?
You hit exactly what I was most worried about when I woke up this morning. If I don't use APX, the file size for xp2KeyCrypt is like 700 KB. Kind of big. On the other hand, if I keep them separate like I did before, the UPX version of 7za does not trip any sort of virus flags (virustotal.com) and my own executable only trip 4 for being a packer. But if I combined them... it might be troublesome. However the results from virustotal are kind of positive but not sure yet haha. The heuristic might make it different.I have no doubt that many anti-virus toys will just love the idea of your binary unpacking another binary just to execute it - usually that sort of thing is reserved for static resources or DLL's. There's nothing wrong with doing it, and it is "cleaner" - but there may be pitfalls.On that same theme, if you're still playing with UPX compression, you'll note that that's one of the main causes of AutoIt/AHK scripts being flagged as evil-doers...
EDIT: I'm doing it this way now. UPX the 7za.exe executable and leave my program alone.
https://www.virustotal.com/en/file/a1e1 ... 375985143/
https://www.virustotal.com/en/file/0e57 ... 375985253/
So yeah, I might not go for it then. Going to have think more about it. On the other hand, X2.DAT being a 7-zip file is even less apparent with this method. Unless they pay attention now lol. Of course in terms of security, that means nothing.
Anyway I updated the binaries but it does not need testing I think. It's pretty much just that END statement being added so it's rather minor. I work on the other stuff later today when I get hope again haha.
EDIT: Ok. Now when you finish the first time encryption, it should now send the command-line arguments as well.
EDIT2: Link removed. The new executable and source is now in the first post.
Hahaha I feel down on XYplorer's forum for XYKeyCrypt. No feedback whatsoeverRegrettably x2's "scripting" is indeed a limited affair, forcing us to be more inventive than your average litter of kittens. Having an open and practical API is one of those things that never seemed to dawn on Nikos, and x2 suffers for it - but such is life. Considering that file managers are niche-products anyway, the actual percentage of users who would delve to such a level is virtually non-existent - so it's kind of a chicken-vs-egg argument. He did not exactly imagine 10 years ago when x2 was initially pushing kicking and screaming into this life that weirdo's like myself would be messing with its entrails.
xyplorer's quite impressive for a manager written in basic, but it can never seem to get away from the "shiny" impression of too many niche-requests being granted for the sake of customer relations, and not enough attention brought to the depth of the shell itself. The same applies to x2 in reverse - a little more thought put into fluffy GUI nonsense (because people like their fluffy) wouldn't hurt. But that's just my opinion - at the end of the day all file managers essentially do the same thing and the users are just quibbling about the paint-job. Besides, we're not here to play comparison games, enough of that goes on elsewhere. (Although I will point out that your own xyKeyCrypt seems to have suffered a lukewarm reception so far on that forum - no discussions of assembly, no humor, no suggestions... where's the fun? You'll need to work harder to wake them up, the grumpy bunch.)
. They don't seem to be interested in encryption in general though so two of my scripts (I wrote the other one in XY's language) that had to do with encryption did not get much reception. My other scripts get a lot of more response and help. *sigh Oh well, I'm going to force it out of them and be blunt about it "hey I need feedback!" 
.Actually Don's rather hard about implementing features lol. We have to spend a lot of time and prove to him that the feature is productive and is easy to use with customers that are now power users. If we can't convince him, we don't get the feature lol. It took us years before he finally agreed that basic zip support is useful. But yeah, I think it's extremely amazing how stable and good the program is yet it's written in Visual Basic. He fully prove that it's the programmer is the one that can work the magic with any language. On the other hand, the compiler is still an issue and therefore haven't figure out a good way to implement multi-threading and x64 version so that will continue to be the wall. It's expected though, all file managers have their own issues. Directory Opus is really really good but portability is a pain. And... it's huge. Very huge. But it's good! But it's huge. xplorer2 and XYPlorer are the lightweight ones and are the fun ones to take with you everywhere you go. Got stuck on a deserted island? Don't worry, you have xplorer2 and XYplorer ready to help you... and XYplorer can make coffee in the morning too if you need that.
Statistics: Posted by Enternal — 2013 Aug 08, 18:23
]]>
Code:
While ProgramRunning(Integrity7z) : : WendIf ExitCode = 2MessageRequester("xp2KeyCrypt Error " ... )EndCleanup()EndIfWipe("X2.LIC")Also, just after that (when setup is complete), you conveniently re-launch the program to save the user the trouble of clicking the shortcut again, except you forgot to pass any initially given arguments. Ain't minutia fun?
I have no doubt that many anti-virus toys will just love the idea of your binary unpacking another binary just to execute it - usually that sort of thing is reserved for static resources or DLL's. There's nothing wrong with doing it, and it is "cleaner" - but there may be pitfalls.
On that same theme, if you're still playing with UPX compression, you'll note that that's one of the main causes of AutoIt/AHK scripts being flagged as evil-doers...Regrettably x2's "scripting" is indeed a limited affair, forcing us to be more inventive than your average litter of kittens. Having an open and practical API is one of those things that never seemed to dawn on Nikos, and x2 suffers for it - but such is life. Considering that file managers are niche-products anyway, the actual percentage of users who would delve to such a level is virtually non-existent - so it's kind of a chicken-vs-egg argument. He did not exactly imagine 10 years ago when x2 was initially pushing kicking and screaming into this life that weirdo's like myself would be messing with its entrails.
xyplorer's quite impressive for a manager written in basic, but it can never seem to get away from the "shiny" impression of too many niche-requests being granted for the sake of customer relations, and not enough attention brought to the depth of the shell itself. The same applies to x2 in reverse - a little more thought put into fluffy GUI nonsense (because people like their fluffy) wouldn't hurt. But that's just my opinion - at the end of the day all file managers essentially do the same thing and the users are just quibbling about the paint-job. Besides, we're not here to play comparison games, enough of that goes on elsewhere. (Although I will point out that your own xyKeyCrypt seems to have suffered a lukewarm reception so far on that forum - no discussions of assembly, no humour, no suggestions... where's the fun? You'll need to work harder to wake them up, the grumpy bunch.
)Statistics: Posted by Kilmatead — 2013 Aug 08, 13:04
]]>
In the absence of a specific /P switch, that's exactly what I'm saying. (Never mind that I have no idea what would happen if one instance used the registry settings and the other one referenced its own INI. Hence the worms.)So you mean that if xplorer2_UC runs from C:\Users\ and another version run afterwards from I:\Users\, according to the system, both were run from C:\Users\? So basically what I'm trying to do will be useless?
Suggestion taken!Do.
Not.
Have.
Children.
When Helmuth von Moltke the Elder wrote "no plan survives contact with the enemy" he was thinking of you. Take his words to heart and save yourself some future ulcers.
Ok. It's been implemented. Good thing 7-zip already has the function built-in so I can just simply call it up to verify the archive's integrity! Now... I think I did something kind of cool. I have put the 7za binary information directly inside the file. So now whenever it starts, it will write 7za.exe in the running directory and when it finishes or exit for any reason, it will delete it. That reduce 2 executable down to 1! On the bad side, the overal executable size now is around 300 KB. Plus with that size, I can't really upload it onto the forum. So I guess I will make "two" version. One where they can download 7za themselves with xp2KeyCrypt uploaded to the forum. The other is the xp2KeyCrypt with 7za integrated which will be on Dropbox.Ok, thus far (not to be taken as future-proof) this revision of xp2KeyCrypt seems much more solid. The only concern I can see (aside from a few pointless Delay() calls) is at the end of "Setup" the LIC is destroyed after the 7za.exe converts it into the DAT - except there is no check that the DAT was successfully created.
For example, if the user (for whatever reason) did not have write-permission to that folder or an over-anxious security programme decided to choke up, the 7za.exe call would fail (silently or not) and the script would continue to (convincingly) destroy the existing LIC no matter what.
One could pedantically argue that if the user does not have write permission he probably wouldn't have delete permission either, but that's splitting hairs and forgetting how much sunspots and alien invasions actually influence our daily lives.
A wee check to verify DAT's existence would be nice, if not the integrity of the archive itself (you are, after all, destroying the user's only potential on-site copy of his or her key).
Lol! I already expected that.I will endeavour to find something else to break.
Hmmm... I think I'm still confused what you mean. Or it's probably because it's now 4am over here. I think I will go to sleep and think about it tomorrow... plus a RPG game is coming tomorrow so... lol. I might be a bit "busy".Addendum: Also, as an ergonomic suggestion, since you now are comfortable using the FindWindow_() results, and emulating a launcher, if the user attempts to launch another instance right now (and the LIC exists) you just have the programme exit (no extra instance is launched, as would be expected). But if the LIC does not exist, and an x2 instance is already active the poor user still has to go through all the trouble of laboriously typing in "Sør3nK13rk3gårdAndRumpelst1ltsk1nAreΛάθος" every time. This seems like an overly-anal policeman.
Oh, and a /Cappuccino command-line switch would be just dandy. Necessary even. Really. Withdrawal is setting in. I can feel it. The world is going dim...
I know this is an xplorer2 forum but XYplorer supports a really powerful scripting feature (as far as I can see, much more powerful than what xplorer2 or Directory Opus have to offer). One of the scripting commands though is somewhat of an easter but the command ":makecoffee" makes coffee for you!Anyway, I have uploaded the new binaries at: https://www.dropbox.com/sh/n73u54twqpzoko8/GdBtgdej9AIt's now stored with my XYplorer version since it makes it easier for me to keep track of all things in one location. Also you don't need to download 7za.exe since the new binaries have 7za integrated. *sigh I think I really need a break from this for a day or too lol.
Statistics: Posted by Enternal — 2013 Aug 08, 11:10
]]>
So you mean that if xplorer2_UC runs from C:\Users\ and another version run afterwards from I:\Users\, according to the system, both were run from C:\Users\? So basically what I'm trying to do will be useless?
In the absence of a specific /P switch, that's exactly what I'm saying. (Never mind that I have no idea what would happen if one instance used the registry settings and the other one referenced its own INI. Hence the worms.)Do.It's just I have a somewhat bad habit of trying to make sure things take into account of all possible situations that whatever I'm doing may encounter.
Not.
Have.
Children.
When Helmuth von Moltke the Elder wrote "no plan survives contact with the enemy" he was thinking of you. Take his words to heart and save yourself some future ulcers.
Ok, thus far (not to be taken as future-proof) this revision of xp2KeyCrypt seems much more solid. The only concern I can see (aside from a few pointless Delay() calls) is at the end of "Setup" the LIC is destroyed after the 7za.exe converts it into the DAT - except there is no check that the DAT was successfully created.
For example, if the user (for whatever reason) did not have write-permission to that folder or an over-anxious security programme decided to choke up, the 7za.exe call would fail (silently or not) and the script would continue to (convincingly) destroy the existing LIC no matter what.
One could pedantically argue that if the user does not have write permission he probably wouldn't have delete permission either, but that's splitting hairs and forgetting how much sunspots and alien invasions actually influence our daily lives.
A wee check to verify DAT's existence would be nice, if not the integrity of the archive itself (you are, after all, destroying the user's only potential on-site copy of his or her key).
I will endeavour to find something else to break.
Addendum: Also, as an ergonomic suggestion, since you now are comfortable using the FindWindow_() results, and emulating a launcher, if the user attempts to launch another instance right now (and the LIC exists) you just have the programme exit (no extra instance is launched, as would be expected). But if the LIC does not exist, and an x2 instance is already active the poor user still has to go through all the trouble of laboriously typing in "Sør3nK13rk3gårdAndRumpelst1ltsk1nAreΛάθος" every time. This seems like an overly-anal policeman.
Oh, and a /Cappuccino command-line switch would be just dandy. Necessary even. Really. Withdrawal is setting in. I can feel it. The world is going dim...
Statistics: Posted by Kilmatead — 2013 Aug 08, 07:05
]]>
Keep in mind that x2 will by default run as a shared-process unless the user specifically launches via the /P argument. That means that if no /P is designated then no matter where x2 is launched from (even a physically separate path) its aegis will automatically be subsumed by the existing process - although appearing to all the world as a separate instance.
So you mean that if xplorer2_UC runs from C:\Users\ and another version run afterwards from I:\Users\, according to the system, both were run from C:\Users\? So basically what I'm trying to do will be useless? Darn. I guess I might really need to stick with the Windows Class method instead...So... I'm opening up a can of worms? I think I agree... but temptations can be so hard to control at timesWhen incest is known to exist in a family tree, those little school projects about "Where Did You Come From?" the daughters announce at the dinner table are quietly and surreptitiously swept aside for the promise of a new dog and a trip to Coney Island, and never spoken of again.
One of the adages of programming (and, for that matter, masochism) is to calculate the value-to-return ratio - if it's not in your favour by natural design, call it an act of God and live to fight another day.
Personally (and I am in the minority here), I always give to the Benevolent Masochists Christmas Fund. Read into that what you may, though it usually involves the phrase "Can of Worms".
But if what you said above is true, then maybe I should not proceed...And you said this programming thing wasn't for you... seems your heart may not be listening to your brain.
Nah. It's just I have a somewhat bad habit of trying to make sure things take into account of all possible situations that whatever I'm doing may encounter. Right now I'm feeling really frustrated but I MUST make sure that the program does not fail under odd circumstances. Pretty much I'm making it harder for myself but... I really need to stop haha. The whole time when I was writing this program, I was thinking "What if the user does this? That? How about this? What if the program does this? that?". Ok I will need to force myself to stop... after I finish this writing this part of the prpogram EDIT: Ok. I decided not to do the path checking method for the xplorer2 version (the XYplorer use it due to how the users use it so it really needs that feature). Also I finally use the debugger to check and fix any other errors that might have shown up. That's actually my first time ever using a debugger so that was interesting and fun! Don't ask me why I never used it
. Anyway I have attach a semi-final version of it here so you can you please play with it and see if there are any other suggestions that you can give me. Other than that, I think I'm done now. 
LINK REMOVED. Up-To-Date Version Now Uploaded On First Post.
Statistics: Posted by Enternal — 2013 Aug 07, 22:14
]]>
So that means if you go to your friend's house and he/she has her own xplorer2 process going on, xp2KeyCrypt could know the difference since the process path will be different than the one you ran.
Keep in mind that x2 will by default run as a shared-process unless the user specifically launches via the /P argument. That means that if no /P is designated then no matter where x2 is launched from (even a physically separate path) its aegis will automatically be subsumed by the existing process - although appearing to all the world as a separate instance.When incest is known to exist in a family tree, those little school projects about "Where Did You Come From?" the daughters announce at the dinner table are quietly and surreptitiously swept aside for the promise of a new dog and a trip to Coney Island, and never spoken of again.
One of the adages of programming (and, for that matter, masochism) is to calculate the value-to-return ratio - if it's not in your favour by natural design, call it an act of God and live to fight another day.
Personally (and I am in the minority here), I always give to the Benevolent Masochists Christmas Fund. Read into that what you may, though it usually involves the phrase "Can of Worms".
And you said this programming thing wasn't for you... seems your heart may not be listening to your brain.
(Many projects, and many more illegitimate progeny, have been born from such a confluence of ills and vapours.)Statistics: Posted by Kilmatead — 2013 Aug 07, 19:33
]]>
Code:
FindWindow_("ATL:ExplorerFrame",0)However currently playing with another method that someone helped me which was another 100 lines of code. It can detect if the process being run matches up with the path. So that means if you go to your friend's house and he/she has her own xplorer2 process going on, xp2KeyCrypt could know the difference since the process path will be different than the one you ran. Still testing it though but it looks good.
Statistics: Posted by Enternal — 2013 Aug 07, 18:52
]]>
I am sure that Kilmatead could say it better than I have.
Hey, it's my job to play the fool around here - holding me to some imaginary standard will get you nowhere. Besides, I would imagine youngsters these days were all born after the apocryphal "640K ought to be enough for anybody" quote. As such, you'll never be able to sell them on the Art vs. Science interpretation any more than you could sell the Renaissance to Jacques de Molay.
To seek the ephemera is a religious quest - to understand it is an artistic one. Despite all the odds, there is yet hope for the coder's holy grail.
Statistics: Posted by Kilmatead — 2013 Aug 06, 20:16
]]>
If you have never written a program that required you to shave execution time or memory space in order to meet the specs, you probably will not understand what I am trying to say. However, if you had to write a program that had a specific set of requirements that had to fit in 512 bytes of memory, you might appreciate the need for efficiency. I am sure that Kilmatead could say it better than I have.
Statistics: Posted by drac — 2013 Aug 06, 18:33
]]>
To be fair, the only people who "need" to know assembly these days (aside from critical optimisations) are BIOS writers
... and security researchers, digging into undocumented code.Statistics: Posted by Tuxman — 2013 Aug 06, 14:36
]]>
Regarding xp2KeyCrypt, I'd say a little extra applied logic at startup wouldn't hurt either - only ask for LIC if LIC does not actually currently exist - one of the most common things when programmes are slow to start is for people to just keep clicking the launcher ("a watched kettle never boils", etc), and can end up with multiple password requests. I don't mind multiple instances of x2 itself, but xp2KeyCrypt could just as happily die all the deaths of Hamlet without the drama. After all, even if the parent process dies two seconds (ultimate efficiency) or two minutes after the initial launch, the end user is unlikely to notice the actual difference. Again, this sort of thing is more ergonomic than important, but while you're still tinkering, the cheap-seats will keep heckling and clambering for more...
Ok I added that simple logic (haven't uploaded the executable yet though since still seeing what else I can do) and that's an excellent idea. I would have never thought about that but when I think about, I do remember seeing it quite often when I was younger in school as well. People just don't have the patience at times lol. Anyway I'm just going to stick with the silently grumpy method for now while I continue to decide and tinker with the other stuff to see how it goes. I think I'm already spending waay to much time on this already which is not what I intended to do in the first place haha. The XYplorer version is still unfinished as well since I need to get Unicode working.My mechanical engineering professor hates the Arduino for that reason even though it's also C (albeit with a lot of new libraries). He said that C already comes with the true-and-tried libraries that were made long ago so he trusts them much more than those that comes with the Arduino which are "made by programmers who are motivated more by money than the stability of the libraries themselves" so he will only write hardware in pure C with the standard libraries and nothing else. As a result, his final projects for that class was really really time consuming yet we ended learning so much about the interfacing of electronics and mechanical systems. Plus C with the standard libraries are everywhere like you have said. So it's tested, tried, reliable, stable, and it works.For example, one of the reasons MS inadvertently shot itself in the foot (not for the first or last time) when it started introducing the .NET platform was that it encouraged programmers to use the library functions liberally (indeed, within the .NET environment you didn't have much choice). The problem was those libraries were buggy as hell and would crash and fail irregularly with very little the programmer himself could do about it without a lot of gymnastics.
Plus, technically speaking, virtually every language these days is usually written in C to begin with, either the compilers themselves or the interpreter modules - so it's just one more level of abstraction away from what people could be using (with, admittedly, a few extra trusted libraries) anyway. The odd thing is that many students are never told this until much later in the courses - when they loudly exclaim "Hey, C is just like Javascript!" - and pretty much everyone in ear-shot suddenly feels the urge to instantly kill themselves out of shame.
Does anyone even bother teaching (or studying) bootstrapping anymore? Or is it purely considered an intellectual exercise for the bored and the nostalgic? (Wait, don't answer that...
Bootstrapping? Like how one of the Ruby compiler projects involved writing the interpreter in Ruby itself? Nope I don't know
Statistics: Posted by Enternal — 2013 Aug 06, 11:28
]]>
I wasn't thinking so much in terms of people knowing how the hardware itself works for the language to be relevant - I was considering the implications of how design itself is approached (and limited) given the "easy" languages available....even if there's a lot of forking of languages, doesn't it seem that generally the useful and good ones are the one that succeed? The rest just become toys or past-time test drives as far as I can see. Or there's something I'm just missing?
For example, one of the reasons MS inadvertently shot itself in the foot (not for the first or last time) when it started introducing the .NET platform was that it encouraged programmers to use the library functions liberally (indeed, within the .NET environment you didn't have much choice). The problem was those libraries were buggy as hell and would crash and fail irregularly with very little the programmer himself could do about it without a lot of gymnastics.
Many languages suffer from this, with some people eschewing any form of library dependencies whatsoever - which is a bit of an extreme reaction, but if nothing else will teach people "how to think" about programming rather than just looking in the reference-index for a function that "looks good" and does all the work for them.
Plus, technically speaking, virtually every language these days is usually written in C to begin with, either the compilers themselves or the interpreter modules - so it's just one more level of abstraction away from what people could be using (with, admittedly, a few extra trusted libraries) anyway. The odd thing is that many students are never told this until much later in the courses - when they loudly exclaim "Hey, C is just like Javascript!" - and pretty much everyone in ear-shot suddenly feels the urge to instantly kill themselves out of shame.
Does anyone even bother teaching (or studying) bootstrapping anymore? Or is it purely considered an intellectual exercise for the bored and the nostalgic? (Wait, don't answer that...
)Statistics: Posted by Kilmatead — 2013 Aug 06, 10:21
]]>