Debugging embedded Lua - c++

How do you debug lua code embedded in a c++ application?
From what I gather, either I need to buy a special IDE and link in their special lua runtime (ugh). Or I need to build a debug console in to the game engine, using the lua debug API calls.
I am leaning toward writing my own debug console, but it seems like a lot of work. Time that I could better spend polishing the other portions of the game.

There are several tools floating around that can do at least parts of what you want. I have seen references to a VS plugin, there is a SciTE debugger extension in Lua for Windows, and there is the Kepler project's RemDebug, as well as their LuaEclipse.
RemDebug may be on the track of what you need, as it was built to allow for debugging CGI scripts written in Lua. It does require access to the LuaSocket module to provide a communications channel between the target script and a controller as well as a couple of other modules.
A bigger issue might be the ability to load arbitrary modules from within whatever sandbox the game engine has put around your scripts. If you have some control over the engine, then that won't be as big an issue.
This isn't currently possible for developers of Adobe Lightroom plugins, for example, because Lightroom does not expose require inside the plugin's sandbox.
A surprise to me has been how rarely I have felt a need for a debugger when working with Lua. I've built several small applications in it for various projects and have been surprised at how well a combination of complete stack backtraces and the occasional print call works to locate the bugs that require "strict" didn't prevent in the first place.

How about Decoda?? there is a video that explains how to use it, and it works pretty darn well for embedded lua source. (i am a happy customer). and it's pretty cheap.

You don't need to write your own console as you may want to start with one of the existing ones. RemDebug has already been suggested; I have been developing MobDebug, which is a debugger based on RemDebug, but with a host of new features and bug fixes. The detailed list of the changes is in the README.
Enabling debugging in your script may be as simple as adding require('mobdebug').start() (if you are running your app and the debugger server on the same machine). This should try to connect to the debugger listening on a default port on localhost. You can use a command-line interface included in MobDebug, or you can use a ZeroBrane Studio, which is a Lua IDE that integrates with MobDebug to provide debugging capabilities. The IDE supports debugging for Love2d, Moai, and other Lua engines and may well work for your set up too.

You can use my debugger: GRLD (graphical remote lua debugger). Like RemDebug it uses a socket connection, but unlike RemDebug it has a nice graphical interface. The source code is provided, so you can make it work on any platform. It works with the standard lua runtime. Free of charge for non-commercial use.
EDIT: sorry, I had to close the website, so the software is not available for download anymore. I might release it as open source software later, if I ever find the time.
EDIT 2: link updated, now hosted in github under the MIT license (open source)

I don't see how calling DebuggerBreak should work, since that is .NET specific. I would assume that only works with the forked Lua targeting the CLR.
If you are using standard Lua you have some rudementary debugging facilities through the lua function call debug.debug(). That will throw Lua into your console, so if you are running lua from a console, you should be able issue lua commands interactively to inspect your current state. debug.debug() wont put you into the current stack frame, so you have to use debug.getlocal() to read the values of your variables.
I haven't tried it myself yet, but I actually don't think making your own workable debug console is that much work. Remember Lua is not as complicated language as C++, so doing this is a lot easier than making a real C++ debugger like say gdb.
I think there are a lot of people who have done similar things already, whos code you could look at. Here is CLI debugger written in only lua. Just one lua file. Shouldn't be to hard use and modify for your needs.

If you are using windows and VS - Can you use the trick we use?
Copy the lua code in a file. Then in the lua code make a call to the Debugger api (in C++ this is DebuggerBreak() I think - see here). then when the lua code executes the debugger will fire up and you should be able to specify the file. Then debug as normal?

Related

Peripheral registers in Qt Creator during debugging

I use Qt Creator to develop embedded application using Bare Metal configuration for STM32. When I debug this application under different IDEs like KIEL uVision, IAR System Workbench or some Eclipse IDE I have special view available where I can see processor specific registers in tree list. Is there something similar for Qt Creator?
I've seen the register view in debug view. Is there possibility to tell it which memory address to show?
EDIT: The application I'm writing is in C and C++. The target is microcontroller based on ARM architecture in this case STM32. There will be no Qt or QML code.
My goal is to use QtCreator as IDE for developing this application. This quite easy as you just configure the compiler (arm-none-eabi-gcc), debugger (arm-none-eabi-gdb) and gdb-server (openocd) in the kit configuration. This allows me to create executable elf file for bare metal target and then flash it to the FLASH memory inside the microcontroller.
All these steps are already done.
However the debugging part gets tricky as part of the memory space is direct hardware configuration and not pure memory. This memory space contains the configuration for the peripherals which allows you to e.g. talk over UART, I2C, ETHERNET, USB or just configure the pins or clock speed.
You need to look at these values and compare them with reference manual and see what each bit does. Currently it is possible to look at the memory map and read it there but Keil uVision, IAR System Workbench and Ecplipse based IDEs have nice plugin where you can see the values exactly as in the reference manual. (see the images)
So my question is if there is some plugin or some way how to view and edit these or if I have to write this plugin myself?
In the latter case I would need to know how to connect to the debugger instance and write commands and read output - mainly read data #address and write data #address. I understand that the gdb uses the MI mode. I tried to connect to gdb from different process but that is not possible so I guess that I'll have to create plugin for Qt Creator. The register description is in file format SVD which is XML with defined structure.
To summarize the last part I look for code that I have to implement in the plugin that will connect me to the running gdb and allow me to send and receive data when it hits breakpoint.
You don't say whether you are debugging C++ code or QML code, so I can't answer with a yes or no. Those register values are useful if you are debugging at the assembly language level (which in itself may or may not be useful).
If you're debugging C++ code, then you can configure your compiler to generate an assembly listing of that code, but you will be debugging at a pretty low level.
If you're debugging QML code, then you would need an assembly listing of the QML engine, which I doubt you will be able to get. More importantly, I suspect that it would be a waste of time to try to debug a declarative language like QML with such a low level procedural debugger. The point of a language like QML is to get you above all that.

Creating an SNMP agent with Qt and C++

I'm considering adding SNMP support to a simple daemon I wrote under linux. My daemon is written in C++ and Qt5.
I'm looking for an easy way to add this support. I found several MIB creation tools, the problem is writing the agent (or subagent). I'd rather not code this in C, would anyone know of q Qt library that helps out? I found mib2c which will create a skeleton in C (but I'd rather use C++ with Qt).
You can try using CIMPLE, which I've forked on github from it's original website. I've done some cleanup on github and I've attempted to contact the original authors, but they've never returned any of my emails which makes me wonder whether or not they intend to continue supporting the library.
Regardless, it does work and it plays fairly nicely with both Windows and Linux, which have very different styles of implementing SNMP agents. If you google around for "WBEM" you will find some other libraries as well. CIMPLE is the one we used at Fusion-io for SNMP support. It supported C++ fairly well and uses a code generator to handle lots of the boiler plate stuff that's really boring to write and not specific to your application.

Bonjour/DNS-SD on Windows

I'm currently working on a cross-platform application (Win/OSX/iOS) which has a C++ (with Boost) back end. On iOS and OSX I'm using the Cocoa Net Service Browser Delegate functions to discover an embedded device via mDNS, then pass the information to the back end to create the objects it needs to communicate with it.
I wanted to take a similar approach with my Windows MFC front end and I found this article which seemed to do exactly what I want. However, it seems that using the Bonjour SDK has some really nasty side effects - forcing you to static link to MFC and in my case the only way I can get it to link properly is to not use debug DLLs at all, which is not ideal.
So, the Bonjour SDK isn't really any good for me because it imposes too many restrictions on my project. With Cocoa I'm actually using very little of the functionality - just didFindService and netServiceDidResolveAddress really. All I want to do is find the devices of a given type and get their IP addresses.
Can anyone suggest another way around this that will work with an MFC front end on Windows?
From what I have been able to gather from researching this topic just goto http://www.opensource.apple.com/source/mDNSResponder/mDNSResponder-333.10/ and grab the source. There is a VC project file which will let you build the dll how you want.

What's the best language for real-time graphics programming on Android?

Some googling has led me to believe that C++ is the best language for real-time 2D graphics programming, but since the Android is Java-based, is that still the best option? Or us the fact that I have to use NDK going to slow it down or something? My program also has a lot of scientific computing and I know C++ is best/fastest for that...
I've never done anything with the Android before so I'm really helpless right now. If I'm just going about it the wrong way, please give me other suggestions... Some other vocab I came across is OpenGL (which I have experience with, but that's more for 3D, right?) and Canvas (don't quite get this)? If I could get access to GPU-like capabilities that would be great.
Android applications are written Java, yes - however the Android NDK allows you to write performance-critical sections of your program in C or C++. From the Android NDK website,
The Android NDK is a companion tool to
the Android SDK that lets you build
performance-critical portions of your
apps in native code. It provides
headers and libraries that allow you
to build activities, handle user
input, use hardware sensors, access
application resources, and more, when
programming in C or C++.
That said, using the NDK appropriately will most likely not slow your program down.
OpenGL works for 3D and 2D graphics - if you're only interested in 2D you will want to look at using an Orthographic Projection - see glOrtho for more information. The Android Canvas, on the other hand, is the Java method for drawing raster graphics to the screen. It will let you render 2D graphics, but at a slower rate (and with frequent interruptions from the Android Garbage Collector).
Keep in mind that if you want to use C++, as of writing, there is no STL implementation available. There are, however unofficial ports that provide most of the functionality. STLPort is one that I have tried with some success. The biggest reason to move code to C/C++ is because of interruptions from the Android Java Garbage Collector - if you're not overly careful with your code, it will interrupt your program frequently to clean up objects you've left lying around. In practice this can limit game or simulation framerates drastically.
All that said, I would strongly recommend you look into one of the few open source android game engines that are cropping up. The best one I've tried is libGDX. It takes care of all the messy NDK details and lets you code your game / simulation purely in Java. It automatically runs the performance-heavy parts of the game engine in native code to get the fastest possible performance with the ease of coding in Java. Best of all, you can write your application code once and have it automatically run on Windows, Linux, OSX and Android - which makes testing your applications much, much easier than using the Android Emulator.
If you really want to look into the NDK yourself, or need to have really fine control on what OpenGL is doing, I would recommend you download the Android SDK and NDK, get eclipse set up, and then start with the NDK samples. There is an OpenGL demo there that shows you how to get everything set up. Another good starting point would be the SpinningCube google project.
EDIT: I'm not really sure if what you mean by 'GPU-like capabilities', but With libGDX, you can compile vertex and fragment shaders under OpenGL ES 2.0 - you could use this to run embarrassingly parallel code using the device's GPU.
You're making the assumption that the Android system will be too slow to do what you want, without any data to back that up. Write some tests in Java, and test out the performance first. You don't want to make assumptions about performance without any basis.
Premature optimization is the root of
all evil. - Knuth
How to do it: C-programmers guide to Java and JNI in Android
Good question, I put myself like 1½ years ago, found it very annoying. I feel a lot for you!
And because of this I like to give a hands on answer.
But look it is easy if you follow this guideline step by step (you will have much less struggle). I did it.
Learning this, you can in no time learn easily write Java Netbeans GUI with JNI apps (for any other OS) also, you are in the Java GUI JNI development world?
The basis is “knowing C/C++ very well, not knowing Java or Android programming at all, coming from for instance the Win32 SDK culture and making the first Android app”.
Android GUI is Java – you have to yield
Thing is that the GUI of Android is Java. Java like your app and the app is more or less in practice a piece of the GUI/OS environment completely integrated calling Java GUI SDK code all the time. The debugger even goes into the Java GUI SDK source code (feels like going off road, real odd for a Win32 SDK programmer).
In short, no way writing any Android apps, but in Java.
But it is pretty easy in anyway, you got the JNI
There are three very good shortcuts:
The Android sample library (is very rich), especially the Hello JNI sample is really important
The fact Java is in syntax very much alike C/C++ (but very different in its soul, read below, you need to understand)
You got the JNI C-code opportunity in doing the heavy work (and you major share of the code)
You have to write a small Java Android GUI user interface for your app (by thieving form samples) and the major part JNI, where you write your C/C++-code doing all the work.
Start with the Hello JNI sample program
Install Java and Android Studio and that it is all you need in tools (available in Win10, OSX or Ubuntu, they are the same).
Start Android Studio and its generic picture is a menu, select the lowest, Import an Android code sample.
The main sample program for a traditional C/C++ programmer is Hello JNI. Select it and say next to everything.
The Android Studio editor will open with the sample code (chews somewhat first see status line low).
Up to the right you (might need to push the Android tab to) see the content of your project Hello JNI, app. It consists of:
Manifests (app declaration, today of minor importance because most is now in Gradle script declarations (below))
Java tab for the Java files
Cpp-tab for your C-code files
Resources (texts, menus and icons)
Gradle compiling scripts
C-make-files
The Android studio might ask you for installation plugin upgrades, say yes to everything until it is done (see status line below).
Then run the Hello JNI sample code, to make certain your installation is OK
Pushing the green arrow in a cogwheel (mid top).
You get a dialogue box. Here you can try the sample on:
A physical Android device (via a cable from your PC, might need a Samsung win driver from their support)
A HAXM Android unit emulator (is reel good)
But you need to switch off the Hyper-V feature (used for XP emulation) in Win10 to make it run. Android studio might do it automatically for you asking, else control panel/Programs and functions/Windows functions.
Select Create new Virtual device. You might need to do some installation plugin upgrades more, say yes to everything.
When the Hello JNI app is working in the device, you have an OK installation.
C-code, check hello-jni.c
Look in the cpp-folder Up right) and you will find a C-file with a function.
Here and in any other C-file you can fill it with regular C-code.
Everything but the ANSI C locale features are supported (must get locale data from Java and transport them to the C-environment).
You need to edit the CMakeLists.txt file to add any additional C/C++-files (it is the makefile, look up to the right under the Gradle scripts).
Memory heaps, Java with JNI and C are different
You must be aware that everting in the data jstrings delivered by the JNI interface is located in the Java memory heap. This is also the case after the data has been in delivered C-format by JNI.
You will have fuzz if you don’t copy string data (and arrays) from the Java heap to the C-heap. Make a basic function like this to copy the data and release the JNI data:
char *GetStringfromJniString(JNIEnv *env, jstring jniString)
{
const char *TempString = (*env)->GetStringUTFChars(env, jniString, 0);
char *String = calloc(strlen(TempString) + 1, sizeof(char));
strcpy(String, TempString);
(*env)->ReleaseStringUTFChars(env, jniString, TempString);
return String;
}
When you send data to Java jstrings you need to contain it to the JNI transport by using the
return (*env)->NewStringUTF(env, pCstring);
Long funny names of the JNI-functions
The function name is Java_com_example_hellojni_HelloJni stringFromJNI(…).
There “Java” is always there
com_example_hellojni means it communicate with your app in the Java com.example.hellojni Java package (read about it in the tutorial)
The HelloJni is the name of the Java file the JNI function is declared
And stringFromJNI(…) is the actual function name (functions in Java are called Methods).
If naming is OK the declaration of the C JNI-functions in the Java file is black text, if not red text. (Give it a chance, it stores and checks the code continuously in the Java environment, might take a few seconds to verify it is right (becoming black).
You must declare the C JNI-functions in java
In the Java file here HelloJni.java the JNI-functions must declared as Java Methods (functions in Java).
public native String stringFromJNI(…);
Where return values and function/method switches are the same as in C.
After that you can use the JNI-functions as Java methods as they are declared in the Java declaration. Note that char * is String in java.
Constants must be declared on both sides
#define CONSTANT_A = 24
Is in Java
static final int CONSTANT_A = 24;
And you can use them in Java and in C as usually.
if(!variable) does not work in Java
You need to do
if(variable==0)
Test other samples
The sample library is full of fully nice functioning Java samples. Try them one by one until you find a user interface of your like. It is actually nice to test samples.
There are a lot of sample in Github but a lot of them need fixes of Gradle scripts or comes from Eclipse (the past Android dev environment) and is harder to try (often need fixes). Other Github sample are just fragments and a lot of work making them working. Of course nothing for a Java Android star but we are not there yet. But Github a very good even larger source of samples.
Copy the Java stuff into your Hello-JNI
Found anything nice, copy it!
Theft always pays as JS Bach used to do!
It is quite easy to just copy stuff from one sample to another. When copying in the Android studio, Android studio adds automatically the includes (asking first) and just accept. Sometimes it does it asking you to enter Alt-Enter, do it.
Editing several projects at the same time
The File/Open recent - Own windows-command, make you having two projects up at the same time, easier to copy stuff in between.
Making your own application
After some testing you create your own app.
Go to the generic Android studio picture (file/close project), select Start a new Android Studio project. Put your Package tree data (think that over, read about it in the tutorial) and create it. Then copy the stuff you tested to your own app.
Learn Java, the Android developer tutorial is real good
Now you have made your environment working and spotted some good user interfaces, learn Java!
The Android Studio tutorial is real good. Try it, and soon after a few lessons you will be able to play with Java code and very soon you are a Java programmer.
Getting stuck, google and you find most answers in Stackoverflow, just search.
You are never the first with a problem and Stackoverflow is real good. Read all the answers and think, you find what fits you best.
The Java environment and Android OS is very different from Windows
You need a feeling for the culture and environment. Like a Swede coming to Norway, the same food taste slightly different, even if it looks the same.
The major difference is that in Java nothing crash as good as in pure C in a C environment. Finding bugs can be hell because of non-consistent crashing. The program continue to run and crash later, but you find the bugs.
There are Java log files for debugging, but it takes quite an effort to penetrate it. Like learning the assembly code in a Windows debugger.
A good idea is to really debug the C-code in a pure C-environment first and handle the Java stuff in Android Studio.
I can amend C-code in Android Studio but writing a large chunk of C-code is really looking for troubles debugging it. Like asking a Norwegian make a Swedish dinner, impossible to get it right, looks the same but taste different. Nothing is wrong but different culture.
The soft crashing style of Java includes even security soft crash features like the try/catchy/finally stuff. (You have to google and read about it yourself. It is unbelievable for a hard core C-programmer, but it is real.)
There are no h-files and #if-compiler switches in Java
Instead of h-files and common declarations of functions/variables as in C in java you have to refer to them with a filename followed by a dot and the method name, using them from another file.
If declared private variables and methods can only be accessed from the same file, with public can be used with file reference. Static is something very different in Java.
There are no compiler #if-switches so you need to use regular variables/constants (for constants put final before in the declaration).
There are no pointers in Java, but there are strings
There are no pointers in Java but a String (and array) variable is in fact a char pointer
But you can’t handle pointers as in C with * and &, but in JNI you certainly can. The memory management is completely different, nothing is fixed in Java.
You don’t need to free data, Java wipes it all for you
Java cleans unused data automatically.
You don’t free data just delete (=0;) the string-“pointers” or just leave the method (Java function) and it cleans it.
So if you have a string pointer and just replace it with something else the old stuff is automatically wiped.
The Java environment lives its own life, but the Android studio debugger includes a monitor of the data used.
Size limitations of Java apps and JNI code
Good to know is that there are some restrictions in how large a Java app can be (but as usual nothing is written in stone in Java) but the JNI heap can be as large as the HW can take.
But you are not alone in a phone, an incoming call might come and you don’t want to mess that up? If you clean well it is a larger chance your app is intact returning to it and not killed.
Android apps don’t die by exit
If you exit an app, the app is still running even though the GUI is gone (like in Macintosh). Thing is that you have to be aware of that, read about it if you make serious apps.
Android kills apps
But on the other hand you can never trust that an app is not wiped by the OS and you have to rebuild. If the OS need memory it just starts to kill apps. But the JNI part usually survive and you can store data there for a recovery.
There is only one JNI instance (WinSDK term) but there might be many Java instances
And them all connect to the same JNI at the same time. Only one app instance can be active (shown) but the others might make background tasks. In JNI you need to keep track of them.
Normally there is only one Android instance of every app. But if you start the app by a work files from for instance like an email client, you in fact have another instance of the app (with its own memory and everything (but the JNI that is in only one common instance)).
Starting an appended file there will be two or more Android instances. Each related to each email instance, by the intents procedures (learn about intents in Android tutorial).
A smart thing is keeping track of the instances by number them when the app is created if savedInstanceState == null.
Copy data to the emulated unit
You might need to upload some data to test your app. In a regular phone you just attach the USB-cable and enter the Phone storage from Windows explorer. With the emulated units you must use the adb-terminal script functionality (can be used in bat-files in Windows and a copy bat file looks like this:
PATH=%PATH%;C:\Users\You\AppData\Local\Android\sdk\platform-tools
adb push C:\Users\You\Documents\v.txt /storage/emulated/0/Android/data/com.yours.app/files/v.txt
Very limited privileges to read and write files
Thing is however that you are only allowed to open your own files stored by your app in the emulated SD card. Else nothing comes reading them.
Use standard ANSI C file functions rather than Java
Best in a C-heavy app is to use standard C- file functions, as a C-programmer you are used to them and their behavior.
The C-file functions works fine and is easier to get binary code or transparent text files with ctrl-characters etc (Is not allowed in Java Strings but in java bit arrays). Take some effort learning Java file handling if you try that.
JNI performance is no issue
The C-code is much faster than the Java code so a lot of developers not from the C-culture must make JNI-functions and pure C-code to perform in heavy apps, needing performance. In short JNI performance is no issue.
However I have the impression that the Android GUI is faster than the WinSDK GUI in many cases. Working with ListViews and sometimes very long lists, Android is far better optimised. It looks like WinSDK is loading every line of the list, but Android only the lines visual, and in long lists it makes a huge difference.
I am impressed by performance in Android even with tiny ARM processors. Apps do perform very well. Intel Android units are real good in performance. I wouldn't hesitate trying to make a heavy duty app in Android, as long as I use JNI. Does not come short compared to Windows.
But notice, that running HAXM in an Intel PC the Intel emulated units runs much faster than the ARM than in real HW-units, because it runs intel code straight and not over an emulator layer as with ARM emulated units.
I am amazed that the Android x86 is not marketed heavier as a competitor to Windows on netbooks, for the common man, doing some documents, some calculations, email and Google? I believe the Crome OS is too alien for most people and most people have Android phones, feeling home. As a SW vendor I would like to see Android netbooks marketed much more and I would put more effort in SW development. Same thing with the Android TV without menus is closing the market for just the old Smart-TV approach. Something I can't understand having a boxed Win10 on the back of my TV since years, using a lot of programs there. The lack of Android graphics driver for the Raspberry-pie is also hard to understand, one with a regular Android would be smashing attached to the TV. In Sweden where I live, people under 40 don't watch aired TV, they stream, public service play, YouTube and Cable TV operators packages over internet. Having regular Android in the TV would generate usage of a lot of other apps. I see a market opportunity for SW vendors is closed. This when MS is making suicide with leased SW (normal people don't pay) mixing the culture of large accounts with the common man, a huge marketing window is opened. And the Android app performance is real good and nothing to worry about. It is not performance but marketing policies that limits the app market.
Quick you become a Java and Android master
You will be surprised how easy Java is for a C-programmer, doing it the right way (like following this guideline).
It might be slightly harder for a C++-programmer because the Classes in java and C++ culture looks to vary, might be easier to learn Java classes from scratch? But if you see C++-code in Win32 and OSX environment they look usually from different planets, so they might use to it.
The major disadvantage is that you wouldn’t get a diploma for your CV as doing a programmers course?

Remote programming and debugging

I have to program a C/C++ application. I have windows and linux (ubuntu 9.04) in my machine, and can program in both of them (via gcc/code blocks/vim,etc). The problem is that the executable is going to be run in a Unix (not linux) machine (will have access to it in about 20 days).
My Team Leader doesn´t want all of the code to be programmed in linux - unix. So, some of it will have to be developed in windows (and then many prayers will follow so that nothing bad happens).
The best thing i´ve come up with is to program remotely on the server, from windows and linux, so every programmer (only me for the next 2 weeks) is sort of happy.
In windows, I think i´m stuck with putty, but is there any alternative on linux, rather than ssh-vim? .
I read this Remote debugging with Eclipse CDT but it didn´t bring much light on the subject. At least not much hope.
There is another issue. I don´t consider C/C++ to be a portable language. At least for real programs. Sure it compiles, but many issues will arise, even with boost / stl. I haven´t taken a careful look to the code, but still, how wrong a I?
Any tips will be greatly appreciated.
Thanks in advance.
You could ssh w/ xming for a gui ide/editor that is on the remote machine.
If all the code is one the remote machine and compiled there, don't you have to worry about developers trying to work with the same resources? Also might the machine/network not be able to handle multiple ssh connections if you're using xming?
If you can convince your system administrator to install the libraries (an X server is not required), you can use X forwarding with SSH, which will allow you to execute X apps remotely and have them come up on your local server. If you're using Linux locally, you probably have X running already, and if you are using Windows, you can use the Xming server (with a little configuration to get it to accept remote connections). For debugging, if you need a separate shell, just set another instance of SSH going and perform debugging from another process.
As for portability, it depends on what you are trying to do. If all you want is a simple console-based application, you shouldn't run into any major portability concerns. If you are using more complex code, portability depends heavily on two things. The first is the choice of libraries - sure, you can run applications written for Win32 on Linux with Wine or actually compile them with Winelib, but it's not a pleasant experience. If you choose something more portable like Qt or gtkmm, you'll have a much easier time of things. Likewise for filesystem code - using a library like Boost.Filesystem will make things significantly simpler. The second thing that makes a big difference for portability is to follow the documentation. It's hard to stress this enough - many things that you do incorrectly will have varied results on different platforms, especially if you are using libraries that don't do checks (note: I highly recommend checking code against debug standard libraries for this reason). I once spent nearly a weak tracking down a portability bug that arose because someone didn't read the docs and was passing an invalid parameter.
If you want to use remote desktop like facility try VNC www.realvnc.com
or in case its just a remote login Hummingbird, EXceed could help
You might want to check the wingdb visual studio extension.
Not sure if this will help, but take a peek at sshfs. I haven't had a need to use it myself, but I have read others use it to access remote files and directories via ssh and work on the files locally. I presume you could access your remote home directory via sshfs and then use your local tools to work on the source files. I would very interested in knowing if this works out, so please post back if you give it a shot.
I use No Machine NX, which gives you the entire desktop of the remote machine. It also has a Windows client. I work remotely from home on Fridays, so I'm using it right now. You'll have to install it on the remote machine, and then install a client on your Windows or Linux machine.