I'm looking for a .chm creator on Mac, but can't seem to find one? There seems to only be .chm readers for OS X.
Are there any .chm creators for OS X?
Thanks
Probably not, because .chm files are specific to Windows, and are deprecated even there. Are you trying to produce Apple Help files? If so, check out the Apple Help Programming Guide.
Yes. The Free Pascal compiler has a creator library, which also should work on Mac.
Note that this is just a chm compiler, iow something that compiles .html (and .hhc/.hhk/.hhp) into a .chm.
The library is already in current editions of the Free Pascal project (2.4.2). A commandline frontend (a chm compiler that understands .hhp) is currently only in development releases (but will go live in the current months in 2.4.4 and 2.6.0)
Update: the commandline compiler is now live in 2.6.0. It doesn't support all features (like merging chms)
Related
With the release of Swift 3.0 being available for Mac OS and Windows, does this mean you can compile and run Swift code on Windows? If so what compiler do you use for Windows?
There is an open source project on GitHub that (quote) "provides an easy-to-use development environment for Swift programming for Windows applications": Swift for Windows.
System Requirement
Windows 10 64bit, Windows 7 64bit
NOTE
The project was initially hosted on Microsoft CodePlex, but then moved to GitHub.
Since Swift got open sourced, many more platforms were supported by Swift.
Linux was added shortly after it was open sourced, and just recently, the Android support for Swift was merged into the master branch.
You can track the progress of porting Swift to Windows here. As you might see, it's not currently being worked on actively by the Swift team, there is, however, a community port on Github trying to port Swift to Windows.
It is possible to write, build and run Swift code on Windows. With "Siver" and "Elements".
Silver is a free implementation of Apple's Swift programming language. With Silver, you can use Swift to write code directly against the .NET, Java, Android and Cocoa APIs.
Elements is a compiler and development tool chain for Oxygene, C# and Swift which targets the .NET runtime, Java/Android virtual machines. Elements is developed by RemObjects Software (https://en.wikipedia.org/wiki/RemObjects_Software).
HelloWorld.exe example here:
https://github.com/alexbaban/Various-Programming-Languages/blob/master/Swift/Building%20Swift%20Code%20On%20Windows.md
You say:
With the release of swift 3.0 being avaliable for Mac OS and Windows
But this hasn't been announced officially.
There's some projects, but nothing from Apple... yet.
And anyway, the site where you read this:
swift.im/releases.html
is not about Apple's Swift, it's an entirely different project with, unfortunately, the same name.
As far as I know: Swift is available for linux and you can expect swift for Windows, Android soon in the future.
If you want to use Swift language on windows, you must be rely on web based platform. For example: http://swiftstub.com , http://www.runswiftlang.com , etc.
Silver runs on Windows and allows you to compile Swift code to Java and .NET.
Yes, as of September 2020 Swift is available as a binary download for windows. There are even windows-specific instructions for getting started.
The OP asked about which compiler is used. I believe the swift binary is what actually builds the code into an executable. (As of the blog post in 2020, it was CMake, but swift packages are now supported, as well as the swift build command.)
This question is quite old, so no doubt the other answers were all correct when they were written, but this shows up prominently in search results, and should probably have a community wiki answer.
I'm new at programming on the Mac. I've got me a brand new copy of XCode 4.0. I've got people asking me what versions of MacOSX we'll be able to support but I'm not sure what to tell them.
I see options for selecting an "SDK" and other options for selecting a target version. It seems the lowest I can go is 10.4 though -- even though we'd like to support 10.3, if possible without a lot of pain.
My question is, could anyone give me a quick rundown of how sdk versions and target versions fit into this? As I'm coding, what kind of things do I need to watch out for to make sure I can still support the smallest version of MacOSX? Likewise, how do I figure the G4/G5 (PowerPC) versions of MacOSX into all this? For example, on Windows, if I write an app in c#, I know that all I need to do is make sure an appropriate version of .net framework is installed, regardless of the OS. Does something similar hold true for the MacOSX?
Thanks in advance.
I believe Apple has dropped PowerPC support completely, including Rosetta, in Mac OS X so 10.3 is out of the question.
If you want to support PowerPC, see this related question. It looks like a lot of work.
How can we restore ppc/ppc64 as well as full 10.4/10.5 SDK support to Xcode 4?
With the analogy to the .NET Framework, there isn't anything like that for Mac OS X built-in.
It is true for Mac OS X. If your program targets 10.3 SDK, it will be able to run on 10.3 or greater. I.e. the Base SDK project setting specifies minimum target OS version.
However, supporting 10.3 IS a lot of pain. Even 10.4 is not that easy, for example Objective-C 2.0 (most important, #property, garbage collection) is only available with 10.5 SDK or above.
The common solution in existing projects is to keep an old version of software available for 10.1-10.4 users, while the new versions will require 10.5 or greater (and also usually are Intel-only).
If you're starting a new project, you will probably want to distribute it via Mac AppStore, which only works on 10.6+, which means you can safely pick 10.6 SDK as the lowest target version.
Apple is way more harsh about upgrades than Microsoft. Mac users don't walk around with 10-years old systems on their laptops. The only reasons I can think of to still use 10.3 are using 10-year old mac, not having Internet connection and not knowing what “to update a software” means. So, I wouldn't care even about 10.4, not to say 10.3.
I have found plenty of articles and how-tos online about making plugins for Photoshop on a Mac. Trouble is, many are old, apply only to CS1/2/3/4, or refer to tools or APIs that (it appears) are obsolete. Some articles say you must use CodeWarrior, but it seems this no longer even exists in the Mac programming realm.
Today, in 2011, making plugins only for CS5 and only on a Mac running Snow Leopard, what is the proper toolchain and what libraries/APIs/frameworks should I be using?
I've gotten the impression that Carbon (whatever exactly that is) is old and to be avoided, but it's not clear if that's true for plugins. I am not clear as to whether I should use Cocoa (whatever that is) or not. I do think I will need Core Foundation (whatever...) Is there a choice about 64 vs. 32 bit or is CS5 purely 64 bit and that's that? (I prefer 64 bit, of course.) I do have the Photoshop CS5 SDK, and Photoshop CS5 itself installed.
Can XCode can be used as an IDE? I'll hand-code a makefile and compile at the command line, if that's easier or the only way possible. If XCode can be used, which project template to use? What is this "Mach-O" I read about, and how does that apply to PS plugins?
It's especially confusing since I'm a total noob at Mac programming of any kind, though many years experienced on Linux and other platforms.
Mission accomplished! (Months ago.. I just realized I had this question sitting here.)
Cocoa is useful for GUI settings windows and other things - it's a huge gob of stuff - but I ended up using it only for the "About" popup window for my plugin.
Completely forget about Carbon for the combination of CS5 or later, OSX 10.6 or later, and 64 bit. Apparently parts of Carbon had been made 64 bit in the past, but should be ignored now.
XCode is a fine editor. Start with a "dylib" project using C. C++ and Obj-C source files can be added without any fuss. There's no way getting around just needing to use XCode for some simple toy projects to gain familiarity with how it organizes things and builds apps and libraries. This is the only real "tool" needed; the rest is APIs - header files and libraries (or "frameworks" in the Apple world). While toying with XCode, get to know what a "bundle" is - a folder containing the executable and other files needed by the app.
Paths need to be set up to the Photoshop CS5 API, there being two or three specific directories to be listed. You may need to copy certain common source files out of the Photoshop example plugins directory, and there was a bit of trouble with a file named MachOMacrezXcode.h about which see What is the meaning of exit code 3 from Rez?
Unfortunately there were no truly useful examples of well-written plugins for CS5 on 64-bit. A combination of the Dissolve example, the SimpleFormat file read/write plugin, browsing source for plugins at http://www.telegraphics.com.au/sw/product/FilterFoundry and asking questions on the Adobe Photoshop SDK forum.
Pay no attention to the clumsy process of using some "Plugin Suite" for obtaining memory. It's like Microsoft's old 16-bit Windows API where you needed "memory handles" and thick malarky that is now several times obsolete. These days, good ol' malloc/free or new/delete are fine.
With all the arrowhead wounds I now have in my back, maybe I should write a book or something...
I need to support Windows 98. The Qt documentation claims this is possible, but there are no instructions. The distributed binaries of Qt 4.6 don't run on Win98 and the majority of Qt applications I have sampled also don't. For several apps that do run on 98, I have asked authors how they did it, but the common answer is that it was accidental and they don't know what factors caused it.
In searching the forums for help, I found only guesses that turned out to be wrong. For example, one belief is that to compile for Win9x, you must build the tools and the apps on that platform. Yet, things I found to run were built on newer versions of Windows.
What is required to build the Qt dev tools and then applications for Win98?
How about cross-compiling from WinXP or Linux?
Are there specific components that can't be made to run on Win98?
Are there particular difficulties with dynamic or static linking for Win98 support?
Here is as far as I'm going to get on this:
You can target Windows 98 using MinGW or VC++ 6 SP5 from any Windows version. Cross-compiling from Linux is doable but not easy to set up.
Qt 4.4.3 was the last version officially tested on Win98. To run the distributed binaries on Win98, you need to install older versions of glu32.dll and opengl32.dll that are available from Microsoft. Due to an unresolved bug, Assistant will launch but can't load the help files. The alternate version in the bin directory, assistant_adp.exe, works fine. It seems the only other potential problem is that QtOpenGL may use features not available on older boxes.
Qt 4.5.3 appears to be still compatible except for WebKit, OpenGL, and Phonon. QtOpenGL expects OpenGL 1.5, which I don't know is even possible on older boxes. I didn't look into Phonon deeply enough to see exactly what the problems are. QtWebKit now requires Win2K or better. The distributed binaries work mostly OK. Assistant depends on QtWebKit, so will not launch, but assistant_adp.exe still works.
Qt 4.6.3 distributed binaries are now completely incompatible with Win98. It may be possible to get some things working with MinGW 4.4 and a lot of hacking.
Building Qt Creator requires Qt 4.6.0 and either MinGW 4.4 or VS 2008.
Wow...interesting mission.
So, basically - yes, there is windows 98 support for Qt. The problem is that there is one big IF. For example if you even try to set some different QTextCodec::codecForName, you'll have to provide 3rd party ttf for this purpose, because in most cases Win98 will not recognize it as valid. If you provide the exact error, while compiling it on win98 machine, I could help you.
"How about cross-compiling from WinXP or Linux?" - If you use ONLY Qt libraries everything goes fine. Otherwise in .pro file, you have to link these libs under win32 and unix conditions. So you could even forbid your code, to be compiled and executed in other systems...
"Are there specific components that can't be made to run on Win98?" - Of course. In .pro file you could include different libraries, for different operating systems.
"Are there particular difficulties with dynamic or static linking for Win98 support?" - As far as I know - there isn't.
//off - But it still strange, that someone want to write application for win98, today...
I want to make an easy to deploy Windows application and was was wondering which programming systems can create totally self contained Windows .exe files?
As a plus, if the same can be done with MacOSX and Linux from the same source this would be a bonus. I took a look at Realbasic but they have since abandoned the single .exe concept.
update: i am looking for something that can run from Windows XP up to Windows 7, no matter what version of .NET is installed. Is this even possible?
Delphi compiles to one executable, and generates native windows executables. So no dependencies to any kind of framework. If you use Free Pascal (fpc) and the Lazarus IDE, you could even develop for Linux and Apple from the same source.
If your using external dll's this would become a bit more tricky, but you could pack them up in your resource file and still maintain the one exe property.
Update 2020: since #Vassilis & #Marco van der Voort commented on this, I would like to update my old andswer and add that go is a very good way to make self-contained executables. Even crossplatform compilation is realy simple.
You can certainly do this with C/C++. Technically the runtime libraries are required, but they should already be installed on any windows, mac or linux system.
With .NET you can compile to an EXE, but of course the .NET framework is required. For newer versions of windows it should be installed by default, but on older versions (XP or older?) it may or may not be there. And of course you couldn't expect mono to be there by default on linux or mac either.
For Windows the following languages are viable:
C (MS, gcc)
C++ (MS, g++, Digital Mars)
D (Digital Mars)
Delphi (Embarcadero??? how do you spell that? just trips off the tongue doesn't it?)
Fortran (Intel, Salford Software)
Visual Basic 6 (MS)
Lua (you'll need a special tool to do it, but it is doable)
C#, VB.Net, F#, J#, etc (assuming that you don't mind using .Net technology)
You can use Tcl/tk. The technology you should research is a "starpack", which combines a runtime executable (a starkit) with a platform-specific runtime (a "tclkit") to create a single-file executable. It's remarkable in the fact that it's not just compiled code, but an entire self-contained virtual filesystem that can include images, sound, data, etc.
This same technology works for many platforms from the same code base. The only thing that is different is the platform-specific runtime. You can even "cross compile" in that you can copy the runtime for multiple platforms onto your dev box and then build starpacks for each platform without having to actually be on each platform.
Tcl can do this, especially through producing starpacks. They can be produced for all platforms from the same code. Note that this also includes all the necessary runtime libraries (except for things like the C library, but you don't want to make that static under normal circumstances).
JavaFX 2.2 supports that. It allows creation of self-contained applications targeting Windows, Mac OS, and Linux.
Please follow this link for more information: http://docs.oracle.com/javafx/2/deployment/self-contained-packaging.htm.
I would recommend taking a look at AutoIt. It is an easy-to-use scripting language that will compile into an exe, so there are no runtimes needed. This would be for windows only though.
http://www.autoitscript.com/autoit3/index.shtml
From the website:
AutoIt v3 is a freeware BASIC-like
scripting language designed for
automating the Windows GUI and general
scripting. ... AutoIt is also very small,
self-contained and will run on all
versions of Windows out-of-the-box
with no annoying "runtimes" required!
c/c++
purebasic
delphi
vb6
i hope this help :)
Here's a good source for a number of basic-like programming languages that build small stand-alone EXEs. Some are cross-platform for Windows and Linux:
www.basic.mindteq.com
You can use Liberty Basic which is easy and cheap, you can easily make stand alone programs for windows but not possible to transfer to MacOS or Linux.
You can do this for Windows with .NET languages using ILMerge
ILMerge is a utility for merging multiple .NET assemblies into a single .NET assembly. It works on executables and DLLs alike and comes with several options for controlling the processing and format of the output. See the accompanying documentation for details.
However:
Currently, ILMerge works only on Windows-based platforms. It does not yet support Rotor or Mono.
QBasic can :-)
I wrote a few command line tools using it!