Printable View
I began programming windows two weeks ago. I did simple programs that draw a line or a circle or input a text.
Butmy question is: Is WinAPI enough to do "huge" commercial programs ??
what API does C# use for making GUI apps ??
what API does VisualBASIC use for making GUI apps ??
if they are different, are they better than WinAPI ??
All are wrappers of the old API.
Define better?
People don't like API because is hardcore coding from scrath, but yet...free of use non-standard libraries like VB, .NET, etc...
There are docens of programs build just in pure api...
There is actually nothing else than WinAPI in Windows. WinAPI is the only API that Windows uses - others are wrappers or runtime environments.
Going a little off topic here, but I too am new to windows programming. I've been at it for about a year now.
Anyway, I am not a professional programmer so I am not very knowledgable about these things. I only know C and so that's how I use the win32 api. I often tell myself that I don't use things like visual basic because I am doing a user interface that is more DOS-like than windows-like so it's easier for me to write the wndprocs myself, but it's a lot of work.
My question is, am I shorting myself by not using these other development tools? Are they flexible to use? Can you splice C code into them? I don't know anyone else that does windows programming and uses these other development tools to get a valid opinion from. Indeed, the couple of guys who told me about the stuff couldn't demonstrate anything to me when I asked them.
Maybe/maybe not. I tried VB once, didn't like it. I've coded in C/C++ using the Win32 API, and why it's been a bit tedious, it's not really hard once you get used to it. The biggest thing I think I abhor is handling a window resize where children in the window must resize with it. (And handling all the offsets/proportions needed.)
That being said: a little-known RPG I play was written in VB. Other apps I use are written in C/C++. For VB, C code can be called from the app in the form of a DLL. Not sure about C#.
I've also used a library called wxWindows, which offers a C++ approach to GUI programming. (And is portable.) The downside is that programs are larger (~500KB after stripping/compression, I think) and things take (much) longer to compile. (I have an old machine, however - when I get a new computer this point will be considerably less.)
In the end - choose the right tool for the right job. It's probably never a bad idea to add a tool to your knowledge. When a problem arises, just choose what you think would get the job done best. A lot of my programs that I've made used various things from Console mode C++ to PHP scripts.
I like Windows programming to be honest. But I see that people use C# or VB for "fast development". The only reason I use WinAPI is that I wanna use C++ cuz it's more fast and productive, also, it's the only programming language I know so far. I dont wanna tire my self with the .NET stuff while industry standard is available for almost every API
:)
To pass data between VB and C/C++ you can use technologies such as COM (eg an 'int' is different size in C compared to VB). This allows you to develop the UI in VB (or ASP web page) and the backend in C/C++ and communicate with the database.
Debugging is difficult however (stop COM, shut down VB IDE, rebuild C++ DLL, register DLL, start again...).
C# / VB.NET use the Common Run Time library and so should allow data to be pased without the COM marshaling the data across technolgies.
I use MFC to get the development speed of VB and the power of C++ and WIN32. Can always use pure WIN32 but I find the MFC wrapper quicker and safer.
People have a misconception about MFC as they do about VB. Both are good tools if you identify correctly, which is required for the given task.
I use all in my commercial apps as required and would recommend a basic understanding of all three (poss just the .NET version of VB).
It's so funny - I deleted all ocx files on my computer. :DQuote:
Originally Posted by novacain
The big difference between MFC and VB is that MFC is just a wrapper which wraps WinAPI, but VB runs on a run-time environment.Quote:
Originally Posted by novacain
I'm just used to use Win32 API and I can do everything easily with it. That's why I don't need MFC. I usually have enough time to do it with WinAPI and for many things I've made my own functions which I can easily copy-paste to another application.
No wonder - you have problems installing updates from Microsoft...Quote:
Originally Posted by maxorator
I did it lately, but I have had those problems with updates and Microsoft soft since... I don't remember.
I don't know what else you have manually "improved" in windows after installation before trying install other products...Quote:
Originally Posted by maxorator
Even if I did do something, I don't like any software that relies on other programs. Microsoft programs all seem to rely on eachother, sometimes you need 10 programs just to get one thing working.Quote:
Originally Posted by vart
I'm new to this forum, but I've been a developer for 25 years, Windows, Unix, Linux, C, C++, PHP, C#, Java - the whole map.
So, I thought I'd chime in with responses to the themes weaved through this thread.
To Hussain Hani original question, is WinAPI 'huge' enough for commercial programs?
Certainly. Some of the most ambitious types of applications are written in C++, aside from advanced research on, say, a machine with 4096 cores performing artificial intelligence simulations, or weather simulation or fluid dynamic simulations - but there's really no technical reason a 'high end' version of Windows in a 64bit version couldn't do that.
For examples of high end commercial applications written to the win32 API, look at 3D Studio Max, AutoCAD (and it's descendants like RevIt), PhotoShop and similar applications.
Actually, the C++ language is more important to these applications that is the win32 API. The win32 API simply gives you access to the underlying machine as presented by Windows. Where that API leaves off, there are tributaries for 3D (OpenGL and Direct3D of DirectX), and libraries for things like medical imaging.
One area where the win32API is not well suited is in real time systems. They are industrial applications where the computer must respond to events in predictable timeframes without fail, and Windows isn't geared toward that. Neither is Linux, in most flavors.
Otherwise, the most ambitious applications you find are written in C++, and were written in C before that time, with some applications of related sophistication coming from forms of Pascal (like Delphi).
There is, however, a new concept recently (in the last few years) introduced by Microsoft which to my mind has dubious or at least questionable value. I refer to .NET, for which C# is singularly devoted. All previous operating systems in common use, except for a few experimental works, are 'function oriented' interfaces. Linux, win32, win64, were all exposed to application code as a set of C function calls. This works, but there are no object abstractions available for them from the operating system.
Stroustrup hinted that this is just fine, and we should rely upon C++ libraries (for C++ development, obviously) to abstract the underlying C interfaces. That is, instead of opening a file using the OS C function _open or fopen, consider using a stream object or a file object from a library (perhaps even your own).
This thinking is behind the generation of frameworks like MFC, WTL, QT and wxWidgets, where the C oriented exposure of the operating system for GUI development is encapsulated by a framework of objects representing windows and, hopefully, other concepts. MFC isn't among the best of them, but it's an 'official' Microsoft product with lots of support.
I use wxWidgets myself, because I target all platforms that it supports (Windows, Linux and MAC). These frameworks are modeled on the underlying C interface provided by the API, with varying degrees of simplification, so using these frameworks is hardly a departure from win32 API development. In fact, using MFC or WTL as a framework hardly differs from 'pure' (as some call it) win32 development in that what you end up doing to make things work is all but exactly what those frameworks end up doing to make things work.
There was a time when the resulting executable size difference between a win32 API and an MFC or wxWidgets built application was important. That was also when 64Mbytes of RAM cost about $2,000. That problem is no longer important enough to outweigh the leverage provided to the developer who uses them to good effect. If the framework doesn't do something the way you want, you're still free to mix the win32 API approach as you see fit.
The .NET approach, which I mentioned before, is an object level exposure of the operating system. Instead of exposing the services of the OS as a set of functions, they are exposed as a set of objects. The distinction is an important one, if it serves us well, in that it is more obvious what to expect of an object that of a collection of functions (the grouping alone tells us what we can do with, for example, a DVD burner - instead of hunting down functions in an alphabetic list that's otherwise mixed between uses).
This would be all the better if it had been given as a set of objects native to C++, but they were not. Instead, Microsoft, in what I view as a business oriented motivation more than a technical one, decided to create an entirely new concept now called .NET, and make the objects conform to that standard (of their own proprietary creation) that to those native to C++.
.NET objects are native to C#, and secondarily native to Visual BASIC .NET (a different creation that Visual Basic prior to .NET). C++ can play along, though, if the C++ programmer is willing to accept an unhappy marriage of the standard C++ syntax and concepts to that of the .NET extensions. It works, but to no advantage for the C++ developer.
.NET is, among other notable differences foreign to C++, a garbage collected - or memory managed - environment. Objects from .NET are not handled by the kind of heap C++ developers have used for years.
To C# developers this offers the same underlying advantage, if that's what you think of it, as Java developers had when freed from pointers and allocation errors (otherwise known as memory leaks). As a result, those not familiar with C++ - and well practiced, say at least 5 years, will find C# a gentler environment, and thus will be fond of the ease with which they can forge ahead with the development of features without care for memory management problems. This has an early euphoric effect, but it's not entirely without fault. At some point, there's a penalty to be paid for garbage collection that C++ programmers avoid. Seasoned C++ developers have few problems with pointers anyway (we avoid them, using tools from our libraries to serve the problem without our concern, or we take over direct control and avoid the other issues garbage collection professes to free us from).
C# programmers, and many C++ converts to C#, praise the language. There's no doubt you can be fully functional and develop applications of fair ambition in C#. Their results can not, however, outperform a C++ application. They can, on occasion, develop their applications in less time, assuming they compare that time to a similarly novice C++ developer. Compared to an experienced C+ developer, it depends.
The .NET exposure of Windows promises to be more complete and easier to use than the win32 API counterpart. Many 'external' features are included. For example, there is no win32 API for controlling a DVD burner, for the purpose of writing to the DVD. There are libraries available, few of them free, that provide that service on pre-XP versions of Windows. For .NET developers, however, the developing a DVD burning feature is almost trivial, and is an object from the .NET libraries.
Technically, there was no reason Microsoft could not have provided a C++ library of interfaces to match this object level exposure, but they chose not to. C++ is a portable language. Over the years it became increasingly practical to develop cross platform applications, more so in C++ than in C. While C code can be written to be portable over many platforms, writing to the various API of different operating systems is not a portable option in C. C++ objects, however, provide an abstraction of the GUI to such an extent that with frameworks like QT and wxWidgets, you can create one body of code that runs (compiled separately) on various platforms - and performs natively (as in, fast, local look and feel).
That's not in Microsoft's business interest though. Instead, they've created a set of technologies that all but intoxicate both the technical and business interests of developers, creating a gravity of a kind that impels developers to create Windows specific applications. They created a seductive environment in both .NET and C# that enhances the productivity of novice developers, making the results of work faster and cheaper.
This isn't entirely bad, else developers wouldn't be drawn to it. However, if Linux Desktop continues to draw interest, and Vista continues to 'flop' in the eyes of consumers, there could come a time when entire libraries of applications developed with features so specific to Vista literally can't migrate to Linux and Mac. This serves Microsoft, but delivers a cost to the developers which can't be measured for a few more years.
While it's possible Linux will not capture significant user interest, consider the history of Netscape and how that compares to the history of Firefox.
There are ways to run C# applications on Linux. However, one must be careful to develop C# applications in ways that do not rely upon Vista specific features, and that's not simple to do unless you develop on Linux. Gravity pulls them away from that because you can't find a better development platform that Visual Studio 2005. It's absolutely luxurious compared to other debuggers, compilers and tools.
So, what I'm saying is that the choice of development tools and platform targets are not entirely based on new trends and common 'wisdom'. The choice requires us to consider what we're making and what our market is, today and in the future.
Vista, in my mind, is a flop. I client of mine purchased a new Dell laptop for his wife with Vista pre-installed. They had a choice between Vista and XP. They didn't ask me first.
After two weeks with the new laptop (a beautiful dual Core2 machine), the new owner begged me to help her install XP over Vista. So many things she had become accustomed to in XP just didn't have drivers, or wouldn't work correctly. I think the duplicate email transmission when she applied attachments was the final straw.
Still, Vista will take hold as new machines are shipped. Microsoft is increasingly self serving and I dare say surreptitious about their designs. They already announced the end of XP. What if they decided to stop XP activations? They have no legal requirement to continue, if my reading of the EULA is correct. They could literally force XP owners to either decide to downgrade to Windows 2000 (which I still run as my primary OS), or to spend $150 or so to upgrade to Vista....and for what? Just to keep things running like they were?
Similarly, this gravity to generate Vista specific applications is insidious. It implies a reduction in non-Windows variants of cross platform applications, and forces developers into supporting Microsoft's interest in selling updates to operating systems.
Technically there's no reason to require XP over 2000. Nothing XP ever did was impossible to implement within 2000. I purchased a copy of Adobe Premiere, and was forced to upgrade to XP (which I installed as virtual machine, keeping 2000 on my computer) to install it. Why? There was no service provided by XP that wasn't provided by 2000, save one.
The objects that write to the DVD!
Adobe literally bought into Microsoft's gravitation toward upward service, without backward compatibility, in order to support obsolescence without reason.
The trends toward .NET and C# are doing the same thing, and developers who unwittingly follow that trend are supporting something for Microsoft's benefit without even considering their own.
Out of the 7 major hospitals in the area where I live, 6 run Windows 2000 on all workstations.
The other runs XP, and recently announced Vista is an absolute impossibility.
That trend is echoed elsewhere, yet Microsoft tools will gravitate you toward making XP and Vista specific applications if you don't think to select the options to avoid it.
With all that, I still write using Visual Studio 2005, but I write using wxWidgets, and compile and test my code on both Windows and Linux (in 3 flavors). For that I gravitate to C++, but then I've known C++ since 1987.
If you're making business applications (which I sometimes call 'bag of fields' applications), using C# is probably a good idea (maybe even the best choice), so long as it's on a version of .NET friendly to Windows 2000. That's because a sizable fraction (probably a majority) of corporate clients insist on Windows 2000 as their host desktop operating system.
On the other hand, Ubuntu proves to me that Linux can be packaged such that your typical end user could install and use it. That wasn't true just a year or so ago. At some point I think consumers, asking geeks like us what they should get for their new machine, might just be introduced, and they'll realize Microsoft isn't the only windowed GUI that serves their purposes. If so, C# development may tend to drop in importance, because the .NET support for Linux is not yet accepted as an industrial strength solution. Perhaps in time it may, and C# code, written specifically to avoid Vista or XP specific use, could be portable and serviceable to that audience. I can agree that this target audience is not well served by C++ applications in the general practice, but there's plenty of room for C++ developers to make the stuff upon which those system depend. Where do you think mono (the Linux .NET runtime) comes from?
C++ is demanding, even tricky. Correctly fans of other languages will warn about it. For those familiar with it, there's nothing better, except maybe the next version of C++ due in a year or two :)
There are ways around this limitation, which is due (in part) to the low priority of timer msgs in the OS que (lower than paint msgs).Quote:
Originally Posted by JVene
We use XP Embedded based industrial PCs to monitor heavy machinery in real time and so require finer/more reliable time resolutions than the >10ms Windows provides.
I used to be like you when I first started programming.Quote:
Originally Posted by maxorator
Ewwww! MFC I don't need the bloat to do something I can hand code!
VB is the spawn of satan and only used by those who can't write REAL code!
Then my programming skills matured and I came to understand that a good programmer uses the right technology for the task at hand and mixes them when you have to.
Why spend a day coding/testing that app in WIN32 when I can do it in VB in a hour?
I suppose it is different when it is your living, to just playing around trying to be 'leet.
WinAPI32 is great in my opinion. Also, imo, it's the best 2D games tool.
The only problem i'm facing is the the functions and the messages, that's why when I program, I open all my WinAPI32 books as references :)
but that's actually not a big problem, since i'm getting used to it
thanks all for replies
When you can write WIN32 code, without ever refering to MSDN, then you are the uber one.....grasshopper.Quote:
Originally Posted by Hussain Hani
When programming commercial stuff, then performance is usually important. VB is not good at that. But MFC makes almost the same result as Win32 I guess.Quote:
Originally Posted by novacain
You're kinda right. But VB is not a good thing for beginners, because they really learn writing good code and following standards better in C/C++. I would only use VB for personal tools or little freeware applications.