Is it possible to create a new, arbitrary, file namespace scheme in Windows?
As best I understand, Windows currently understands two or three file system or file-system-like namespace schemes:
The namespace scheme we all know and love, eg, C:\path\to\file.
UNC paths, eg, \\server\path\to\file
One, perhaps uncommon scheme - the Windows NT Object Manager, eg, \\.\Device\COM1 - see WinObj on SysInternals, usually accessed by programs by calling CreateFile, though this is not really a file system.
Is it possible to implement a custom namespace scheme that would be universally, automatically used by the rest of the operating system? Perhaps a filter driver or some other specialized kernel-mode driver? I'm out of my league here, but I'm genuinely curious.
I don't have anything concrete, but lets say I wanted to implement a kernel driver that, not only understands how to read and write OpenVMS file systems, but also implements some sort of filter driver so that userland programs could use standard File-11 syntax to access such a filesystem.
For example, an existing program calls OpenFile("[DIR1.DIR2.DIR3]FILE.EXT;10"); and somehow a custom handler deals with it transparently, and lo, notepad can read and write VMS files. More importantly, perhaps, some ported program that expects OpenVMS File-11 path strings just works. Simply mapping the OpenVMS file system into the regular windows file system as D:\dir1\dir2\file.ext would be insufficient.
I should clarify that my OpenVMS reference is just an example; I'd be looking for a more generic solution. This could be for OpenVMS File-11, MVS, standard unix syntax ala /path/to/thing, or something I just cooked up myself.
I'm aware of shell-based namespace extensions, and compatibility layers like cygwin, but that's not what I'm looking for.
So SO, what do you think? Is this possible? Where do you start?
Related
I was asked by a friend to write a simple GUI containing some charts and selections of common commands for an application he wrote in Forth. However, I have basically zero knowledge about Forth, only that you can't write a GUI in this language (at least that's what he told me).
Now I've been wondering what other programming languages you would suggest which do interact well with Forth and provide libraries (e.g. Java Swing) for interface programming?
Note: I'm still a beginner in programming, and my experiences so far are limited to Java, HTML, CSS, JavaScript, and some C#.
Win32Forth comes with complete Windows GUI and words to use all user32.dll and gdi32.dll functions. It also has a great development environment and windows form creator and editor. Very easy to create user interfaces with it.
SP-Forth allow developing applications with GUI and library WinLib: http://spf.sourceforge.net/ UI libs: http://spf.sourceforge.net/docs/devel.en.html#ui
I would suggest XHTML and Co. (i.e. CSS, JavaScript, XSLT, HTTP) to create user interface (GUI) and interact with Forth. In most general case you include an http-server into Forth system. In some special cases a Web browser object can be embedded into Forth application (for example, using COM on Windows).
Also on Windows you can use HTA (HTML Application) — quite simple solution. HTA can be started from Forth as well as Forth from HTA.
Another way is to use Qt framework (some Forth systems can have bindings).
Yet another way — just use API to underlying system (like user32.dll and gdi32.dll on Windows). Some Forth systems contain GUI-libraries that are based on underlying system API.
Also as edge case, user interface can be implemented in any language as shared library or as separate process with IPC (inter process communication) to Forth system.
In any case, usually GUI is created using special languages, libraries or APIs. GUI is not a subject of Forth as general-purpose programming language.
Bernd Paysan's MINOS may be a way to write GUI code in Forth:
https://bernd-paysan.de/theseus/minos-1.html
Adding a GUI to a program written in Forth is no different from the same problem in any language. You either have to write graphic code yourself or be able to call graphic libraries. In both cases on e.g. MS-windows you have to call functions present in DLL's and you need the documentation of those functions. Most serious Forth's allow to call DLL's. Of course libraries that are internal to a different language are less easily used, but why would you want to? You then commit to that language and are better off using that language from the get-go.
Forth being an interpreter you can couple a plot program easily via a pipe, but that is a one way street. It may be viable if the plot program has the interaction ( such as enlarge, change scale, crop, print etc.) you need.
Does anyone know a good tool for compression files using Windows API function called RtlCompressBuffer? I want to compress an executable using this method.
RtlCompressBuffer is a fairly low-level tool. You'd normally use it to create some higher-level tool before actually compressing an executable.
Windows has a couple such higher level tools, depending on exactly what you want to accomplish. If you want an executable that's stored on a file system in compressed form, then you probably want to use NTFS compression. To compress your executable with this, you call DeviceIoControl with the FSCTL_SET_COMPRESSION flag.
If you want to compress a file for distribution (e.g., so a user will be able to download it faster) you normally want to put it into a cabinet file, which you might then ship by itself, or (generally preferred) package it up into an MSI package. As far as pre-packaged tools to do this, you'd be looking at Microsoft's cabarc. If you want to do the job in your own code, you can use the File Compression Interface (FCI).
Obligatory side note: although both of these do compression (and also support matching decompression), no I'm not really sure whether either (not to mention both) is actually implemented using RtlCompressBuffer. I don't believe Microsoft's documentation specifies their implementation in nearly that level of detail.
First, sorry for my poor English...
I want to add a virtual folder to Windows Explorer using a Namespace Extension (NSE), and I want users to be able to open this virtual folder to explore some path (e.g., c:\test).
How can I do this using Delphi? Thanks.
The place to start is the MSDN documentation: Introduction to the Shell Namespace. Naturally this is written from a C++ perspective but it's not too hard to map that across to Delphi.
Another excellent resource for such tasks is Code Project. For example: The Complete Idiot's Guide to Writing Namespace Extensions - Part I by Mike Dunn. In fact this is just part of an excellent series of articles on shell extensions.
At present Delphi is a poor choice because it does not produce 64 bit executables. This means that your shell extension will not run on 64 bit Windows which is now a serious limitation.
With the recent release of Delphi XE2 this limitation has been removed. XE2 is capable of producing 64 bit executables and can therefore be used to produce 64 bit shell extensions.
Basically a shell extension is a COM object that implements a set of interfaces. Which interfaces needs to be implemented depends on the type of the extension (there are some used by any extension, of course).
You can start reading here (you need some C -> Delphi translation, but when you start to work on such matters is better you get prepared to it), and then the reference is of course MSDN
http://www.shellplus.com/examples/namespace-extension-example.html
http://delphipower.tripod.com/winshell.htm
What are the differences, and in what cases one or the other would prove superior in some way?
First of all the function fopen can be used only for simple portable operations with files.
CreateFile on the other side can be used not only for operations with files, but also with directories (with use of corresponding options), pipes and various Windows devices.
CreateFile has a lot of additional useful switches, like FILE_FLAG_NO_BUFFERING, FILE_ATTRIBUTE_TEMPORARY and FILE_FLAG_SEQUENTIAL_SCAN, which can be very useful in different scenarios.
You can use CreateFile with a filename longer that MAX_PATH characters. It can be important for some server applications or ones which must be able to open any file (a virus scanner or a backup application for example). This is enabled by using namespace semantics, though this mode has its own concerns, like ability to actually create a file named ".." or L"\xfeff\x20\xd9ab" (good luck trying to delete them later).
You can use CreateFile in different security scenarios. I mean not only usage of security attributes. If current process has SE_BACKUP_NAME or SE_RESTORE_NAME privilege (like Administrators typically have) and enable this privilege, one can use CreateFile to open any file also a file to which you have no access through security descriptor.
If you only want to read the content of a file, you can use CreateFile, CreateFileMapping and MapViewOfFile to create file mapping. Then you can work with a file as with a block of memory, which can possibly increase your application's speed.
There are also other uses of the function, which are described in detail in the corresponding MSDN article.
So I can summarize: only if you have a hard portability requirements or if you need to pass a FILE* to some external library, then you have to use fopen. In all other cases I would recommend you to use CreateFile.
For best results, I would also advise to learn Windows API specifically, as there are many features that you can find a good use for.
UPDATED: Not directly related to your question, but I also recommend you to take a glance at transactional I/O functions which are supported starting with Windows Vista. Using this feature, you can commit a bunch of operation with files, directories or registry as one transaction that cannot be interrupted. It is a very powerful and interesting tool. If you are not ready now to use the transactional I/O functions, you can start with CreateFile and port your application to transactional I/O later.
That really depends on what type of program you are writing. If it is supposed to be portable, fopen will make your life easier. fopen will call CreateFile "behind the scenes".
Some more advanced options (cache control, file access control, etc) are only available if you are using the Win32 API (they depend on the Win32 file handle, as opposed to the FILE pointer in stdio), so if you are writing a pure Win32 application, you may want to use CreateFile.
CreateFile lets you
Open file for asynchronous I/O
Pass optimization hints like FILE_FLAG_SEQUENTIAL_SCAN
Set security and inherit settings without threading issues
They don't return the same handle type, with fopen/FILE object you can call other runtime functions such as fputs (as well as converting it to a "native" file handle)
Whenever possible, prefer object oriented wrappers that support RAII, like fstream or boost file IO objects.
You should, of course, care about the share mode, so fopen() and STL are insufficient.
Simple question here (though perhaps not such a simple answer):
Is it possible to specify a path for an (existing) named pipe that can be used by programs as if they were opening on a normal file?
According to this MSDN page, name pipes on the local computer can be referrenced using the following path syntax: \\.\pipe\PipeName, yet I'm having no luck using this from standard Windows programs.
As a side point, if anyone has any suggestions for interfacing with programs that are only capable of using the file-system in a more efficient manner than physical I/O (e.g. named pipes), I would be glad to take them.
It would only work if the programs are using the Win32 API CreateFile() function to open the files.