I am thinking about buying an iPod touch and I Wonder if there is Java and c++ editor to install in the iPod, something like having netbeans in the IPod. I want this because I would like to advance in my home-works on my way college-home while I'm on the bus or waiting for someone, etc. Is there anything?
Don't even consider trying to write code on an iPod, or even an iPad.
iPod is the wrong type of device for any sort of development. There are some ergonomic factors which are really important when it comes to writing code:
You should have a decent keyboard - i-devices only have touch-screens. A laptop keyboard is OK but not great.
You need the screen at a reasonable height and angle if you're going to be looking at it for a long time. You need to be able to type with both hands at the same time.
You need as much screen space as you can get.
I could come up with a lot more reasons for not using an i-device for development, but I think they are too obvious to bother listing.
If you really want to do your homework on the bus, you are better off getting yourself a decent laptop.
The iTunes App Store restrictions explicitly prohibit any compilers or interpreters from running on approved iOS apps.
That said, you could make a simple Javascript interpreter in a webpage, and then save it for offline use, without much trouble.
For that matter, any language that's implemented in Javascript and can work in an offline webpage could be used. For example, if you had a compiler written in Javascript, which compiled C++ to Javascript, then you could use that to write C++ on your iPod. I do not know of any such compilers offhand, but there's no theoretical reason they couldn't exist, as the App Store restrictions don't apply to HTML pages you browse to yourself.
A far more practical solution would be to just get a text editor (of which the App Store has many). Write your code on the bus, and then compile it when you get home. It will still be faster than the compilers we had when I was a kid!
(Or just get an SRS and spend the time studying rather than programming, since you're not going to be very effective at programming on a small touchscreen device, anyway.)
There's always an option to jailbreak your device and install GCC toolchain: iphone-gcc in Cydia and instruction here. Netbook would be a much better option though.
You can do some basic HTML and Latex but no Java or C++.
But I found something that could be interesting:
Processing is quite like Java and can be programmed on this site, with every iDevice.
http://jepstone.net/HiperPad/editor.php/HiPad4d113f1595b4c#home
Related
OK, so I recently purchased an Acer T232HL touch screen display to hook up to my Macbook Pro as a secondary monitor. To give you an idea, here's my setup.
OS X doesn't support this monitor in any way, so as you can see in the screenshot I'm actually running Windows 8 through VMware, which proxies the USB connection to Windows perfectly where the touch events are supported. But obviously this isn't ideal.
There's at least one 3rd party driver for OS X that looked sort of promising, but it doesn't seem to support multitouch from this device, it's expensive, and generally was a pain to get working to the small degree it was. There's also mt4j but best I could tell after running their examples, it doesn't support this device at all.
So here's my question: what exactly am I in for if I wanted to write a driver for this thing? I'm mostly a web developer with years of experience with Ruby, Objective-C (and a little C), Javascript, etc. I have never ventured into any kind of hardware programming, so from the surface this feels like an interesting while intimidating challenge.
I know at some level I need to read data from USB. I know this will probably mean trying to reverse engineer whatever protocol they're using for the touch events (is it possible this will be entirely custom?). However I haven't got a clue where to start - would this be a kernel extension? In C, I presume? Would love a high level overview of the moving parts involved here.
Ultimately I want to use the touch screen to drive a specialized web interface (running in Chrome), so ideally I could proxy the touch events straight to Chrome without the OS actually moving the mouse cursor to the touch location (so have the UI behave just as it would on an iPad), but regardless of whether this is technically possible, I'd love to start with just getting something working.
You're going to want to start with Apple's I/O Kit documentation. You can hope that the touchscreen isn't completely custom, though there must be some part that's not standard USB HID, or it would work already. If there are any linux (or other open source) drivers available, you'll have the advantage that somebody already did some of the reverse engineering for you. As an alternative to the I/O Kit, you might also want to look into libusb, which might make your brain hurt less when getting started. If you end up needing to write a kext, that might not help you anymore, though.
As to some of your specific questions:
would this be a kernel extension?
Maybe, maybe not. I'm not really up on the Mac OS X driver situation, but I did write some totally user-space USB code for OS X many years ago. Maybe you'll be as lucky.
In C, I presume?
Probably. I/O Kit itself is written in a subset of C++, so you can probably use that too, if you prefer.
is it possible this will be entirely custom?
Unfortunately, yes, it's possible.
Good luck!
So, some background: I'm using a memory scanner called cheat engine to get real-time values for game stats (e.g. hp, mana, exp) in a non open-source video game that I'm trying to make a bot for.
For my bot to effectively use this information, I need to get it from cheat engine (or any memory scanner with similar functionality) to my bot code in a timely manner.
Now, one obvious way to do that would be to save all of the information to a file and then load the file in my bot code, but since this data needs updating about every half second or so, that isn't a real solution.
What I really need is either a terribly convenient memory scanner that allows you to use the information you uncover as a set of variables in some programming language (preferably java, c, or matlab), or a way to access the memory addresses found in one of the above languages.
This latter option should hopefully be doable, as cheat engine gives the memory address, controlling process ID, and data type.
This question doesn't have an easy answer. As far as I can tell you are very new to this area, so what you really need is a proper introduction to the subject, and for that I recommend reading Exploiting Online Games: Cheating Massively Distributed Systems.
It's an awesome book and it shows in a detailed manner how game hacks work, and it dedicates an entire chapter on how to build bots.
If you want to write an application to read/write data to those memory addresses you need to investigate functions like ReadProcessMemory() and WriteProcessMemory(). Whatever language you to choose to implement your bot needs to provide access to the Windows API. This is needed because you have to manipulate another process' memory space.
There are lots of tutorials out there that shows how to do this using C and C++, since they are the preferred languages to do this kind of stuff. Another option is to use a macro tool if you want something simple to play the game for you.
Modern computer games implement their own anti-cheat mechanisms to make it a little more difficult for people like you (and me). And since this book presents attack and defense techniques I recommend it to anyone interested on how to exploit computer games. The book is fully loaded with code examples.
I'm sorry for not providing more information but I was criticized once in the past for helping people with your curiosity and I would also never do a better job than the authors of the book explaining how to do this stuff.
Try using the Lua interface to get what you need.
Here's an example (I have not tried it, but I'm assuming it works....)
http://forum.cheatengine.org/viewtopic.php?t=530047
You can probably use COM with a script in Lua (with LuaCOM) on one side and Matlab or C on the other
You would need to use a debugging library to do that. You would set a watchpoint on your variable's location, and when it triggers, you would get its value.
scanmem does that for Linux.
Unfortunately, many closed-source games go to great lengths to avoid the use of debuggers, so this won't probably work on your game.
Have you tried Visual VM?
http://visualvm.java.net/download.html
Cheat Engine is open source, so what you do is look in the source code of Cheat Engine, and look how the memory dump thing works.
However, it is highly non-trivial to monitor a live process that you are not controlling, so unless you are a black hat code wizard, level 11, I suspect that it won't work.
Even if You say You want to look at a few integers that you can guess looking at memory dump, it is a lot harder to find that area programmatically, consistently, while possibly retracking every so often as the data may be copied or moved when the state of the program changes.
Also read this encouraging citation from Cheat Engines FAQ:
Q:Will Cheat Engine work on online games?
A:Most of the time, no
But anyway, try it - it sounds fun and I am sure you will learn something, and there is always a chance that you'll make it work :-)
I need to port a C library to Java so it can run on the Blackberry platform (mobile, native application). The options I am considering are:
bytecode conversion (cibyl, etc)
Complete port
Wrap C code around Java using JNA (would this even work for Blackberry?)
Please let me know which option is best. thanks
Aha. Some quick googling says "No, JNI does not work for blackberry" source:
http://supportforums.blackberry.com/t5/Java-Development/Can-we-use-JNI-Java-Native-Interface-approach-in-Blackberry/m-p/365362
http://supportforums.blackberry.com/t5/Java-Development/JNI/m-p/41140.
So you're stuck with bytecode conversion and complete port. Since I have no idea what bytecode conversion is, I'd go with a complete port, so long as you are familiar with both languages. If you can define bytecode conversion for me, I might be able to give you a better answer.
We also have an in-house developed C library for core functionality of our iOS and Android apps.
I asked about using cibyl to run this on BlackBerry in the form of a .jar and the good news is that it's possible: https://twitter.com/#!/simonkagstrom/status/114581622833152000 [backup of the tweet: "Sure, that's how #waze on the blackberry works."]
You can also try MoSync: http://twitter.com/#!/MoSync/status/115088826430533632 [backup of this one: "Yup, you can use MoSync for BB. There's "experimental" Blackberry support in MoSync 2.6, already used in live apps!"]
And David A Roberts, developer of LLJVM sent me this: "I'm not familiar with BlackBerry development, but I see no obvious reason why LLJVM wouldn't work, so long as the library doesn't rely too much on things like the C POSIX library (e.g. dirent.h, etc) - I
never got around to implementing this fully. Otherwise LLJVM would need to be updated suitably..."
Side note: BlackBerry's new Tablet OS and planned BBX phones actually have a native SDK but this QNX based stuff is quite unpopular. We just need to wait if BBX is going to become a success since Java based solutions are just too much risks.
a previous relevant question from me is here Reverse Engineering old paint programs
I have set up my base of operations here: http://animatorpro.org
wiki coming soon.
Okay, so now I have a 300,000 line legacy MSDOS codebase. It's sort of a "be careful what you wish for" situation. I am not an experienced C programmer. I'm not entirely inexperienced either, but for all intents and purposes I'm a noob to the language and in particular the intricacies of its libraries. I am especially ignorant of the vagaries of the differences between C programs written specifically for MSDOS and programs that are cross platform. However I have been studying this code base for over a year now, and this is what I know about Animator Pro:
Compilers and tools used:
Watcom C compiler
tcmake (make program from Turbo C)
386asm, a specialised assembler for the Phar Lap dos extender
and of course, the Phar Lap dos extender itself.
a selection of obscure dos utilities
Much of the compilation seems to be driven by batch files. Though I have obtained copies of all these tools, I have not yet succeeded at compiling it. (though I have compiled its older brother, autodesk animator original.
It's got a plugin system that replicates DLL before DLL's were available, based on REX. The plugin system handles:
Video Drivers (with a plethora of included VESA drivers)
Input drivers (including wacom tablets, and keyboards)
Drawing Tools
Inks (Like photoshop's filters, or blending modes)
Scripting Addons (essentially compiled scripts)
File formats
It's got its own script interpreter named POCO, based on the C language- The scripting language has enough power to do virtually all the things the plugin system can do- Just slower.
Given this information, this is my development plan. Please criticise this. The source code is available in the link above, so you can easily, if you are so inclined, assess the situation yourself.
Compile with its original tools.
Switch to using DJGPP, and make the necessary changes to get it to compile with that, plus the original assembler.
Include the Allegro.cc "Game" library, and switch over as much functionality to that library as possible- Perhaps by simply writing new video and input drivers that use the Allegro API. I'm thinking allegro rather than SDL because: there is a DOS version of Allegro, and fascinatingly, one of its core functions is the ability to play Animator Pro's native format FLIC.
Hopefully after 3, I will have eliminated most or all of the Assembler in the project. I say hopefully, because it's in an obscure dialect that doesn't assemble in any modern free assembler without significant modification. I have tried them all. Whatever is left gets converted to assemble in NASM, or to C code if I can define the assembler's actual function.
Switch the dos extender from Phar Lap to HX Dos http://www.japheth.de/HX.html, Which promises to replicate as much of the WIN32 api as possible. Then make all the necessary code changes for that to work.
Switch to the win32 version of Allegro.cc, assuming that the win32 version can run on top of HXDos. Make any further necessary changes
Modify the plugin system to use some kind of standard cross platform plugin library. What this would be, I have no idea. Maybe you can offer some suggestions? I talked to the developer who originally wrote the plugin system, and he said some of the things it does aren't possible on modern OS's because of segmentation restrictions. I'm not sure what this means, but I'm guessing it means all the plugins will need to be rewritten almost from scratch.
Magically, I got all the above done, and we can try and make it run in windows, osx, and linux, whilst dealing with other cross platform niggles like long file names, and things I haven't thought of.
Anyone got a problem with any of this? Is allegro a good choice? if not, why? what would you do about this plugin system? What would you do different? Is this whole thing foolish, and should I just rewrite it from scratch, using the original as inpiration? (it would apparently take the original developer "About a month" to do that)
One thing I haven't covered above is the text/font system. Not sure what to do about that, but Animator Pro has its own custom font format, but also is able to use Postscript Type 1 fonts, and some other formats.
My biggest concern with your plan, in a nutshell: Your approach seems to be to attempt to keep the whole enormous thing working at all times, tweaking the environment ever-further away from DOS. During each tweak to the environment, that means you will have approximately a billion subtle assumptions that might have broken at once, none of which you necessarily understand yet. Untangling them all at once will be incredibly painful.
If I were doing the port, my approach would be to disable as much code as possible to get SOMETHING running in a modern environment, and bring the parts back online, one piece at a time. Write a simple test harness program that loads a display driver and draws some stuff, and compile it for DOS to make sure you understand the interface. Then write some C code that implements the same interface, but with Allegro (or SDL or SFML), and make that program work under Windows or Linux. When the output differs, you have a simple test case to work from.
Your entire job on this port is swapping out implementations of various interfaces and functions with completely new ones. This is a job that unit testing excels at. Don't write any new code without a test of some kind that runs on the old code under DOS! Make your potential problems as small and simple as you possibly can. Port assembly code instead of rewriting it only if you're reasonably confident that it will actually make your job easier (ie, algorithmic stuff that compiles fine with few tweaks under NASM). Don't bite off a bigger piece than you can comfortably fit in your brain at once.
I, for one, look forward to seeing your progress! I think what you're attempting to do is great. Thanks for doing it.
Hmmm - I might approach it by writing an OpenGL video "driver" for it. and todays machines are fast enough with tons of ram that you could do all the pixel specific algorithms on main CPU into a back buffer and it would work. As the "generic" VGA driver just mapped the video buffer to a pointer this would be a place to start. There was a zoom mode in the UI so you can look at the pixels on a high res display.
It is often very difficult to take an existing non-trivial code base that wasn't written with portability in mind - you mention a few - and then try to make it portable. There will be a lot of problems on the way. It is probably a better idea to start from scratch and rewrite the code using the existing code as reference only. If you start from scratch you can leverage existing portable UI solution in your new project like Qt.
I'm thinking of something smaller than a laptop that i can spend my hours on the way to work doing project euler problems or such.
Any ideas?
If you mean a programming platform, you could get a netbook like the ASUS EEE.
Or if you meant smallest programmable device, check out a PIC microcontroller:
http://en.wikipedia.org/wiki/PIC_microcontroller
This may sound crazy but try pen/pencil and paper. No you can't run the code but it'll help you to not use online references so much (yes they are good but memory skills help us all) and it'll probably also help you plan your code better.
I've programmed directly on my HP 48G series calculator.
There's a good programming tutorial for it here. I'll have to dust it off and see if it will pass Project Euler's one-minute rule.
If you are looking for a microcontroller or similar my advice to you would be to check out either an AVR, PIC, Arduino, or BeagleBoard.
All are relatively cheap and easy to program (the first three more so). AVR's and PIC's are types of microcontrollers that you can program with C or ASM, however you will need some type of prototyping board or similar to achieve anything. An Arduino is an AVR chip sitting on a board, so it is much easier to achieve something in a small amount of time. In addition to this they are quite popular and you can find many projects that have been done at Hackaday. Lastly BeagleBoard is a much gruntier board that will run embedded linux.
My recommendation is for the Arduino.
There are many more suggestions here.
However, If you are looking for a small laptop device to program you have plenty of options. An Asus EEE pc, HP 2133 (I believe thats the correct model), MSI Wind, MacBook Air etc etc. As other people have suggested check out some netbooks. There are also various PDA's or mobile phones that you could program, such as an Android phone or an OpenMoko phone. There are plenty of options, I suggest you find out what size you are looking for specifically and that will narrow down your choices.
Good Luck.
I'll take the reputation hit to say this: why not read a book or watch the scenery go by? Trying to cram more programming into your day isn't actually good for you, and may even make you less productive.
I have used SmallBASIC on my Palm OS 5 device for a while now, and it seems to work well with most of the problems I throw at it.
How about using a Palm with the OnboardC compiler?
A netbook would be ideal.
A graphing calculator might be too limited for programming.
If you're talking about doing a microcontroller, there are several models of arduino boards that are very easy for someone not familiar with embedded programming.
I have a Nokia E51 with python interpreter. It's not pleasant to type with a numeric keypad at all. I think it is as small as you can get.
I have a Samsung i760 running Windows Mobile 6. The slide-out keyboard is fantastic (best mini-keyboard on any device) - I can type on it almost as fast as a normal keyboard. I mainly use it to write Oracle Lite queries in mSQL, which is borderline unusable with any other PDA keyboard.
This question led me to wonder about real programming environments for this device, so I asked another question, and one of the answers was a link to this, which is a Windows Mobile IDE for creating .NET Windows Mobile applications. You write them in C#, even.
Netbooks are smaller than your typical laptop and have plenty of power.
It's pretty subjective. I code on my commute using a 15.4" laptop and I find it quite limiting.
I could still work at 13", but the limitations would be getting so large I'd already be questioning if it's worth it. Anything smaller would be right out.
But then I tend to work with lots of windows open. Multiple editors, docs, browsers etc. Cutting back on that eats into my productivity. At home I have a 30" display. At work I have 2x 24" displays.
If you tend to work mostly in one window, rarely consult docs and other apps etc, you could probably go smaller.
It depends so much on the type of person you are, what you are comfortable with, the way you work, what you are working in and with... the list goes on.
My guess is that for most developers 13" is going to be the smallest before it gets so frustrating that you're better off just listening to podcasts or something - but YMMV - and will!