macOS Windows programming

[kainjow]

Here's the deal. I'm working for a company and have created a Cocoa installer-like app, and another guy has created a Windows version. However, the Windows version was made for .NET 2, so every user who wants to use it needs .NET 2 (which requires Windows Installer 3).

mad: why can't M$ bundle the .NET framework with Windows </rant>)

Since the Windows guy only knows .NET, it's semi my responsibility to figure something else out that doesn't rely on .NET. Plus, I really want to have both apps share common code, which would be C/C++.

It seems to me that when doing modern Windows programming, the choices are:

• .NET (easy for developer, annoying for user)
• MFC (seems old now, don't think M$ will be updating it any more)
• Win32 (+- WTL)

The last option right now seems the best, although it would take the longest. Does VS support a visual editor for Windows? I know it can for MFC but it doesn't seem like it for Win32.

Anyways, anyone have any experience in this area? Has anyone used WTL before? That might make it easier. Or is there another option to explore?

Edit: what about Borland's C++ Builder?? Looks like it's still in active development..

 

[Catfish_Man]

Could just do it in java.

 

[kainjow]

Java has the same problem as .NET...

I did find an open source C++ GUI framework called SmartWin++. Looks interesting...

I also found some .NET linkers, which might solve our problem, but the filesize is still relatively huge.

 

[mduser63]

I thought I'd throw a reply in here, take it for what it's worth. I'm no expert on programming, especially Windows programming (I'm just learning to program, and it's all Mac stuff). However, my dad does a lot of Windows development, and I talk with him about his work fairly often. He does C/C++ development using Borland's Builder and highly recommends it. It is still actively being developed, and from what I hear from him, it's a really nice IDE with good support for doing GUI stuff.

 

[slooksterPSV]

If you're looking for an IDE, I use Dev-C++ when I use a PC and program a bit; it does have a lot of nice features (syntax coding, debugging utilities, massive support for various APIs [e.g. Allegro, SDL, etc.]) I'm not sure it'd work in your situation. I'd probably go with Borland. I have a Borland Compiler and I wish it still worked (cd is all scratched) cause Borland did a damn good job with their compiler tools. Try them out.


If you're talking about how to recode the .Net part, you'd have to be more specific.

EDIT: And borland has a GUI Window Editor so you can Edit and set properties of your Windows/Modal/Modal-less dialogs so you don't have to code it by hand (which its good to code by hand once in a while).

 

[kainjow]

Thanks for the replies guys.

I did look into Borland's C++ Builder. It's expensive though. But one thing I don't understand about this is whether they use their own API or just the standard libraries/Win32? I already have Visual Studio 2003 and 2005, so if they don't have a separate API then I'd just stick with VS.

I did check out Dev-C++ because it uses MinGW. It's pretty decent, but again I'd rather just use VS for any Win32 stuff.

I guess what I'm mostly going for is an easier GUI API. SmartWin++ looks decent, but I don't think it has all the GUI stuff I need.

I'm tempted to just write it all in Win32, but that would be a relatively large learning curve.

Windows programming sucks

Edit: OK I see that C++ Builder uses its own API, which is cool. It might be what I want.

 

[Palad1]

Microft Software Installer

Why don't you just the MSI sdk in order to create your installer?

It works out of the box on any windows version (since 2K) and supports some scripting.

If you need to copy files and do some basic installation stuff, use NullSoft's GPL installer, works great : http://nsis.sourceforge.net/Main_Page

ps: you may find some tool that compiles .net bytecode into x86 opcodes.. but I don't think they have been ported to .Net 2. Besides that is a very ugly hack and your binaries would end-up weighting several hundred megs more... (you have to drag the framework classes with you...)

Good luck

 

[cblackburn]

http://www.wxwidgets.org/

Chris

 

[AlmostThere]

why can't M$ bundle the .NET framework with Windows

I really want to have both apps share common code, which would be C/C++

Why don't you just bundle the .NET framework with your application and install it if necessary during the installation process?

Why not put this common functionality in a .dll and call from <language of your choice>?

 

[budugu]

Here's the deal. I'm working for a company and have created a Cocoa installer-like app, and another guy has created a Windows version. However, the Windows version was made for .NET 2, so every user who wants to use it needs .NET 2 (which requires Windows Installer 3).

mad: why can't M$ bundle the .NET framework with Windows </rant>)

Since the Windows guy only knows .NET, it's semi my responsibility to figure something else out that doesn't rely on .NET. Plus, I really want to have both apps share common code, which would be C/C++.

It seems to me that when doing modern Windows programming, the choices are:

• .NET (easy for developer, annoying for user)
• MFC (seems old now, don't think M$ will be updating it any more)
• Win32 (+- WTL)

The last option right now seems the best, although it would take the longest. Does VS support a visual editor for Windows? I know it can for MFC but it doesn't seem like it for Win32.

Anyways, anyone have any experience in this area? Has anyone used WTL before? That might make it easier. Or is there another option to explore?

Edit: what about Borland's C++ Builder?? Looks like it's still in active development..

If you ask me the last option that you want to use actually is a NO OPTION. Win32 APIs have been depricated ions ago .... so i would strongly suggest against it. If you ask me use .Net2 framework + C# .... i know you want to share the code and all ... may be you can differentiate the GUI code from the core "model".

More over .Net framwork is a redistributable thing last time i checked ...
like DirectX when you are building the application you can also install/upgrade their .Net version. Or askit to get from windows update. So this route i think is the most simplest one than re writing large chunks of code on some given up API with out any future.

 

[kainjow]

If you ask me the last option that you want to use actually is a NO OPTION. Win32 APIs have been depricated ions ago .... so i would strongly suggest against it. If you ask me use .Net2 framework + C# .... i know you want to share the code and all ... may be you can differentiate the GUI code from the core "model".

More over .Net framwork is a redistributable thing last time i checked ...
like DirectX when you are building the application you can also install/upgrade their .Net version. Or askit to get from windows update. So this route i think is the most simplest one than re writing large chunks of code on some given up API with out any future.

I think you misunderstood. The app is already written in .NET 2. But .NET is a huge pain for users because they need to a) download .NET which is 22MB, and then they need to make sure they have Windows Installer 3, which is even more confusing to get. All for a little installer app.

Also, why do you say Win32 is depreciated? As far as I know, that is the *only* native API that exists for Windows? .NET is not native. Yes, it's *perfect* for when the user already has the framework, but virtually no one does.

The only problem with using existing installer apps is our installer has to be very highly customized on the fly, so that is why we developed it 100% ourselves.

Anyways, wxWidgets is a possibility, along with Borland C++ Builder. wxWidgets is free though, so that has some major incentives right there.

I'll keep exploring...

 

[cubist]

If the installer itself is written in .net code, you can't install the framework with it. If it were Java, then the JRE would have to be installed by the user.

As for win32 being deprecated, that's news to me. I only write C and Win32, not C++ or MFC. I get small executables that run fast and work exactly the way I want.

You could try writing Javascript that would get executed by WSH.

It's a shame you'll have to maintain two executables for a while, at least until Apple ports Cocoa to Windows. You could try wxWindows, but it doesn't come with any prebuilt libraries, so it could be weeks before you can write any code with it.

As for .net, it's just like VB, OLE2 and ActiveX: ignore it long enough and it will go away.

 

[pilotError]

Static Link

If you do a Static link do you still need the .NET dll's?

I never tried it to be honest with you, but it should work. I know it does with MFC, as I have built small apps for friends and didn't feel like distributing some of the DLL's along with it.

Mike...

 

[kainjow]

There is no built in way to do that, unfortunately. Xenocode is the most affordable way, but at $400 your compiled exe is several MBs larger. But it does remove the hassle of having to install .NET/Windows Installer 3.

 

[AlmostThere]

I think you misunderstood. The app is already written in .NET 2. But .NET is a huge pain for users because they need to a) download .NET which is 22MB, and then they need to make sure they have Windows Installer 3, which is even more confusing to get. All for a little installer app.

If the issue is purely about size, then there is not much you can do about it.

But if your principal worry (which seems to come across here) is users having to download different components, from different sources, with awkward names, then you can put .NET 2, Windows Installer 3 and your application all in one single package. The tool to use is the MS Component Installer SDK.

The user will download it, it will check to see which components need to be installed, install them and then install your .NET app.

Sorry to repeat if you already understand this - just checking before you start learning a new API and such like

 

[Oats]

Can you explain again why you don't want to use MFC? I use visual c++ and MFC a lot... I don't find that it is that much of a hassle, once you figure out a few things. Apps tend to be very small.

 

[weg]

Plus, I really want to have both apps share common code, which would be C/C++.

Have a look at Qt from Trolltech. This is probably what you want.

EDIT: If you can afford it, or if you are willing to open source your installer

 

[weg]

Can you explain again why you don't want to use MFC? I use visual c++ and MFC a lot... I don't find that it is that much of a hassle, once you figure out a few things. Apps tend to be very small.

MFC makes code sharing between the Mac and Windows pretty much impossible.. (unless there's a port to the Mac which I don't know about).

 

[weg]

If you do a Static link do you still need the .NET dll's?

How would you link the byte-code interpreter/JIT compiler with the byte-code binary ;-)

 

[pilotError]

Ignorance

How would you link the byte-code interpreter/JIT compiler with the byte-code binary ;-)

I am admittedly a little ignorant in the ways of .NET. I haven't needed it as of yet, but I was under the impression you could do unmanaged code and still build exe's that don't run under the JIT but still use the .NET libraries.

 

[Palad1]

I am admittedly a little ignorant in the ways of .NET. I haven't needed it as of yet, but I was under the impression you could do unmanaged code and still build exe's that don't run under the JIT but still use the .NET libraries.

This is what you are referring to

And this is another way

 

[mbabauer]

Java has the same problem as .NET...

I beg to differ...Java is a perfect language. And, since it seems like you are probably doing very simple tasks, one could EVEN suggest using the GNU compiler to compile the Java bytecode into an actualy self-contained executable. I have not done this myself, but I have seen it done first hand, and is REALLY simple. What you get is a natively compiled, stand-alone application for that specific plateform. Its not cross-compatible, since you have taken the JVM out of the picture, but the code would be identical.

Another way to go is to use the Eclipse SWT/Rich Client framework. It is much nicer than Swing, compiles to a native executable, and has TONS of OS feature Swing doesnt, like the ability to add icons to the tray and a bunch of components that Swing is missing.