I'm using Delphi XE2 on Win7 x64, compiling for Win32.
I've started using CSIDL_LOCAL_APPDATA to design installations for my first software release.
I see on MSDN that as of Vista, MS wants us to start using KNOWNFOLDERID values instead of CSIDL values:
However, when I try to replace GetSpecialFolderPath(CSIDL_LOCAL_APPDATA,false) with GetSpecialFolderPath(FOLDERID_LocalAppData,false), XE2 won't recognize FOLDERID_LocalAppData.
I would think that since XE2 came out long after Vista, that there should (if you'll forgive me) be support/recognition of these constants (?) in Winapi.Windows in XE2.
If not, does anyone know if Win10 still recognizes CSIDL values?
Not everything in the Win32 API that Delphi natively supports is implemented in the Winapi.Windows unit. For instance, CSIDL support is implemented in the Winapi.SHFolder unit, and KNOWNFOLDERID support (which yes, does exist in XE2) is implemented in the Winapi.KnownFolders unit.
GetSpecialFolderPath() is not a native Delphi function, so you must be using third-party code. CSIDL is an Integer that is passed to SHGetFolderPath() (or older CSIDL-based functions), whereas KNOWNFOLDERID is a TGuid that is passed to SHGetKnownFolderPath() instead. So you can't just pass a FOLDERID_... constant to GetSpecialFolderPath() unless it has been overloaded to accept either a CSIDL or KNOWNFOLDERID as input.
Related
I am used to using Win32Ada library for calling system calls for a terminal program that I was creating for Windows. The system calls were sufficient to achieve the control needed over the console, but nothing in Ada standard library would be. Examining the list of sources of GPS Community edition, I found Win32Ada missing. I am ready to continue using Win32Ada, but it is implied by its exclusion (as was the case with the POSIX exclusion for the Linux build years ago) that there is a better way to achieve low level interface. Can anyone give me the simplest code or reference to how I may interface with Windows in the way that will be supported from now on?
Example of before:
pragma Ada_2012;
with Win32;
with Ada.Text_IO;
...
I'm not sure that the exclusion of the win32ada library from the GNAT Community Edition implies it's obsolescence. The library is still available on GitHub and no obsolesce is mentioned in the README file. You just might have to clone, build and install it yourself.
Note also that win32ada seems to target 32-bit as well as 64-bit Windows. From what I know, the difference between 32-bit and 64-bit Windows boils down to the size of the pointers being used. These pointers are represented by the types ULONG_PTR and LONG_PTR defined in win32.ads where their sizes are defined using Standard'Address_Size; an attribute exposed by GNAT. Furthermore the fact that win32ada links to files like user32.dll and gdi32.dll with the number 32 in their names is irrelevant when it comes to targeting 32-bit or 64-bit Windows as is mentioned in e.g. this post.
That being said, you might, as an alternative, also want to check GNAT.OS_Lib. This package contains an abstraction to various OS related facilities (see also "Help > GNAT Runtime > GNAT > OS_Lib" in the GPS IDE). Depending on this package instead of win32ada might make your program more portable between operating systems.
You could take a look at the Visual Studio plugin for Ada, Visual Ada which has some UWP support for Windows 64
Visual Studio Community edition is free.
If you really really want to use win32ada, then you may have to contact AdaCore and see if they support it for their paid version or stick with the one supplied with GNAT GPL 2017 for windows 32bit (which is still downloadable). You could potentially pair it with a more updated Ada compiler from msys2 which has both 64 and 32 bit versions of GNAT that are maintained.
Have a look at how it is done in GWindows: the whole framework builds for both Win32 and Win64. Especially, you'll find in the package GWindows.Types how the detection 32 vs. 64 bit is done automatically:
type Handle is new System.Address;
Null_Handle : constant Handle := Handle (System.Null_Address);
type Wparam is mod 2 ** Standard'Address_Size;
type Lparam is new Wparam;
type Lresult is new Wparam;
I am not sure if StringCbPrintf and the include file strsafe.h where it is defined belong the the WinAPI. On one hand, Microsoft documents the function on its WinAPI sites and strsafe.h is under the Windows SDK directory structure which indicates (to me, at least) that it is indeed part of the WinAPI. On the other hand, strsafe.h includes stdio.h etc. which belong to the CRT. I was always under the impression that the WinAPI is completely independent from the CRT (but not vice versa). Possibly, my assumption about the relationship between WinAPI and CRT is wrong. Thus my question: is StringCbPrintf part of the WinAPI?
The StrSafe API is a bit strange because it does not have its own .DLL nor its own exported functions. I assume it was developed this way because it needed to support older versions of Windows that had already been released. It was created during the WinXP service pack security push:
During February and March 2002, all application development in
Microsoft stopped and developers took part in the Security Push
initiative. The goal was to check all code for possible security
vulnerabilities and fix those problems. One of the outcomes of the
Security Push was a library of safe string functions called
"strsafe.lib" with an associated header called "strsafe.h." This
library is available through the Platform SDK that can be downloaded
from the MSDN web site and is automatically installed as part of
Visual C++.NET 2003.
As far as I can tell, a copy of strsafe.h was also included with Writing Secure Code (Second Edition) by Michael Howard and David LeBlanc but I'm not sure if they are the original authors (David LeBlanc is the author of SafeInt):
You can find a copy of Strsafe.h in the companion content in the
folder Secureco2\Strsafe.
msvcrt.dll is basically a system file these days, only Windows 95 shipped without it. You are not supposed to use it as your C run-time but SDK code from Microsoft can probably use it without issues.
msvcrt.dll is now a "known DLL," meaning that it is a system
component owned and built by Windows. It is intended for future
use only by system-level components.
If you want to use msvcrt.dll as your C run-time as well then you must use the WDK for <= Windows 7 but when using the inline version of StrSafe.h, as long as you link to a .lib that contains the required vsnprintf type functions it should not really matter which CRT it comes from. There is also a StrSafe.lib file but Microsoft recommends that you use the inline version.
You are correct that the Windows API is supposed to be independent of the CRT but StrSafe also supports stdin functions like StringCbGetsA and they did not choose to separate those into a separate header for whatever reason. That combined with the need for a existing vsnprintf type function to do the actual work means that StrSafe is somewhat attached to the CRT even though it is meant to be used by all WinAPI developers.
There is probably no true answer to whether it is part of the WinAPI or not since it is a bit subjective. Since it is included with the SDK in the include folder one would assume that Microsoft believes it is a SDK/API component and not a CRT component.
If it's not implemented in Windows and exported from one of its DLLs (as e.g. CreateFile() or CloseHandle() from kernel32.dll), I'd say it's not part of the WinAPI, even if it ends up calling things that are implemented in Windows.
Is there a built in function that converts integers to strings in Free Pascal, as in returns a string object of the integer input? I've scowered the Google and the docs for 2 hours now and have found nothing but false hope and disappointment. Using Lazarus 1.4.4 on Windows 10.
Also, why is pascal so complex/aggravating? There are tons of versions, IDEs, application support vs not application support, and the docs are mediocre at best (at least for Free Pascal, although Delphi's doesn't look too good at a glance either). It's so all over the place, it's like a giant tangled pair of earbuds.
Thank you!
As said there is inttostr, which is Delphi's way of doing it. The classic Pascal solution is str. Both work in FPC and Delphi, though inttostr might require a object oriented (Delphi alike) mode in FPC.
A string is not an object btw, but a first class native type.
Basically Lazarus/FPC and Delphi are the only really active native Pascal products. Typically the two last versions of Lazarus are in active use (1.4.4 and rc's for the upcoming 1.6). Some older versions are still visible on specially Debian and derivatives(because these versions are default in that Debian Stable).
For Delphi of course there are more versions in active use because a new version must be bought (in the Eur/$ 500-600 range).
The FPC docs are quite good, there are several thousands of pages (and the doxygen like tool is set not to generate pages without content). Lazarus has a different setting and generates also pages with skeleton info only.
For a totally self supported project (no major, continuous corporate sponsors, no dedicated FTEs, either directly it the project (like Firefox) or at sponsors (like e.g. LLVM) ) this is quite good.
I believe IntToStr() converts int to string in Free Pascal.
In C/C++, Windows executables are linked against static libraries that import DLL files containing Windows API procedures.
But how do we access those procedures from Forth code (e.g. GForth)? Is it possible at all?
I'm aware that there's Win32Forth capable of doing Win32 stuff, but I'm interested how (and if) this could be done in Forth implementations that lack this functionality from the box (yet do run on target OS and are potentially able to interact with it on a certain level).
What currently comes up to my mind is loading the DLL files in question and somehow locating the address of a procedure to execute - but then, execute how? (All I know is that Windows API uses the stdcall
convention). And how do we locate a procedure without a C header? (I'm very new to Forth and just a bit less new to C++. Please bear with me if my musings are nonsense).
In general case, to implement foreign functions interface (FFI) for dynamically loaded libraries in some Forth system as extension (i.e., without changing source code and recompilation), we need the dlopen and dlsym functions, Forth assembler, and intimate knowledge of the Forth-system organization and ABI.
Sometimes it could be done even without assembler. For example, though SP-Forth has FFI, foreign calls were also implemented in pure Forth as a result of native code generation and union of the return stack with the native hardware stack.
Regarding Gforth, it seems that in the version 0.7.9 (see releases) it doesn't have FFI for stdcall calling convention out of the box (it supports cdecl only), although it has dlopen and dlsym, and an assembler. So, it should be feasible to implement FFI for stdcall.
Yes, you could do this in Gforth according to its documentation. The biggest problem will be dealing with call backs, which the Windows API relies on rather heavily. There is an unsupported package to deal with this, see 5.25.6 Callbacks. I have not attempted this myself in Gforth, but the documentation looks adequate.
You might also want to check MPE's VFXForth. From their website:
Windows API Access
VFX Forth can access all the standard Windows API calls, as well as functions in any other DLLs. The function interface allows API calls to be defined by cut and paste from other language reference manuals, for example:
EXTERN: int PASCAL CreateDialogIndirectParam( HINSTANCE, void *,HWND, WNDPROC, LPARAM );
EXTERN: int PASCAL SetWindowText( HANDLE, LPSTR );
EXTERN: HANDLE PASCAL GetDlgItem( HANDLE, int );
This is down the page a bit at VFX Forth for Windows.
As I do my Forth on Mac and Linux, I can't work through the Windows for Gforth to provide more detail, sorry.
Gforth 0.7.9 provides Windows API calls generated by Swig from the Windows header files. The C interface uses a wrapper library, which is compiled by the C compiler, to pass parameters from the Forth stack to the system functions; as the C compiler understands stdcall, and the header files declare Windows API as stdcall, this "just works".
As all pre-generated C bindings live in the directory "unix" (for historical reasons), include unix/win32.fs gives you the win32 part of the Windows API.
Callbacks in the event loop are still a problem, as Gforth is a Cygwin program, and Cygwin has its special event loop task... but I hope that problem can be fixed.
I'm coming from C# background, learning C++, specifically on the Windows Phone 8 platform.
Many code samples (installed with the SDK) show usage of the Hat operator ^ (Reference here: Types that wear hats).
For example:
void PhoneDX::Initialize(CoreApplicationView^ applicationView)
{
// ... function body
}
I am wondering:
Why are most of the pointers being defined in that manner, specifically on Windows Phone 8 ?
Is that syntax mandatory? Suppose i am using a C++ native library from another platform (that doesn't use this syntax). Should it work with no issues?
A hat is a compiler-supported smart pointer type that is designed to make Windows Runtime types easier to work with from C++ code. As discussed in "Types That Wear Hats" and the other articles in that series, the C++/CX language extensions are optional: any code that can be written using C++/CX can be written in C++ without using the language extensions, albeit at greater code complexity and verbosity.
The key here is that hats are designed to facilitate code that makes use of Windows Runtime types. In general, you should confine your use of C++/CX and Windows Runtime types to the boundary of your components: most of your code should be standard, portable, normal C++ code. C++/CX should be used (1) to wrap C++ code to make it consumable through the Windows Runtime and (2) to use other Windows Runtime components from your component.
So, yes, the syntax is optional, but you should strongly consider using it when writing code that must work with Windows Runtime types. You should be able to use any ordinary C++ code, without modification, with the caveat that Windows Store apps and Windows Phone apps run with low privileges and some facilities are not available (e.g., there is no console, so console I/O doesn't work, and the runtime provides specialized process lifetime management facilities, so calling exit is a bad idea).
You might have a harder time grasping it since it's somewhat of a compound leap from (1) C# references to (4) C++/CX hats, with a stop in the middle for (2) C++ pointers then (3) reference counted objects.
The ^ smart pointers are a language extension, not part of standard C++, for handling the Windows Runtime types (which are reference counted)
so answering your points:
If you're seeing them a lot with Windows Phone 8, it's because ^ is used for Windows Runtime types, which would be used a lot in that platform samples (since the samples are trying to demonstrate that platform's api and features).
You would need to use conventions for that library, which would probably require that you use the types it defines (if it has its own smart pointers) or standard/regular pointers (i.e. *) or Standard Library smart pointers (i.e. shared_ptr).
Some concepts that should help you understanding this would be the lifetime of C++ objects, deterministic destruction (vs. waiting for a garbage collector to kick in), reference counting, stack/static vs. heap/dynamic allocation of objects.