Quote Originally Posted by mwildam View Post
No, that didn't work even in VB.net. I tried with a few code pieces. None of them worked in .net.
I did that with an entire app. It took an afternoon. There are some changes that need to be made, so only certain, simple, methods can be directly copied and expected to work, and even then they won't be all that efficient. After all, the fundamental integer type in classic VB was the Long (32-bit Integer), but .NET matched the ANSI C/C++ conventions and made Long a 64-bit integer, which is slightly slower to work with, especially on 32-bit systems. Therefore, at the very least, Long in Classic should be changed to Integer in .NET.

Considering how well Apple has done at emulating Windows, I would expect that any client written in .NET would probably be runable on an Apple, as well. Apple has put lots of effort into emulating. I don't deal with them either, though, so all I can go on is what my few Apple friends tell me (they tend to be a passionate bunch, though, and there is generally an "everything runs better on Apple" in any such conversation, so I'm not sure I trust them).

As for graphics, that really is my concern, at the moment, even though the app is line of business. The interface couldn't be rendered fast enough using GDI. By using some clever caching of partial images, I got the performance into the acceptable range (no pause at all), but there were actions that forced me to clear my caches and redraw the whole screen. When those actions were few and far between, I had no issue with spending 10-15 seconds re-building the caches, but then I added a much more significant feature that people would use frequently, and a 10-15 second pause became too onerous to bear. At that point, I moved to using the graphics subsystem and scrapping the caching. Without caching, I have to redraw the entire screen VERY frequently. In normal use, it might be more than once a second. However, by using the graphics subsystem, even my laptop, which doesn't have much in the way of graphics hardware, is able to redraw the whole screen in a few milliseconds, which is faster than the eye can perceive. This is excellent, but it means that I am tied to languages that allow access to the graphics card. In MS, that pretty much means DirectX, as there is no reason I know of to deal with the hardware directly when you have a library to do it for you. However, DirectX doesn't exist everywhere. I was thinking that OpenGL was fading out, too.

It's a frustrating situation. I have no problem being tied to Windows, as I can mandate that, though tablet apps would be viable options down the road. Unfortunately, it doesn't seem like even MS knows where MS is going with graphics. XNA is an excellent means to interact with the graphics card in .NET, and VB6 could use DirectX directly...though with a fair amount of pain to the user relative to how XNA is for .NET (still some pain, just not as much). On the other hand, MS has made some noise about leaving graphics to unmanaged C++. So, I'd look at another language that dealt with graphics hardware well, and still allowed for RAD. It sounds like you don't know whether Java interacts with the hardware, at all, let alone whether or not their solution is portable across platforms. My feeling is that it is not, but I may have to look one of these days.