I am looking for tools and techniques for prototyping (virtual prototyping), simulation, and testing of deeply embedded C code on desktop Windows, including building realistic embedded front panels consisting of buttons, LEDs, and LCD displays (both segmented and graphic).
I'm specifically interested in a possibly low-level approach, using pure C code and raw Win32 API rather than MFC, .NET/C#, vxWidgets or Qt. I'd also like to use free development tools, such as Visual C++ Express with Platform SDK and ResEdit for editing resources.
I'm looking for code examples to render graphic LCDs (from monochrome to 24-bit color) with efficient pixel-level interface, multi-segment LCDs, and owner-drawn buttons that respond both to "depressed" and "released" events.
I am surprised that my original question triggered so many misunderstandings and adverse comments. The strategy of developing deeply embedded C code on one machine (e.g., a PC) and running it on another (the embedded microcontroller) is called "dual targeting" and is really quite common. For example, developing and testing deeply embedded code on the PC is the cornerstone of the recent book "Test-Driven Development for Embedded C" by James Grenning.
Avoiding Target Hardware Bottleneck with Dual Targeting
Please note that dual targeting does not mean that the embedded device has anything to do with the PC. Neither it means that the simulation must be cycle-exact with the embedded target CPU.
Dual targeting simply means that from day one, your embedded code (typically in C) is designed to run on at least two platforms: the final target hardware and your PC. All you really need for this is two C compilers: one for the PC and another for the embedded device.
However, the dual targeting strategy does require a specific way of designing the embedded software such that any target hardware dependencies are handled through a well-defined interface often called the Board Support Package (BSP). This interface has at least two implementations: one for the actual target and one for the PC, for example running Windows. With such interface in place, the bulk of the embedded code can remain completely unaware which BSP implementation it is linked to and so it can be developed quickly on the PC, but can also run on the target hardware without any changes.
While some embedded programmers can view dual targeting as a self-inflicted burden, the more experienced developers generally agree that paying attention to the boundaries between software and hardware is actually beneficial, because it results in more modular, more portable, and more maintainable software with much longer useful lifetime. The investment in dual targeting has also an immediate payback in the vastly accelerated compile-run-debug cycle, which is much faster and more productive on the powerful PC compared to much slower, recourse-constrained deeply embedded target with limited visibility into the running code.
Front Panel Win32 GUI Toolkit
When developing embedded code for devices with non-trivial user interfaces, one often runs into the problem of representing the embedded front panels as GUI elements on the PC. The problem is so common, that I'm really surprised that nobody here could recommend an existing library or an open source project, which would provide a simple C-only interface to the basic elements, such as LCDs, buttons, and LEDs. This is really not that complicated, yet it seems that every embedded developer has to re-invent this wheel over and over again.
So, to help embedded developers interested in prototyping embedded devices on Windows, I have created a "Front Panel Win32 GUI Toolkit" and have posted it online under the GPL open source license (see http://www.state-machine.com/win32). This toolkit relies only on the raw Win32 API in C and currently provides the following elements:
Dot-matrix display for an efficient, pixel-addressable displays such as graphical LCDs, OLEDs, etc. with up to 24-bit color
Segment display for segmented display such as segment LCDs, and segment LEDs with generic, custom bitmaps for the segments.
Owner-drawn buttons with custom “depressed” and “released” bitmaps and capable of generating separate events when depressed and when released.
The toolkit comes with an example and an App Note (see http://www.state-machine.com/win32/AN_Win32-GUI.pdf), showing how to handle input from the owner-drawn buttons, regular buttons, keyboard, and the mouse. You can also view an animated demo at http://www.state-machine.com/win32/front_panel.html.
Regarding the size and complexity of the "Front Panel Win32 GUI Toolkit", the implementation of the aforementioned GUI elements takes only about 250 lines of C. The example with all sources of input and a lot of comments amounts to some 300 lines of C. The toolkit has been tested with the free Visual C++ Express 2010 (with the Express Edition Platform SDK) and the free ResEdit resource editor.
Enjoy!
The appliances you mention in your comment clarification to the question will never be using a windows PC, so low level windows programming is not a requirement in that case. In fact, I'd say its undesirable. Prototyping is about speed. It's about how fast you can put something together to show potential investors or upper management or some other decision maker.
You wouldn't want to spend the extra time with low level C and Win32 api until the project requirements were flushed out enough that you knew that was an absolute requirement for the final project deliverables (perhaps a server/PC monitoring tool?). Until then you want speed of development. Lucky for you the industry has tools for rapid prototyping and development of hardware like you describe.
My Preference for Prototyping with Embedded Development
As for my opinion as a developer, I like the .net microframework (.netmf) simply because I'm already a Microsoft .Net developer and can transfer a lot of my existing skills. Therefor I prototype with a FEZ microcontroller using C# under Visual C# Express 2010 (free as you required). Its fast, easy and you are working on the core of your project in minutes.
If your experience as a developer is different, you may look for a micro controller which is programmed using BASIC, Java or some other language to help with the speed of development by reusing your core skill set.
Addressing your Question Bounty Comments
Astonishingly large portions of the embedded software can be developed
on the desktop computer as opposed on the deeply embedded target. This
avoidance of the "target system bottleneck" can potentially improve
productivity by an order of magnitude, if done right. However, to
develop embedded software on the desktop, one needs to simulate the UI
components, such as displays (both segmented and increasingly
graphical), LEDs, knobs, and buttons. I'm looking for such UI
components written in plain Win32 API in C for easy integration with
embedded code to be developed and tested on the desktop Windows.
I did embedded development full time professionally for well over 4 years as well as many years surrounding that part time. While what you said above is somewhat true, it will not save you time or money which is why everyone is confused about the motivation for this strategy. We spent years trying to put out a windows emulator for this company's hardware devices that would theoretically save time for prototyping. It was always a pain and we spent many more hours of work trying to emulate the experience than if we just went straight from sketched UI drawing specs to real development. The emulator lagged behind hardware development and often wouldn't support the latest features until 6 months or more after the hardware was released. It was a lot of extra work for very little value.
You will spend more of your time developing non-reusable win32 platform code and hardware emulation components than actually writing the code for the core project itself. This only ever makes sense for hardware vendors who provide this emulator as a 'value add' tool to potential 3rd party developers, but it does not make sense for prototyping new hardware designs.
Modern development environments like Visual C# Express 2010 with a FEZ microcontroller can compile, push the project output to the microcontroller, and then begin debugging just as fast or faster than you could compile and run a low level windows app in C emulating LCDs or LEDs or switches, etc... So your comment, "improve productivity by an order of magnitude", is simply no longer true with modern tools. (It may have been prior to the last 10 years or so.)
If you really, truly just want to simulate the embedded hardware visually on a PC use something like adobe flash to mock up a UI. But don't duplicate code by coding for windows when the final device you are prototyping won't be running windows (maybe it will be, but you didn't say that). Use the fastest most reliable prototyping tools available today, which is unequivocally not low level C and win32 api!
Maybe use StackExchange for Electronics?
Because this is a development oriented site, discussion about the merits of specific embedded hardware isn't really relevant. If you decide to refocus on using microcontroller electronics for prototyping (Arduino, FEZ, Propeller, Basic Stamp, Pololu, etc) you might ask for electronics hardware advice on stackexchange for electronics. I will say that most of those platforms are designed to facilitate the prototyping of LCDs, LEDs, buttons and interfaces as you outlined. You can usually assemble a few pre-built modules in a matter of minutes and be ready to start coding your project. Huge time savings can be had here.
You are asking for too much you need to take a look # proteus.
http://www.labcenter.com/products/vsm_overview.cfm
As Mahmoud said, you may find your code solution with prototyping example in proteus professional. It is one of popular software for prototyping, simulation and coding, you can download proteus professional for free and check their manual.
Best of luck
Related
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 6 years ago.
Improve this question
If you open the page "Graphics and Gaming (Windows)" on microsoft.com
the last category is described as
Legacy Graphics: Technologies that are obsolete and should not be used in new
applications.
This category includes (among others) the following APIs:
GDI
GDI+
OpenGL
What's your opinion? If i want to roll out a new software today it must support Windows XP (still about 50% of all installed systems). Direct2D requires Windows 7/Vista. What else should be used?
I suspect that Microsoft's definition of "legacy" has little to do with what any sensible developer should do, and is instead based on some Grand Rewrite of the Windows API.
Starting at around Windows Vista, Microsoft has been redesigning many of their API's. We now have MMDevAPI as the One True Sound API, WIC is the One True Image File API, etc. From what I've seen/heard, these new API's are much better than the old ones, and the "legacy" systems all work based on the new ones. In Windows Vista and later, DirectSound is entirely based on MMDevAPI, and components that need to read image files do it via WIC.
Windows 8 will have an ARM version, which it appears will support only a subset of the current Windows API. We won't know for sure until Windows on ARM is released, but, based on the libraries included for the ARM platform in Visual Studio 11 (ref: http://www.winehq.org/pipermail/wine-devel/2012-March/094559.html), it's looking like GDI+ and OpenGL will not be available. GDI is available for linking, but that doesn't necessarily mean it's intact.
This new API's from Vista and later roughly correspond to the libraries in the VS11 ARM target. I'm guessing that anything on that list is there because it's either the latest and greatest way to do what it does, or it's too technically important to discard (for now). Thus, "legacy" is anything that's not the latest and greatest way to do at least one thing.
I'm not sure what is the One True Graphics API. Already we have Direct2D, Direct3D, DirectComposition (which, by the way, is not available until Windows 8), DirectWrite, and DXGI. DXGI seems the closest, but I don't have a deep enough understanding of the graphics API's to say. I suspect gdi32 is technically very difficult to get rid of. How are non-legacy applications meant to find out when part of a window has been revealed and therefore must be painted, without using WM_PAINT, which involves an HDC, and how could a library do that on an application's behalf without replacing its window procedure? How are we meant to make semi-transparent windows without using UpdateLayeredWindow, which takes an HDC? How much does user32 depend on gdi32, and can they really be separated?
From a technical standpoint, Windows can easily get rid of GDI+ and OpenGL, but I'm not convinced that getting rid of OpenGL will work out, even on a new platform that doesn't promise any backward compatibility. It seems too valuable to developers. GDI+ isn't so important, but it's very easy for a third party to provide a replacement.
I would say use any of the API's you listed, and the worst that's likely to happen is that you have to rewrite your UI if you want to port your app to metro or Windows on ARM. GDI is a fine choice if your needs are simple and you'll be coding directly for the Windows API. There aren't many situations where I'd recommend GDI+ over OpenGL as a drawing API. GDI+ is slow, limited, and only available on Windows. The GDI+ API is simpler because it's 2D, so maybe it's worthwhile if you need to do something very simple but with anti-aliasing.
OpenGL isn't deprecated, Microsoft's implementation of it is. Microsoft's implementation is stuck at version 1.1, which is old. The current version of the standard is past version 4. If you want to use OpenGL, it is fully supported by NVidia, ATI, and Intel graphics cards on the Windows desktop, but not in Metro Windows Modern UI apps, is an industry standard, and also works on Mac and Linux. If you need a software fallback implementation, Mesa has got you covered, and it even works on DOS. (Since Mesa can render into memory buffers, there's no reason it won't work in Modern UI apps, but you probably don't want to do this because it can be slow.) One thing of note is that WGL, the API for accessing OpenGL functionality on the Windows desktop, depends on GDI (which is deprecated) so you probably want to use something like FreeGLUT or SDL instead if you want to future-proof your application, which also nets you platform independence.
OpenGL ES is a variant of OpenGL which works on Android and Apple iOS. It is also accessible in JavaScript via WebGL, which Internet Explorer 11 will support (and pretty much every other browser already does.) ANGLE provides a hardware-accelerated implementation of GLES for Windows which piggybacks off of DirectX (version 9 or 11) and thus should work in Modern UI apps as well. Once again, Mesa's got the software implementation covered.
TL;DR: OpenGL is not only not deprecated, it is cross-platform, standard, and has tremendous momentum in the industry. GDI and GDI+, well, not so much.
If you want to support Windows XP, then you're supporting a "legacy" operating system, and as such, using a "legacy" graphics framework is the logical choice.
Even if that weren't true, let's just say that I disagree with the advice given by the linked MSDN article. The "legacy" status here has more to do with which technology the Windows team thinks is cool this week. The status designation of "obsolete" just means that the group responsible is no longer accepting or fulfilling bug reports (except for critical security issues). Not too big of a deal—these technologies have been around long enough that they're fairly feature-complete and stable.
GDI isn't going anywhere, so if you need something rock-solid that is guaranteed to be supported anywhere and everywhere, that's what I would go with.
If you need a bit more 2D capabilities than GDI offers (e.g., alpha channel transparency), then you could consider using GDI+. It's nearly an order of magnitude slower than GDI, but that's not too big of an issue on modern machines with more power than you could ever want. This, too, is going to be supported for a very long time to come.
That said, if I were writing a new app today, I probably wouldn't bother with OpenGL. There's very little that it offers in benefits over Direct2D and DirectWrite, which are both what Microsoft is pushing as the replacements for GDI/GDI+. There might be some benefit to using OpenGL if you absolutely must target Windows XP because as far as I can tell, Direct2D/DirectWrite are only supported on Vista and later, but that's because (as I mentioned originally), Windows XP falls squarely into the "legacy" or "obsolete" camp itself. Alternatively, if you already know OpenGL well and don't have time or the desire to learn Direct2D/DirectWrite, then it might make sense to continue using it in a new application.
Don't let the verbiage of the MSDN article scare you. Choose whatever technology makes the most sense for your specific use case given all of the available information. By the time any of these technologies go away completely, you'll have to re-write the app completely for a dozen other reasons.
Edit: Hmm, it looks like DirectWrite has also been declared (by some people at least) "obsolete" as well, having been replaced by Direct2D. That's funny, it hasn't even been around long enough for me to bother learning it. I guess that only goes to support my earlier argument that "obsolete" simply designates that a particular technology is not what is currently considered to be in vogue by the Microsoft devs.
I'm personally waiting until all the bugs get worked out of this stuff (and we decide on a semi-permanent standard) before I make the switch for any of my applications. Everything I've seen written in DirectDraw or Direct2D has had serious rendering bugs and is a performance nightmare, even on reasonably competent machines. Sure, they only show up sometimes, under the right conditions, but that's too much for me. And I swear, the blurry text shows up all the time. Not being able to read what's on screen is a deal-killer for me and my users. GDI doesn't have this problem, and it's not going anywhere.
Are GDI, GDI+ and OpenGL really obsolete/deprecated?
This is not true for OpenGL. OpenGL 4 allows you to use geometry shaders on winxp. Which isn't possible with DirectX (DirectX 10 and up isn't supported on WInXP). It is also one of the only cross-platform 3D APIs out there.
From a business point of view MS is interested in promoting DirectX since it is their technology that lock Developer into windows platform (they're also interested in making DirectX more attractive for developer, but that's another story). So it makes sense that they aren't keen on promoting OpenGL.
What else should be used?
I'd advise to stop using platform-specific tecnologies when possible. Grab cross-platform framework and use it for your application. There's Qt, GTK, wxWidgets and other toolkits for GUI apps, and SDL(and alternatives) for games. This way when platform developer decide to make ridiculous decision (like not supporting DX10 on WinXP) you dislike, you'll be able to move elsewhere with minimum development cost. Qt is also ridiculously powerful and at the moment I have no reason to use something else for GUI development. Still, situation can change in the future.
In short, while developing for certain platform you should keep in mind that platform developer might have their goals that are not compatible with your wishes. Discovering that your source has become locked into single platform isn't very pleasant experience. Your own goals should be the first priority, and if os developer tries to make you use certain technology you don't like, then you shouldn't support that technology.
Because OpenGL is a standard, it should be considered equally deprecated as C or C++ so it is a matter of time before the entire Windows API -- which today has become a compile once run on every x86 machine API thanks to Wine -- is considered deprecated in favour of .NET and C#.
I use GDI for simple graphics and OpenGL, when I need accelerated 3d.
Another aspect is that Microsoft's build-in implementation of OpenGL is definitely to be considered as deprecated since it is just version 1.1 or something, but that has been for a long time.
Yeah, about OpenGL, it actually outperforms DirectX in many ways both resource and display wise. It will never be promoted by Microsoft because it can't own OpenGL, not to mention most people don't do their research and Microsoft can claim it is old. Truth is opengl is opensource standard and evolves at a much faster rate than closed does because it is more than 1 room of developers paid to work on it. Also Microsoft has contracts with many companies to release using only Microsoft's software, this causes more business for Microsoft and less to use the more advanced OpenGL standard. It is a interesting lock up if you will, Microsoft creates these contracts so that many programs are written in DirectX to keep business for Microsoft, and no company will refuse it because Microsoft has about 80%+ home user market.
I am busy with a small project that allows for the controlling of an embedded hardware user interface to be moved from state charts and simple constructs as if .. else to a more visual representation.
I would now like to begin testing on a real project. I am looking for an open source hardware project. I've searched around but I have not been able to find anything that meets my requirements.
1/ hardware and software publicly available (i'm don't mind having to buy something)
2/ written in C/C++
3/ has graphical user interface
Any ideas?
Thank you
You might take a look at the open source QP state machine frameworks, which are also supported by the free graphical modeling tool called QM (state-machine.com). QP run on many embedded MCUs, including Arduino and mbed rapid prototyping platforms. The webstie contains a lot of information, including using statecharts for embedded GUIs.
This is not C++ but free with sources and might give you an idea:
If made to work on Linux, it may be combined with fpGUI on ARM.
Some articles point to Windows 8 development being HTML-based instead of primarily using native code like C or C++ (as it has been until now) or .NET (as now, or even more so as it would have been in Longhorn, but never was.)
Is this true? Will the core APIs be accessible from Javascript then? What is the primary API / framework for Windows 8?
This is worth asking. When Windows 8 was demonstrated in June, a couple of comments by the presenter scared quite a few developers - or at least turned the Internet into panic mode. I'm surprised this question hasn't been asked here before.
The best article on the topic I have found is Windows 8 for Software Developers on Ars Technica.
The short answer is: it will remain the same.
The long answer is: it will remain the same, but several things will be added. You may want to pursue using those if you're willing to bet on new Microsoft technologies. One particularly interesting one is WinRT, which is a new object-oriented native code API exposed through COM, which is supposed to be a new version of the old flat Win32 API. Details are in the linked article.
It is very, very, very, very unlikely that anything that already exists, especially based on Win32 or .Net, would be removed. That means your existing programs written in .Net or native C++ or Delphi will continue to work fine. It is also unlikely that the primary development platform will be HTML. More likely is that HTML applications will be encourage for specific scenarios - perhaps touchscreen, kiosks and tablets.
I'd encourage you to read the article I linked to above - it covers this in far more detail than any answer here can.
There are three ways to develop for Windows 8, and they all access the same underlying API, the Windows Runtime.
Use C++ and call WinRT functions much like calling Win32 APIs back in the day (you know, yesterday)
Use C# or VB and call what appear to be .NET methods (but aren't)
Use Javascript and call WinRT functions
The UI is built with XAML using a pretty reasonable designer. More details are still coming out: check http://channel9.msdn.com/Events/BUILD/BUILD2011 for videos with detailed coding demos. http://channel9.msdn.com/Events/BUILD/BUILD2011/BPS-1005 is not a bad starting point.
There are 3 language/framework combinations that are all equally supported:
C++ and XAML
C#/VB and XAML
JavaScript and CSS/HTML
All are first class ways to write Windows 8 Metro style applications. Windows Runtime provides direct access to each of these languages and so choice of development environment can be based on familiarity or feature set of the language and not on restricted availability.
Update: I forgot one: C++/Direct3D (for games).
The original quote, in the context of writing a tablet desktop weather gadget application, is that the application uses "our new developer platform, which is, uhh, it's based on HTML5 and JavaScript."
The demonstrator never said a gadget is the preferred type for applications (How many Vista sidebar gadget or Windows 7 desktop gadget have you written in your life? Even when you can write them in simple HTML!), or the platform is the preferred platform for desktop weather gadget applications (How many animation control have you add to your application with video playing requirement? It is THE control used by Windows Explorer to display video!).
Today, after spending a few minutes playing with Windows 8 developer preview, I found that you can use Expression Blend 5 to easily auto-generate metro-styled applications in HTML and Javascript. Also in Visual Studio you can create exactly looking applications in Silverlight. :)
I am very excited!!! Go Windows 8! :)
I worked mainly in web development but occasionally do some C/C++ or Java programming. I am very curious how these frameworks actually produce the graphics used in their GUI. Were the GUI elements (title bar, window frame, status bar, buttons, etc...) designed by a designer in Photoshop then a developer adds that graphic to the framework? Or do the developers actually build the elements programatically with the direction of a designer?
If someone could give me an overview that would be awesome!
Great question, Lark ! Since we're in Qt Framework branch, I'll tell you how its done in Qt, but I'm sure you can apply to similar frameworks or libraries like GTK, etc.
So Qt started a framework that would provide one API for a variety of platforms making it very easy to port your applications from one platform to another while providing native look and feel on those platform. So for example on MacOSX a push button would have this blue Aqua style while on Windows XP it would look like a button on Windows platform. Trolltech put a lot of effort and did a great job on making the GUI look native. So how it works ? Well, all Qt widgets use QStyle and its derivatives to render themselves. Depending on the style, a widget would look differently. All the standard widgets follow the guides of those platforms they are designed for. There are probably some small graphics designer work behind that, but I believe its not that significant. The main source of the look and feel is the platform guides that describe how UI elements on those platforms should look like and their behavior.
But Qt has been developing very fast and the trolls came with a very promising technology called Qt Quick. Its an amazing technology which allows designers and developers tightly work together providing the best UI. Its highly oriented on using artwork made in Photoshop, GIMP or similar tools in the code. And its much easier to use mock ups from designers with Qt Quick than with C++/Qt cause Qt Quick is initially designed for that.
Hope that helps
The basic low level functionality of most GUI frameworks is quite old, the result of a great deal of very hard work by earlier developers working with primitives - literally drawing things on terminal screens, etc, at very low levels, using C or Assembler. Slowly, libraries for abstraction of these processes, and frameworks and class hierarchies for refining them and organizing come into being. All Linux GUI's (in fact, nearly all contemporary GUI frameworks) are based on XWindows, for example:
X originated at the Massachusetts Institute of Technology (MIT) in
1984. The protocol version has been X11 since September 1987....X primarily defines protocol and graphics primitives - it deliberately
contains no specification for application user-interface design, such
as button, menu, or window title-bar styles. Instead, application
software – such as window managers, GUI widget toolkits and desktop
environments, or application-specific graphical user interfaces –
define and provide such details. As a result, there is no typical X
interface and several different desktop environments have become
popular among users.
See more there, for some good information about this topic.
my background: i've been developing web applications using php and javascript for the past ten years. before that, i've developed applications using turbo pascal for DOS. in my opinion application and web application development are two different kinds of development (at least it's what i think when i remember back the old days of DOS application development).
now i am in the need to go back to "normal" application development for various reasons. the application i want to build needs a GUI and it has to run on osx and windows. as mac os user it would be very nice for me to get an application as result, that really feels like an osx application. i don't need any special UI components: an explorer/finder like tree, a datagrid and some form-elements would be enough for my needs.
now the problem is, that i don't know where to start: i would classify me as newbie, because it's that long time since i last developed anything other than a web application. are there any recommendations of programming languages and gui toolkits with a not to steep learning curve? or can you recommend any book i should read for getting into cross-plattform osx/windows app development?
many thanks!
thanks everyone! i think i'll have a look at realbasic!
Edit Nov 2011 - a retraction
Most of what I say below is still true however I have now got serious reservations about recommending REALbasic for anyone trying to release commercial-quality applications. To save me remembering to edit this post later, see if RealSoftware have managed to release a robust version of their IDE using the Cocoa version of their frameworks. If not, be very cautious.
It's with a heavy heart that I write this because I still really like the language and think the framework and IDE are well-done. The problem is apparently one of under-capitalization and possibly a software development culture inside the company that consistently fails to deal with a bug regression problem. Many bugs are fixed each release but there appears to be a huge tax on the developers in the number of introduced bugs. They have a very small team for the complexity of the product, especially considering the newly released Web Edition which is effectively an entirely new platform.
It's still theoretically a great product but take advantage of the trial period, test it thoroughly on each of the platforms you plan to target and decide if you can live with any bugs you find because they may be there for a while.
REALbasic.
The language is a powerful, modern OO language that won't be hard for you to adapt to from your vaguely remembered Pascal or current JavaScript. It has most of the power of C++ without the dangerous bits that make debugging a nightmare. You will also find the IDE simpler and easier to deal with than say Visual Studio.
The IDE makes it very easy to throw together a GUI and have it just work on multiple platforms. The Pro version has one of the best cross-platform debuggers I've used and it is easy to just work (say) on a Mac and develop for Windows and Linux, compiling and testing with one click.
There is also a thriving community including many people at your level of expertise so you won't be mocked for being a newbie.
I am a professional software developer with over 25 years experience and currently mainly working in REALbasic, C++, C#, Objective-C and a bit of Ruby. For apps such as you mention, REALbasic is my tool of choice.
edit: I can't believe someone downvoted this but didn't have the guts to add a comment explaining why. I'd heard about prejudice against REALbasic but this is the first time I've encountered it. In what way was my answer inappropriate for this question?
Just to add to my cred, I've implemented cross-platform frameworks used by systems deployed to tens of thousands of end users - I have the C++ cross-platform experience to applaud someone else doing a good job and the REALbasic frameworks are very nice.
The best cross-platform tool I've dabbled in with a relatively small learning curve...especially if you're familiar with Visual Basic...is REALbasic. With REALbasic Pro you can compile a program to target Win32, Linux, and OS X from the same codebase, as long as you're not using OS-specific calls and features (which you can do with plugins or direct calls). Their support has been pretty responsive to my questions, the personal edition (which compiles to only the single target platform you'd downloaded the IDE for) is free for Linux and inexpensive for other platforms, but really you might want to download and try it out. One IDE, relatively inexpensive, and can compile native applications on OS X, Windows, and Linux...it's less hassle, and for me that's important when you want to get a job done.
I'd advise against C and Qt and would also recommend REALbasic.
With your background in Pascal and probably JavaScript you'll feel much more comfortable with REALbasic. I've done a lot of coding in Pascal and C/C++ - where Pascal guides you to avoid programming mistakes, C lets you step right in, even invites you, and then you'll have a hard time figuring out why it went wrong. Qt is a very abstract framework and requires you to learn a lot before you can get something working, just like with C. When compared to the easyness we used to have with TP back then.
RB is much more like Pascal in this regard. And its IDE is quite modern in regards to supporting your programming, with an easy-to-use GUI designer, straight-forward editor to fill in the gaps for handling UI events, code completion, etc.
Only when you get into huge program sizes, RB loses some of its appeal because it is missing tools to give you a good overview of complex class interactions etc.
Another thing is that Qt is more likely to cause ugly-looking Mac apps than RB would. RB visually guides you to get it all aligned nicely - in Qt you have to work with numbers, offsets, etc. to position your objects (at least it was that way when I used Qt 2 years ago).
I've written quite a few x-platform apps in RB and am pretty happy with the results.
You won't probably write those super-nice looking apps that compete with the best on the open small business market, but if you just want to get some solid code working, with an easy-to-design UI that's acceptable to the average user, give RB a try.
It's not free, though. But its rather small community is on your side - they're eager to help, instead of bashing everyone who's trying to talk sense :)
I'm new here but picked up on this thread through the REALbasic User Group. I think my position was similar to yours. I did website design for my work, using mostly javascript (with a little php, not much). I had a Pascal and BASIC background. I'd dabbled it C but didn't like the level of detail you needed to monitor it. It reminded me too much of assembly (which I still have nightmares about from my high-school/college days).
I was looking for a cross-platform language, with a familiar feel to it, but initially started with VB because it was free. I prefer programming in MacOS however, so I tried REALbasic. I found that REALbasic's UI builder was much easier to use than VB's. I'd echo other comments that the community is the most responsive of any user groups I've been involved with. I've since used REALbasic and my Mac to make several programs that over 100 users use every day at my work (on PCs, mostly XP and 2000). I've received compliments on the polish and ease of use of these programs. You DO have to remember to adjust the 'little' things to make it look right cross platform (ie: default button placement is opposite on PC vs. Mac, button sizes are different on Linux, etc). Many people have donated custom classes that do this stuff for you though.
People seem to assume that a "BASIC" language cannot be powerful enough for their purposes. While it is BASIC at it's core (with For..Next, Do..While, and If..Then commands), it ain't your daddy's BASIC. It's much more OOP than anything else I've used, based upon an event-driven structure, which for me was easy to pick up. They have a free trial, so grab a demo and run through the tutorial. If you get stuck, ask for questions on the NUG or Forums at the website and you'll likely get an answer quickly.
You may be interested in the following questions and answers:
Cross-platform development - Go with a cross-platform UI toolkit or native on multiple platforms?
Easiest cross platform widget toolkit?
Should I use a cross-platform GUI-toolkit or rely on the native ones?
Using a Mac for cross platform development?
and many others suggested in the Related sidebar of these questions.
Some answers suggest gtk (which is used by cross-platform gimp). Others suggest native approaches. Some suggest that a Mac is a nice platform for developing for Mac OS X, Windows, Unix and Linux.
I wholeheartedly recommend RealBasic too. I have been using RB for about 8 years now and find it to be a perfect tool for my Companies development needs, from small apps, to large multi-user systems.
It is perfect for beginners and those that are getting back into programming, and also for professional developers.
Highly recommended.
As Andy Dent and others here have indicated, for a newbie to create cross-platform applications it is hard to beat REALbasic (now Xojo).
Sure, there are plenty of other cross platform solutions such as QT (C++), Java, .NET (to some extent) and wxWidgets but they are not something a beginner would be able to use effectively.
I have many years of professional development experience in a wide variety of languages and technologies and I prefer to use REALbasic most of the time.
With that said, you might also consider Runtime Revolution or Adobe Air.
Whilst it might seem tempting to use a language thats platform independent and allow you to write the app once and use anywhere, you will undoubtably be sacrificing something on each, particularly in the UI and user experience.
If you can your best creating something using a native API that lets you take full advantage of the features of the OS to make your application shine.
I would definitely go for C++ and Qt, the code you write once will compile and run without problems on Windows, Mac and Linux. The new IDE that comes with Qt - Qt Creator is brilliant, works and looks the same on Windows, Mac and Linux, you don't need to anything else to start writing cross-platform applications.
I tried WxWidgets but didn't find good IDE, the best one was Code Blocks but GUI Designer is not perfect and has different problems on different systems and the IDE itself is still under heavy development.
Other options are Java and C# but those are not cross-platform languages, those are platforms themselves. Although you wouldn't need to compile code for each platform there will a lot of different issues on the way...
If your GUI's simple enough, why not just create a generic GUI layer, then program to that? Compile a version for each OS using native widgets. That's the best way to ensure native L&F on multiple platforms.
Both the Qt and REALbasic suggestions are good, although they tie you to that particular technology (which I can't imagine would be an issue in this particular case).
Personally, I'd go with Java, because it's worked for me before (I had an app that ran on my PDA, my phone and my desktop), but it doesn't use native widgets.
Adding a late comment here:
Take a look at Revolution. It's sort of like a modern Hyper-card on roids. And it's cross platform (Mac, Linux and Windows). This is a serious competitor to RealBasic and is coming on strong. Though I still use RB (and like it) I'm giving Revolution a serious look at.
I would also look into either Realbasic or Revolution. They both create cross platform native apps. Personally I think Realbasic would be a better choice as it is very similar, language wise, to VB. You can learn some valuable skills with RB and it can grow with your experience. I have been using VB and RB for more then 10 years combined and I think you will be happy.
If you need your code to be cross platform, you would have to go with something like QT.
Although, I would recommend using native API for each one (Cocoa for Mac OS X, .NET or the Win32 API for Windows). User experience will be much better. But of course, that will cost you more money in terms of developers hours.