I want to do a very simple task, and yet somehow the hundreds of questions on SO surrounding the topic always manage to skirt answering this exact one (from what I can find).
The task is this: I want to view the source file that holds the Clipboard contents.
I know that older Windows OS had an option for Clipboard Viewers, and for newer OS you can use third-party viewers, but I want to view the actual source file itself. It has to be stored in some file somewhere, doesn't it? This answer gets close by at least letting me view the text natively without 3rd party software, but I still can't figure out where it's pulling its information from. I don't want the user-friendly version, I want to see whatever the computer is using (HTML, XML, UNICODE, C, or even binary, I have no idea).
There has to be some way to view the contents of that file in Command Prompt (or PowerShell), doesn't there? Why is this information so hard to find?
The short answer is through invoking the static method from the System.Windows.Form.Clipboard class in the .NET framework.
[System.Windows.Forms.Clipboard]::GetText()
This will work in powershell as-is, and will return to you whatever is currently stored in your clipboard.
Now, without going beyond the scope of our main topic being powershell/CLI, you can peruse through the class in User32.lib or User32.dll.
See: https://msdn.microsoft.com/en-us/library/windows/desktop/ms649014(v=vs.85).aspx
My original short answer should be sufficient for what I think you're looking to do, which is return the content of whatever is in clipboard back out to your powershell/cli host in plaintext.
This information was easily found by googling
powershell get clipboard contents
Also, if you want a more in-depth walkthrough:
http://powershell-tips.blogspot.com/2011/05/handling-clipboard-with-powershell.html
Windows is not a GNU/Linux OS. AFAIK there isn't really a clipboard daemon that stores content in a plaintext file somewhere on the filesystem. With .NET being natively available in powershell, you can just invoke these classes directly to get what you need.
Related
So I've recently been looking into the Control Panel, to try to see how I might be able to create a custom applet for it, like sometimes you get a custom one when you use a printer, and I just can't seem to figure out how to make one. I've tried opening one of them in a code editing software, and assume that they are compiled as all I get is a bunch of random characters, but I'm not quite sure whether it is or not. I've looked for anything related to it, but the closest thing to an answer I have is something about trying to make the applet show up, but it doesn't say how it's made, so its not really useful.
Thanks in advance.
There are two types of control panel applets:
.Exe files. These are normal applications and can be written in any language.
.Cpl files. These are actually normal .DLL files and can be written in anything that can produce a PE DLL with a named exported function (C/C++, Delphi or if you must, C#).
Support for .Exe applets started in Vista and is now the preferred method according to Microsoft.
All texts on how to create a compiler stop after explaining lexers and parsers. They don't explain how to create the machine code. I want to understand the end-to-end process.
Currently what I understand is that, the Windows exe file formats are called Portable Executable. I read about the headers it has and am yet to find a resource which explains this easily.
My next issue is, I don't see any resource which explains how machine code is stored in the file. Is it like 32-bit fixed length instructions stored one after another in the .text section?
Is there any place which at least explains how to create an exe file which does nothing (it has a No Op instruction). My next step then would be linking to dll files to print to console.
Nice question! I don't have much expertise on this specific question, but this is how I would start:
PE or ELF does not create pure machine code. It also contains some header info etc. Read more: Writing custom data to executable files in Windows and Linux
I assume you are looking for how does ELF/PE file hold the machine code, you can get that from this question (using objdump): How do you extract only contents of an ELF section
Now, if you want to know how the content part is generated in the first place, i.e. how is the machine code generated, then that's the task of the compiler's code generation.
Try out some resource editor like ResourceEditor to understand the exe or simply ildasm.
PS: These are mostly Unix solutions, but I am sure, PE should be doing something fundamentally similar.
I think the best way to approach it will be first try to analyze how existing PE/ELFs work, basically reverse engineering. And to do that, Unix machine will be a good point to start. And then do your magic :)
Not same but a similar question here.
Update:
I generated an object dump out of a sample c code. Now, I assume that's what you are targeting right? You need to know do you generate this file (a.out)?
https://gist.github.com/1329947
Take a look at this image, a life time of a c code.
Source
Now, just to be clear, you are looking to implement the final step, i.e. conversion of object code to executable code?
As in many of his articles, I'd say Matt Pietrek's piece about PE internals remains the best introdction to the matter more than a decade after being written.
Iv'e used "Wotsit's File Format" for years... all the way back to the days of MS-Dos :-) and back to when it was just a collection of text files you could download from most BBS systems called "The Game programmers file type encyclopaedia"
It's now owned by the people that run Gamedev.Net, and probably one of the best kept secrets on the internet.
You'll find the EXE format on this page : http://www.wotsit.org/list.asp?fc=5
Enjoy.
UPDATE June 2020 - The link above seems to be now dead, I've found the "EXE" page listed on this web archive page of the wotsit site: https://web.archive.org/web/20121019145432/http://www.wotsit.org/list.asp?al=E
UPDATE 2 - I'm keeping the edit as it was when I added the update erlier, thanks to those who wanted to edit it, but it's for a good reason I'm rejecting it:
1) Wotsit.org may at some point in the future come back online, if you actually try visiting the url, you'll find that it's not gone, it does still respond, it just responds with an error message. This tells me that someone is keeping the domain alive for whatever reason.
2) The archive links do seem to be a bit jittery, some work, some don't, sometimes they seem to work, then after a refresh they don't work, then they do work again. I remember from experience when wotsit was still online, they they had some very strange download/linking detection code in, and this probably caused archive.org to get some very wierd results, I do remember them taking this stance because of the huge number of 3rd party sites trying to cash in on their success, by pretending to be affiliate's and then direct linking to wotsit from an ad infested site.
Until the wotsit domain is removed entirely from the internet and not even the DNS responds, then would be the time to wrap everything up into single archive links, until then, this is the best way to maintain the link.
Not surprisingly the best sites for information about writing PE format files are all about creating viruses.
A search of VX Heavens for "PE" gives a whole bunch of tutorials for modifying PE files
Some information about making PE files as small as possible: Tiny PE.
The minimalistic way to mess around with code generation, if you're just looking to try a few simple things out, is to output MS-DOS .COM files, which have no header or metadata. Sadly, you'd be restricted to 16-bit code. This format is still somewhat popular for demos.
As for the instruction format, from what I recall the x86 instruction set is variable-length, including 1-byte instructions. RISC CPUs would probably have fixed-length instructions.
For Linux, one may read and run the examples from
"Programming from the Ground Up" by Jonathan Bartlett:
http://www.cs.princeton.edu/courses/archive/spr08/cos217/reading/ProgrammingGroundUp-1-0-lettersize.pdf
Then of course one may prefer to hack Windows programs. But perhaps the former
gives a better way to understand what really goes on.
Executable file format is dependent on the OS. For windows it is PE32(32 bit) or PE32+(64 bit).
The way the final executable look like depends on the ABI (application binary interface) of the OS. The ABI tells how the OS loader should load the exe and how it should relocate it, whether it is dll or plain executable etc..
Every object file(executable or dll or driver) contains a part called sections. This is where all of our code, data, jump tables etc.. are situated.
Now, to create an object file, which is what a compiler does, you should not just create the executable machine code, but also the headers, symbol table, relocation records, import/export tables etc..
The pure machine code generation part is completely dependent on how much optimized you want your code to be. But to actually run the code in the PC, you must have to create a file with all of the headers and related data(check MSDN for precise PE32+ format) and then put all of the executable machine code(which your compiler generated) into one of the sections(usually code resides in section called .text). If you have created the file conforming to the PE32+ format, then you have now successfully created an executable in windows.
I want to allow the displayed name of my application's shortcut in the start menu to appear in the user's local language, if we have a string available for it.
I have found a question that deals with how the localized strings are referenced in storage, but while I could just muck around editing the desktop.ini file directly, I would highly prefer a fully programmatic interface for solving this issue, i.e. an API similar to the IShellLink and related interfaces already used to set up shortcuts. IShellFolder::SetNameOf initially sounded like it would be able to deal with this, but on my second read of that page, it seems it will always rename the physical file.
My application already uses indirect strings for having file associations localised in the shell, this wasn't a major issue setting up since it is well enough documented, but I can't seem to find much documentation on display names of shell links.
I am using InnoSetup for my installer.
That's almost embarrassing, right after posting the question I did another search on MSDN, and found this:
SHSetLocalizedName Sets the localized name of a file in a Shell folder.
I am desperately attempting to guess how the localized filename for photos can be retrieved given the path to that file. For instance, given the path
c:\images\jellyfish.png - Win 7 explorer and the built in image viewer program both display the word "Méduses" for a french win 7. Does this hold true for other versions of windows ?
GetFileTitle only removes the extension and folder path giving me 'jellyfish' which is not what I am after, and after having read through MSDN and google it seems that the Windows Media Format's http://msdn.microsoft.com/en-us/library/dd798508(v=VS.85).aspx interface wouldn't help here. Either I have lost my googling skills or this is very poorly documented. Help please ?
thank you
I'm not sure about this case specifically (I've never encountered localized filenames in that form) but the only officially supported way I know of to get the localized filenames for system directories and the standard Windows applets, etc., is to use IShellFolder::GetDisplayNameOf.
So briefly, you need to get a PIDL for the file (SHParseDisplayName), bind to its parent folder (SHBindToParent), and then query for the display name using the SHGDN_INFOLDER flag.
Addendum: An even easier way (which I completely forgot about) is to use SHGetFileInfo to get the display name with the SHGFI_DISPLAYNAME flag. This means you don't need to muck around with PIDLs. SHGetFileInfo is essentially a wrapper around the various shell COM classes like IShellFolder - either way, the key is to use the shell to get the display name rather than the underlying API functions.
Goal
Let me start with my final vision of what I'd like to be able to do first: In Windows, I'd like to be able to use a global keyboard shortcut that I define (say, Ctrl+Alt+C) to copy the full path and filename of the open document in the foreground application to the clipboard.
This would be useful to, for example, be able to subsequently paste the path & filename into an "Open File" dialog in an email client to attach that document to an email, without having to manually browse to the target document in the filesystem.
Specific Question
Now, the specific part of how to do this that I'm interested in how to implement is: How can I get the path and filename of the current "open document" of any arbitrary currently-running Windows application. (If this can't be done with any Windows application, then the next best thing would be for this to work with as many applications as possible.)
Obviously, this wouldn't apply to some applications that don't necessarily have the concept of a "currently open document" that corresponds to a file on the local filesystem, such as an email client, an IM client, or (usually) a web browser.
Application-Specific Solutions
I'm aware that it's possible to write application-specific solutions to do this. For example, the following MS Word VBA subroutine will copy the filename and path of the open document in Word to the clipboard:
Dim myDataObject As DataObject
Set myDataObject = New DataObject
myDataObject.SetText ActiveDocument.FullName
myDataObject.PutInClipboard
However, what I really want is something that will work for any of the applications on my system (or, again, for as many of them as reasonably possible) without having to try and write an application-specific solution for each one.
Idea: Recent Documents Folder
One idea: Could the Recent Documents folder (and/or its underlying Windows APIs) somehow be leveraged to help with this? It seems to have information about the same concept of "open documents" that I'm interested in here, that apparently applies across various application types. (Looking at the contents of the Recent Documents folder on my machine, I see entries in there that were apparently made for documents that I opened with various applications including MS Word, MS Excel, Eclipse, Adobe Acrobat Reader, Paint.NET, TOAD, and Notepad2.)
Preferred Solution Language
I'd prefer solutions in C# or C++ code, but I'm open to any suggestions for how to go about doing this, regardless of implementation language!
Windows 7?
Update 11/2009: Now that Windows 7 is widely available, I figured it might be worth coming back to this question and asking: Does Windows 7 provide any new APIs, or any other mechanism, that would help with what I'm trying to accomplish here?
The best you could probably do is look at the recent documentation registry keys, and get the list of most recent documents. Some sample code for working with this data is in this CodeProject article. This is saved in:
HKCU\Software\Microsoft\Windows\CurrentVersion\Explorer\RecentDocs
However, this isn't going to show you whether a document is currently open or not. You could potentially check the title of all open applications, since many applications put document names in their window titles, but this is not a requirement, and many applications do not do that.
There is no mandatory mechanism for an application to specify its open document, so this is not generically possible.