i am trying to find the best compilers (if they are actually available) for the following languages:
ALGOL 60
TRAC
TELCOMP
Superplan
BACAIC
i don't know if any of these are still around, but it would be very helpful to get any feedback on where i could locate these.
Try Eric Raymond's retrocomputing museum. It at least has Algol 60 and Trac, along with other languages.
Of course, most of the original compilers ran on machines that are no longer in existence, but the museum also has a PDP-8 emulator.
David's post went in as mine was being written ... so vote him up!
--
ALGOL 60 and Trac (among many others - but not the other 3 on your list) can be found at The Retrocomputing Museum:
http://www.catb.org/retro/
You didn't mention any specific platforms but, there is an ALGOL 60 compiler for DOS available at the link below. A compiler, an interpreter, and the source are available.
http://www.angelfire.com/biz/rhaminisys/algol60.html
There is a free Algol 60 interpreter/compiler here.
TRAC was tricky because there's a newer CMS/bug tracker known as TRAC, but I did find one Trac compiler written in Perl.
I was unable to come up with any links for TELCOMP, superplan or BACAIC. Good luck :)
An extended version of Algol 60 is still used on the Clearpath line of computers from Unisys.
Many of the system utilities (including all the language compilers) are written in this extended version of Algol. The various variants of this language are the nearest thing these machine have to an assembler language! Here is a reference to the current manual.
Clearpath Enterprise Server Algol Programming Reference Manual
Burroughs Extended Algol for the B5500 is available as part of a complete B5500 emulator implemented in JavaScript, running in the Chrome browser. Project description and links to the code at http://www.retrocomputingtasmania.com/home/projects/burroughs-b5500
Related
I was just curious if anyone knew whether JSR 354 will have an official implementation as part of any future JDK.
JDK 11 JavaDocs
JSR354 Reference Implementation
When I search JDK 11 docs online - it doesn't look like Monetary and MonetaryAmount classes aren't included. But the implementation of JSR 354 exists in Github under jsr354-ri.
Does it mean that I can write my own implementation, if I don't want to follow the reference implementation? My purpose is to support additional currencies e.g. Chinese Yuan Renminbi (Offshore) CNH which has no official ISO recognition, but it's well known.
Thanks,
Thanks for the input so far. As one of the designated new Maintenance Leads (also see Transfer Ballot) allow me to give a more formal answer from our side.
As you may know, Oracle has removed many features from Java 11, JavaFX probably the most prominent "victim" which was released into an Open Source ecosystem backed by a couple of other companies, a few Oracle employees and other members of the community.
JavaMoney, the wider project behind JSR 354 and some of its extensions has always played a similar role. After the Transfer Ballot, there is one company (Trivadis) and 2 Individual EG Members as Maintenance Leads. Plus a lot of others contributed extensions including large names like Red Hat or Zalando.
So JSR 354 and a likely follow-up (aka JavaMoney 2.x) compliment Java SE similar to how OpenJFX, Apache NetBeans or other Open Community efforts do without being an integral part of the JDK. I spoke to an Oracle employee familiar with OpenJDK at Eclipse Community Day and he confirmed, this was also in Oracle's interest to focus on core features of the JDK while other vendors and communities provide additional features around it.
Plus with a future Money JSR under the "iterative" release plan developed for the JDK itself, but open to an other JSR we plan to offer regular releases at a pace that matches the needs of the community. Should say Italy or another country lose its place in the Eurozone due to excessive debt or another "Brexit" like situation happen, then currencies for those countries will change. And an independent Money JSR can immediately respond to that by providing the necessary changes without having to wait for the JDK.
Initially JavaMoney was targeted to be included into JDK but then it was decided to make it as JavaEE spec. As you may know starting from JDK11 the JavaEE classes aren't a part of JDK and they should be installed as any other usual dependency i.e. via Maven.
Yes, you can add any custom currencies and this is supported out of the box. You need to add an instance of CurrencyProviderSpi as described in the tutorial Registering Custom Currencies.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 8 years ago.
Improve this question
I want to write an open-source tool for use by developers. I want to eliminate entry barriers, so if they like the idea, they just get the tool and start playing with it.
In particular, I don't want an "Oh, should I also install 200Mb of ThatLanguage runtime libraries? Oh, so they don't build on my latest version of Linux?" entry barrier.
Should I write this tool in C, then? Or is Python, or Java, or whatever, already sufficiently widespread to not worry about this sort of things altogether (everyone already has them installed)?
Well, of course I know that they are freaking hugely widespread, but still - are there any major benefits to writing a super-lightweight zero-dependency tool, or am I being too much of a perfectionist?
Just write it first. If it is worth it people will use it.
Beyond that, (almost) everyone has Java, Python, and Ruby installed (especially devs). Some languages are still esoteric enough that it might not be worth it for 'that one app' (erlang, haskell, etc.).
Just write it though, that's the important part. From there it can be ported, rewritten, adopted, but none of that can happen if the tool isn't written first.
It won't help if people don't know C.
If you write your own DSL, you can have people use that API and not worry about which language you choose.
Write it in whatever common language you like. Everybody has installed .NET framework or JVM. The only difference between your C approach and Java or C# is, that you would link additional libraries directly to your program (opposed to standard libraries).
On the other hand I would hesitate to write it in some exotic language, for example smalltalk, because normal user does not know what is it squak or smalltalk itself and could be worried about installing the wierd thing :-).
I also think, that you should be concerned more about developers, because you write, you want it to be open source. I dont know anyone, who wants to write his own Swing, Spring or any other framework just to be independent of something. Also its (usually) much faster and easier to write it in JIT Language, than to code it in assembler...
I'm going to suggest what Reese suggested but take a slightly different approach: write it first, preferably in a language that allows you to quickly prototype and develop your program. Then, and this is the most important part, document the protocal you've developed.
I'm giving this advice because you mentioned that your "application" may later have bindings in lots of different languages and it is a client/server architecture. Well, two of the biggest applications in the world started out like this.
Bittorrent started out as Python code. This allowed very quick prototyping of the concept to get it working. The main thing that it had going for it was that the original code was well written and well documented. This later on allowed other people to port the protocol to other languages.
HTTP and HTML is an even bigger success story and started out with an even less popular language at the time it was written: objective-C. Even better than bittorrent, the protocol itself is very simple and very well documented. People didn't care that the original implementation was in a language that they've never seen before that uses square brackets in strange ways on a NeXT cube. The concept and execution was good and people quickly ported it to their favourite programming languages. Again, objective-C was chosen to aid in quick prototyping. Legend has it that the original implementation was written in just a couple of days.
I would say yes, you have to write it in C. If it were written in any language other than C (except perhaps C++ or Perl), I would definitely stop to consider whether the necessary build tools, runtime tools, and/or interpreter for that language would be available everywhere I might need the tool before getting myself dependent upon it. If the tool were meant for use in build scripts, I would consider it a complete show-stopper, since I can't expect anyone who wants to build my software to have random arbitrary language environments installed.
The reason I mentioned C++ and Perl as exceptions is that they're both largely portable in a formal sense. They have implementations that work without significant ties to the host implementation, and can be built not just on any current popular system but on any system that remotely adheres to standards. Python is quite the opposite, with strong dependencies on the underlying system's dynamic loader; I've been completely unable to get Python to work on various systems that only support static linking.
ocaml is another possible choice that has a very portable implementation, but it's not widely installed and people who aren't familiar with it tend to frown on it for no good reason.
If you write your program in C, then you will have the dependency of the platform (Windows != Linux != AIX, etc). If you are talking only about writing this tool for one OS, or rather THE OS (Linux;-), then I think that you can have a reasonable amount of confidence that your app will work on almost any system, especially if you use an Open Source language. If you want to run the app on Windows, I wouldn't count on any of those languages being installed on the host system. Your highest confidence across platforms will be with Java.
If possible you could use the lightest weight framework possible and put it online, where it can be viewed in a browser. What does your app do? Would it work as a web app?
I would suggest go for Delphi. If you want to make it portable, you can do it since most of the Delphi code is kylix compatible.
I wish to create shareware software that contains a registration algorithm. I am looking for a programming language, that cannot be easily decompiled into readable code. For example, C# can be decompiled into readable code.
What are my options?
Edit: I'm looking for something that can be only decompiled into assembly. Delphi, for example, cannot be decompiled like C# or Java, but from what I've heard, Delphi is dying.
Delphi is not dying, it is alive and well.
As is the community, at delphifeeds.
You can also see more delphi projects, Freeware, shareware and commercial at the Delphi Wikia.
Thus I'd say Delphi is a very good choice for Software Development. Freeware, Shareware or Commercial.
Update:
On September 1st 2011 Embarcadero released Rad Studio XE2. This released adds 64 Bit Compilation, Livebindings, Native Mac OSX compiling, IOS (via XCode) and a whole lot more to the already powerful delphi Dev environment.
If your CPU is able to see the code and run it, by definition, a sufficiently talented person can do it too.
You can, however, make it harder by running your code through an obfuscator.
I'd suggest the language of business and economics can protect your program.
If you are targeting consumers, and price it at say $10, almost all people would find it easier to pay you the $10 vs going into your program and reverse engineering it.
If you are targeting corporations, and say pricing it at $10,000, it just has to be easier to get the purchasing department to approve the payment than to reverse engineer your code. For real companies who would purchase your product, it's not worth the audit risk to have unlicensed code running.
Lastly, what are the costs/benefits of protecting your code? If you write your program in assembly instead of C#, you might have far higher production costs, while reducing the chance of reverse engineering. However, does this cost outweigh the potential lost sales? Could this time be better spent adding value for people who will buy the product? Generally, trying to sell your product to people who are never pay for software is not a economic strategy.
You could write it in Perl.
(I kid, I kid! Put down the pitchforks!)
As the others said, Delphi is NOT dying.
As the others said, there is no bulletproof method.
As the others said, there are tools to make the life of a cracker much harder.
But what the others didn't say is:
Java, .NET (etc.) obfuscation is rather a toy compared with obfuscation toys for eg. Delphi and other native solutions. (of course YMMV)
A very good technology to relatively protect your executable can be found here.
Repeat after me: "Obscurity is not security."
You would be better off using a hard encryption algorithm (where "hard" doesn't mean "difficult", but "not bi-directional; not easily reversible".
Isn't this logically impossible?
If you can run the code, you can get the instructions being executed by your CPU. At that point, your algorithm is readable, for some definitions of readable.
No language is capable of that AFAIK.. since it's impossible as it can always be reverse engineered.. though a good number of developers would cry if you coded it in brainfvck though.
"I'm looking for something that can be only decompiled into assembly."
Try writing your program in assembly. That is the best possible solution.
if you really concern about people disassemble your software, make your software as a service (SaaS) http://en.wikipedia.org/wiki/Software_as_a_service
Try finding an obfuscator. As the name suggests it obfuscates the code enough that reverse-engineering it will not be trivial.
Or use C/C++. Those can be disassembled, but that's it.
Of course, this is just enough to keep the not-sufficiently-competents from understanding and reverse-engineering the code.
As Dominic said, if you can run it, it can be decompiled.
That said, I believe there are tools that obfuscate the compiled code and make it more difficult for someone to disassemble and reverse or take apart a registration process.
For example, I believe that major companies like Adobe and Microsoft use products like this, in order to make it much more difficult for folks to disassemble and crack their programs.
It's like security or cryptography or even the locks on your car/house - someone with enough time and resources can probably break through anything.
You just need to tilt the curve enough to make it sufficiently unattractive for anyone to really try, so that they'd be more likely to move onto easier targets.
I am going to make the assumption that because you're writing shareware and you mention a registration algorithm you are wanting to protect your software from a keygen or patch that bypasses the restrictions on your trial versions.
Really the most you can do is deter. Like others have mentioned there are obfuscation techniques available, but they are not preventative. There are commercial software packers available which compress the file and make it initially unreadable. But the program has to be decompressed at some point so the machine can run it, so it's still reversible.
And that is pretty much the crutch against any of the anti-reversing techniques you'll see. It has to be interpreted by the machine at some point. More modern packers use anti-debugging techniques to deter the more novice reversers. But these techniques end up being documented rather quickly on popular reversing sites. Many of the techniques are bypassed with nothing more than a simple debugger plugin.
The only way I can think of to protect your executable from being arbitrarily reversed is to run the whole thing on a server you control and just pipe the output to users. But that's not always feasible.
As far as your language options go, take a loot at this. I can't really speak to how complete it is but I'm sure some others can add languages they think of.
If you're lookig "for something that can be only decompiled into assembly", that essentially means that you want to use a language that gets compiled (or assembled) directly into a native code executable.
The usual prime suspects then are C, C++, Delphi, VB6. Of course, also assembly meets your criteria, although I doubt you'd want to write any project of decent size in it.
Very simple:
No Programminglanguage,No Programm can Protect your Software.
The Software Cracker will reversengine your App till it is just asembler and will crackt it.
All code can be read back in assembly. Someone can reverse engineer your application and see what the machine is doing.
This is not so much a matter of choosing the right language as it is finding a tool that will do code obfuscation for you. Nothing is bulletproof, but there are efforts to accomplish this sort of thing.
Eg. see this research project about Java code obfuscation.
You can't be 100% sure nobody will able to read your code, but you can make it very hard. You can encrypt your code and modify it during run time.
For example I have not heard of any successful attempts to reverse engineering Skype.
You could always write it in APL. You could deliver the source and still no one would be able to understand it.
Any code running on client-side can be reverse engineered with enough trial and error. In my opinion, make the client-side code contain only the GUI code, while running the actual security requiring authentications etc. on serverside.
On the other hand, if your app's a service which runs on the client-side, such as a game, CAD, POS or anything that needs to have high quality code on the client-side, I'd recommend storing process outputs on your server-side with an encrypted upload tool, then authenticate the client's key/account data every-time before sending their data back? It is an overkill for most projects though.
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
Questions asking us to recommend or find a tool, library or favorite off-site resource are off-topic for Stack Overflow as they tend to attract opinionated answers and spam. Instead, describe the problem and what has been done so far to solve it.
Closed 8 years ago.
Improve this question
One of my modules at university next year is going to involve programming in Tcl tk, I was wondering where to find the best resources and information about the language, so that I am well prepared. I'm currently looking on this site which is pretty helpful, but the book that they recommend is quite old, and I was wondering if someone could recommend any other books to purchase or if the language hasn't changed significantly since the release of the book in 1999?
Also, what projects or examples should I start working on to make me familiar with the language?
Any other information would be extremely helpful and appreciated!
I posted this question because I couldn't find any others similar too it, apologies if I haven't looked hard enough.
Thanks in advance,
Some of the books I have in my library that you might find useful are:
Tcl and the Tk Toolkit (Ousterhout) - The book on Tcl/Tk, and probably the one you're referring to. It's old and some of the information is a bit out-dated, but it is fantastic (and, I believe, I say that without exaggerating) at showing how to program in Tcl. It was written by the originator of the language.
Practical Programming in Tcl and Tk (Welch) - The other book on Tcl/Tk that nearly everyone that programs in it seriously has in their library. Brent did an amazing job on this book.
Effective Tcl/Tk Programming: Writing Better Programs with Tcl and Tk (Harrison, McLennon) - Once you get to larger, more complex, programs, this book can be very handy to have read. It goes into organization and the like. This book is likely beyond what you need at the moment, but I mention it because it's a very good read as you get deeper into Tcl.
It's also worth bookmarking the Tcler's Wiki. It can feel a bit unorganized at times, but there's more information there than... well, anywhere. It's an amazing resource.
The ActiveTcl distribution is, indeed the way to go. The folks over at ActiveState are a smart bunch.
Are you familiar with the Active Tcl distribution? If not, then this is the best place to start looking for resources and documentation.
You can also try TclTutor interactive application where you can not only learn the materail but also try it at once.
I also recommend Tcl and the Tk Toolkit. It is great for understanding the core of Tcl, though I can't comment on how useful it is as a reference (I use the online documentation for that). The second edition of Tcl and the Tk Toolkit is currently available as a "Rough Cut" from Safari Books Online (meaning that you can download a draft PDF now and a final PDF when the book is released). They seem to have added a bunch of information about Tk, especially the themed widgets that were introduced in 8.5. They also added some information to the section about Tcl, including dictionaries.
but the book that they recommend is quite old,
The fact about tcl is, it is quite old, the book by Ousterhout is still the best book on tcl (and IMHO, almost a classic). There was never even a second edition although one is apparently in the making. tcl was a great idea at the time and it doesn't really hurt to learn it, but it hasn't kept up and frankly had a lot of design issues from the start.
Don't get me wrong, I was a huge fan of tcl back in the day, but it's not the best thing to be learning now. If you decide to carry-on, pick up a used copy of the original book and use the online resources.
The original purpose of tcl was to be easy and free enough to eliminate the need for the myriad of home-grown command languages that folks were writing to add interactivity to their applications. Later, the Tk toolkit was added and it was the easiest, free way to add a GUI to an application.
Today, there are a lot more options available (for example for GUI's the Qt toolkit is now under the LGPL therefore almost as free at Tk.
For adding a command line interface to an existing C / C++ application, the closest modern tool is Lua, but even more powerful languages like ruby and python are not much harder to integrate with C/ C++ applications (especially with tools like boost python and SWIG).
An second edition of Ousterhout's book, updated and augmented by Ken Jones, is available. It has a release year of 2010, so the second edition is pretty current. Also, the wiki page http://wiki.tcl.tk/57 has a list of a number of books that deal with Tcl in some capacity.
Use this invaluable reference guide or this more up-to-date quick ref (thanks to Colin Macleod).
Able to program in Tcl may not land you a job, but it certainly can help you to get the work done fast. I learned Tcl back in 1996 and Tcl is still one of my favorite programming languages in solving most of my daily sys admin work. In most cases, I am able to accomplish the same task when my programming colleagues are still on the drawing board designing the object classes.
Besides from the great suggestions from other comments, I just have to add Tcl for Web Nerd by Philip Greenspun, the creator of the Tcl-based framework ACS (which later became OpenACS).
There is plenty of information on the Tcl Wiki, though it can be hard to find things. A look at the Recent Changes page will show that there's plenty of activity going on.
I have learnt it through Practical Programming in TCL/TK. It is a very good. Along with that TCL-TK toolkit book was also very helpful.
The most recent book I know of is Clif Flynt's Tcl/Tk: a developer's guide. The third edition was published in 2012 by Morgan Kaufman and it covers the (as I'm writing this answer) current version of Tcl: 8.6.
I've only had the book in my house for a week, but it looks to be quite thorough and I like what I've read so far.
I own and have read both Ousterhout's Tcl and the Tk Toolkit and Welch's Practical Programming in Tcl and Tk (2nd Ed) and I liked them both. But Tcl seems to have come a long way since my copy of Welch's was published and a very long way since Ousterhout's. There are some really important/nice things that have been added to the core language/library.
(Incidentally, I also thought the new paperback price was extremely reasonable on Amazon for an almost 800 page tome.)
So, I'm looking at using Smalltalk/Squeak for a couple of hobby/academic interest projects, and while trying to read up on the language I came across this nice article. However, this paragraph had me a bit dumbfounded:
"Unfortunately, there is a complete lack of standardization for providing or dealing with modules/packages in Smalltalk. Some dialects provide very strong, comprehensive support for modules/packages (including versioning and distributed access by programming teams,) and other dialects provide little or nothing in this regard. Some dialects provide a robust implementation of multiple, shareable namespaces, others don't. The only commonality is that, when either modules/packages or namespaces are provided, they are implemented as reified objects, in the same way that classes and methods are implemented as reified objects."
So, I have tried googling for it, and this shows up on the Squeak wiki: http://wiki.squeak.org/squeak/734. Does anyone know if this (or something similar) is now part of the standard distribution?
As Mue says, it is not perceived as a big problem in the Squeak community. Prefixing is "good enough". A while back I tried hard to do something better and still maintain the unique feeling of Smalltalk:
http://swiki.krampe.se/gohu/32
...but even though lots of people thought it was nice it didn't catch on. Code more or less works though, but there are several other approaches too - unfortunately most of them just copy some stupid approach from a lesser language thus destroying the feeling of Smalltalk.
Namespaces are not part of Squeak today. But it's a common agreement to prefix all classes of the own project with two or three letters. That's not as save as real namespaces, but it's leightweighted, simple, and works. +smile+
The Google Summer of Code supported a namespace project called Environments. Chris Cunnington is currently investigating it, but he says it looks promising.
Not necessariy related except by name, Squeak 4.5 has a taken another run at the problem, with Colin Putney's Environments package.
Sounds like you should check out Newspeak.