I was wondering if it's possible somehow to use windows.pas on OS X with Lazarus?
I need to use special library in my project, and one of key-files uses windows.pas :( Any ideas?
Windows.pas only works on Windows. You will have to edit the library to put an IFDEF around it in the uses clause, and then provide alternatives for any functionality that is then broken. Or contact the library author and see if there is already a non-Windows version available.
You certainly cannot use Windows.pas under OSX. Because Windows.pas exposes the functionality of the Win32 library.
If you need to execute Win32 code on OSX pretty much your only option is Wine.
A more plausible solution is that you find an alternative to this "special" library to which you refer.
Windows.pas is mostly a wrapper around different DLLs contained in the Windows operating system. As it is unlikely that you will find those DLLs in OSX I guess you are out of luck.
You could check the library's source code and try to identify the constants, procedures and functions that are used in windows.pas. If it is not too much code you could try to modify the library so that it uses corresponding Carbon functions instead.
While the various answers are correct, and the vast bulk of unit windows is not portable, some functionality IS abstracted. Structures like interlockedincrement, Rect and ColorRef, and some message related functionality. Have a look at types and lcltype and the system unit interface of FPC.
A lot of Delphi code still uses Windows for that functionality, while e.g. unit types already exists since D6.
Some other things are abstracted, but not using the same (windows unit) calls. Better explain what exactly you need in a separate post.
Related
I am trying to understand how code, regardless of the language, works. Specifically thinking about software that runs on Windows.
Is my understanding correct that every built in function of a particular language maps to an exposed function in the Windows API when writing software for the Windows platform?
I guess my question can be even more generally, can a language do anything outside of what the OS provides? If so, how? What is an example of this?
There is a theoretical and a practical answer to this.
Practical: yes.
The WinAPI is the API everything uses to do things on Windows. It’s stable and compatible between versions so you can write whatever you want with it and it will work on practically any version of Windows given you don’t use any APIs that aren’t present in an old version. There isn’t any other interface to talk to the operating system properly.
Any language or platform that wants to work on top of this will call WinAPI. C libraries, Python, etc all are written so that they work on top of it (often other languages use C or C++ libraries which use WinAPI).
Theoretical: no.
Windows itself includes a Native API which is the actual OS interface and WinAPI is built on top of this. It is not really used if it’s not necessary since it’s not really documented. It’s used in a couple of Windows components that need to run before the other parts of the system are running and you can build applications linking to this API. But since it’s undocumented it’s not really reasonable and may change whenever.
There is also the syscall level. Several Windows components provide the lower level services for operations done on the WinAPI level. You can write, for example, an assembly program and use the syscalls directly if you want to. Mostly you don’t want to so this is more of a theoretical rather than practical answer to different platforms communicating with the OS. These also may change based on the OS.
WinAPI is basically only one subsystem that runs on the NT kernel. For example, Windows Subsystem for Linux is another one which implements its own syscalls which are then translated to Windows ones. There has also been a POSIX subsystem previously.
So all in all it depends on which level you look at it, but the practical answer is yes. Everything practically runs on WinAPI.
Yes. Even if an application exits immediately, it uses a windows call.
So it is not only theoretical. In theory, as in practice, every Windows application uses the API, because there is nothing else to use.
Even if you try to rewrite each functionality you are about to use, you would eventually have to install a driver, and this also mean you would use the API.
This may be the wrong place...but since it's actually regarding a GUI toolkit I figured it might be appropriate here.
Anyways theres a Program (For anyones reference it's actually an automated modding thing for a game called Morrowind). Anyways it has a nice clean GUI layout, it's for Windows. And basically im trying to find out just what toolkit was used.
I've tried contacting the author, and I haven't seen anything about what was used mentioned anywhere. Is there any chance I could find out someway which toolkit was used in making this Program?
Or is that technically private information?
If the program runs on MS-Windows, Dependency Walker allows you to find out which libraries the program requires. The required libraries might give you a hint about which GUI toolkit was used.
On other platforms, ldd is often available and gives you similar information.
This only works if the GUI toolkit is dynamically linked.
Is there an open source program for Windows that offers the same functionality as Linux' /lib/ld‑linux.so.2?
You might want to look at the ReactOS project.
They should have everything to load DLLs, and it is open-source.
The loader is a core part of the OS on Windows; there's no open-source alternative I'm aware of, and I'm not sure it'd be possible to do it correctly in any case - you have to handle the minefield of assumptions that kernel32/ntdll have regarding address space layout, support SxS, ASLR, hotpatching, and more.
Open-source linkers are common (e.g., gnu tools), but I gather that's not what you're after.
The Enhanced Dynamic Linking Library for MinGW under MS-Windows may be helpful. Take a look especially at the bottom for the edll solution.
You mean using dynamic libraries? In Windows that's automatic when you use LoadLibrary on a .DLL.
I have a library for Haskell that can take an ordinary web application, run it on a local server, and then open up a window displaying that application using QtWebkit. The code to interface with Qt is very short. However, I would like to avoid the Qt overhead for Windows users.
It seems like the best approach would be to have an alternative to this QtWebkit-based C++ file that instead uses the MSHTML library on Windows. Unfortunately, I have almost no experience with Windows-specific libraries. It seems like I need to use the IWebBrowser2 interface, but that seems mostly speculative.
If someone can point me in the right direction on this, I would be much obliged. The final trick here is that it has to compile with MinGW. Not sure how much of a complication that is in this case.
Thanks
You can use hdirect to call the IWebBrowser2 interface from Haskell. It's messy to code against OLE/COM but it can do the job. Making a C binding to the interface is possible but if you need MinGW then it may actually be harder than a purely Haskell approach.
After a long evaluation period of mainstream toolkits Qt, WxWidget, GTK i came to the conclusion that it does not make sense to religiously equalize the different platform. Now more then ever before.
In the days before Java portability meant, that platform dependent code was located in known places and should be small but not none. No write once, run everywhere marketing.
Is there any GUI tookit - experimental or commerical (even outdated or dead projects) - that is going this way. It would need to give me native widgets of course. I would like to have a look at them before i start my own toolkit
If you think this is a stupid idea tell me why (cause everybody else is doing it differently there may be a reason i don't see)
As someone who zealously believes that GUIs should be drawn with native widgets, I must say I've been very impressed with wxWidgets, although you mention that at the beginning.
As far as I know, wxWidgets uses native widgets whenever possible, and indeed it does also include platform-specific features that are neither possible nor relevant on other platforms. A good example of this is how you can use the native Mac OS X menu, while on other systems it won't do squat. There are other and better examples.
I must mention wxPython in particular, in case you either don't want to or just don't have the time to write a C++ program. wxPython astonished me when I tried it out first, and I even managed to make a stand-alone .exe file from it that worked on a fresh install of Windows 2000 without any updates or particular runtime environments.
If wxWidgets doesn't suit your needs, I wonder what would. :) Hurray for wxWidgets!
AFAIK, wxWidgets uses the platform's native widgets whenever possible.
Have a look at SWT, it tries to use the widgets of the underlying platform as much as possible.