Resource scripts loaded from .rgs files are used with ATL CComModule::UpdateRegistryFromResource(). It's quite common to see samples of such files on the net but I've never seen a complete description on what constructs are allowed in .rgs files. Is there such a document?
There's some MSDN documentation, but it appears to be pretty unfocused.
The book ATL Internals talks at some length about custom replacements.
Other than that, I haven't seen much...
Related
I'm learning Go but I can't find this answer anywhere. Is there any official standard for file extensions in web development? I've seen multiple conventions like .tmpl and .gtpl, which is what? Thanks.
There's no fixed standard, but there are some fairly common practices. For templates on web projects, I use the extension appropriate for the type of file it is, e.g. .html, .css, etc. That's what's done in the widely-read-and-cited Writing Web Applications blog post on the official Go blog, which makes it fairly standard. I find it useful for easy syntax highlighting without changing my editor's settings/config, and processing by other tools. I put these templates in a /templates/ directory to keep them separate from non-template files.
I've seen and used .tmpl before, it's in official docs for both html and text template packages, which makes that fairly standard too, and I think it makes sense if you're making a file-type-agnostic template, or you don't have any associations that are useful by more specialized file type.
For Go code files, I always use the .go extension, which works well with the Go toolset. It's what you generally see in official Go documentation, such as this introductory document on How to Write Go Code. For executables, I don't append any file extension. The default result when you go build <name>.gois an executable called <name>, and so that makes it a common practice.
I've developed a plug-in using the ObjectARX SDK, C# and the Autodesk plug-in templates for VS2010. The plug-in is loaded into AutoCAD at start-up via a registry entry as documented in the SDK files.
The plug-in itself is to be distributed privately and will not be submitted to the 'Marketplace' supplied by Autodesk for AutoCAD products.
I've noticed that there is a section on the AutoDesk website with regards to registering a custom prefix via the RDS scheme.
Code that differs from the default template is found within the following areas:
Namespaces e.g. "MyNamespace.Utility"
Custom Classes MyClass.cs
Custom Functions e.g. LogData()
Custom Commands e.g. "DEBUGDATA"
Based on the current implementation and intended usage/distribution method is symbol registration required? I ask as I am not sure what would happen if another plug-in used by the user has a "DEBUGDATA" command for example.
If symbol registration is required where can I find a clear example of it's implementation within code?
Many thanks
The way I try to avoid command name duplication is to use a really long command name, including my top namespace ("CadBloke" in my case) and then add a command alias to the acad.pgp file so the keyboard command is more sensible. Buttons on a toolbar etc don't care how long a command name is.
In your code, namespace clashes can certainly be an issue. I tend to make my top-level namespace pretty wordy, something like "CadBloke.CadTools.ToolName". You'd have to be pretty unlucky, or have annoyed someone, to get a clash with that sort of thing.
I saw your question on the Autodesk forum - that answer is basically the same as mine: try to make your namespace unique.
Hazy memory: I think some of the project wizards from Autodesk add your symbol to the namespace.
Here's a blog post with a link or 2 on symbol registration: http://adndevblog.typepad.com/autocad/2012/05/registered-developer-symbols.html (your link is dead, pretty typical of Autodesk as they move links around a lot). Follow that up and try & find some info on symbols. Good luck with that, I never found anything concrete. Me, I don't use it presently.
Is there any documentation which describes all the valid elements for a Windows application manifest, which namespace they are in, and which Windows versions will use them? All the documentation I found so far describes only parts of the manifest, and I have seen different XML namespaces used for the same element.
What I have found so far:
Manifest Files Reference/Application Manifests seems to have full documentation of the urn:schemas-microsoft-com:asm.v1 namespace plus the compatibility/supportedOS stuff (from the urn:schemas-microsoft-com:compatibility.v1 namespace). It has a link to a schema file which does not have the compatibility/supportedOS stuff.
Step 6: Create and Embed an Application Manifest (UAC) documents the trustInfo/requestedExecutionLevel stuff as being in the urn:schemas-microsoft-com:asm.v2 namespace. However, I have seen other places saying it is in the urn:schemas-microsoft-com:asm.v3 namespace.
SetProcessDPIAware Function documents an application/windowsSettings/dpiAware thing as using both the urn:schemas-microsoft-com:asm.v3 namespace and a http://schemas.microsoft.com/SMI/2005/WindowsSettings namespace.
Application Manifest XML Schemas looks like a set of schema files for some of these namespaces, but it seems to contradict the other references (for instance, unless I am misreading the xsd, dependency is in the urn:schemas-microsoft-com:asm.v2 namespace, while the first reference above implies it is in the urn:schemas-microsoft-com:asm.v1 namespace).
There's no such thing. In fact I'd bet that there are still some completely undocumented parts of the manifest. Indeed, for a long time the only documentation of the DPI aware part was in Raymond Chen's blog and book!
I hope this is a valid question: how does intellisense work in VS2008? I'm after what is known about the algorithm it uses to find the suggestions, when exactly it pops up (the "." is just one obvious trigger), how its behavior can be modified if at all possible, etc.
To put this question into context: The main issue I'm trying to resolve is how to activate and deactivate intellisense in portions of the editor screen and how to modify where it searches to populate the suggestion box.
All information is welcome.
Take a look at this DIY Intellisense article on CodeProject.
It's more fun to reverse-engineer it, though. Let's consider the problem:
you need to identify the words of interest
you need to find the options possible
you need to present them
Now, the first step means you have to parse the code. You've got the C/C** keywords, you pre-parse the various function and class declarations, and load them into some kind of data structure. Then you parse the code and store the class, variable, etc names and put them in the same data structure.
The second step means you want a data structure which efficiently can search for a partial word and get all the words that have that prefix. You can do that with regular expressions, but that's not very efficient. An efficient data structure for that kind of search is a trie, which is discussed here on SO .
Once you have the list of possibilities, you just present it. You probably want to keep a reference to the root of the tree of possibilities so you can search them out in real time as someone types more letters.
Eclipse also has this feature and it is an open source project. Why not check out how Eclipse does it by actually looking at the code?
This question is too broad. Since there are a number of different languages the VS IDE supports out of the box AND there are N number of DSL and IDE enhancements that support alternative intellisense this implies a number of answers. If you are speaking about C# specifically then See the Tools | Options | Text Editor | C# | Intellisense area to see the available options of completion options. As far as the algorithm[s] used, you would be looking for the metadata of assemblies, copious caching of type members, MRU list for last member chosen for specific type, etc. If you have a more specific question, I'd suggest you clarify.
See the example of a DSL (ironpython) and its implementation here.
I haven't seen any text editor in VS that limits where IntelliSense shows up. It's all language specific. If your cursor is located at a point where IntelliSense might contribute to a valid token, that's when it will be used.
I believe there is some interaction with the project system being used, but that's as far as I know. I also believe there is a sample project system in the Visual Studio SDK, and that might give you an idea.
For such cases I sometimes use my own version of InteliSense that I developed for AutoHotKey when I want specific behavior. The point of this script is that it can be used with any editor, or basically any control accepting text. It works by recording text input and interpreting it upon syntax file.
You can perhaps use it as a base for the thing you want to achieve. I used ISense succesifully with several languages that don't have such thing, like Csound or even batch scripts. It will be possible to extend it to support C# using input monitoring in combination with Reflection.
Anyway, with AHK you can even control VS intelissense by "taking" the list of items it presents and filter it, or similar things. You may have some small problems with process boundaries but nothing that cant be fixed.
The intellisense ius generally, AFAIK, implemented using different methods. I read that Delphi is so fast that it implements isense by recompiling the project on each token and thats the reason C++ Builder didn't have isense as its compiling very slow.
As to your how to change where it looks question, short answer is, you can't. Intellisense for the most part is provided by reflection of assemblies included in your project ( and some other tricks with C++ ). What you are getting is a result of VS processing through all the assemblies you have included and all assemblies from the GAC.
That said, if you want to provide explicit intellisense results from a project you are working on, look into IVsContextualIntellisenseFilterProvider
Finally, for some insight into the behind the scenes process, check this blog post
Whats the easiest way to find out what programming language an application was written in?
I would like to know if its vb or c++ or delphi or .net etc from the program exe file.
Try PEiD
of course if they used a packer, some unpacking will need to be done first :)
Start it up and check what run-time DLLs it uses with Process Explorer.
If that doesn't make it immediately obvious, search the web for references to those DLLs.
Most disassemblers (including Olly I think) can easily show you the text contained in an EXE or DLL, and that can also sometimes give a clue. Delphi types are often prefixed with T as in TMyClass.
If it's a small executable with no DLL references and no text you might be SOL. At that point you'd need to look for idioms of particular compilers, and it would be mostly guesswork.
There is an art to detecting what language a program was written in. It is possible but there are no hard and fast rules. It takes a lot of experience (and it also leads to the question "Why would you want to..." but here are a few ideas on how to go about it.
What you're looking for is a "signature". The signature could be a certain string that is included by the compiler, a reference to an API that is quite common in the programming tool being used, or even a style of programing that is common to the tools being used, visible in the strings contained in the application.
In addition, there are styles to how an application is deployed: various configuration files found in the deployment directory, dlls and assemblies and even images, directories or icons.
Java applications wrapped in a self-launching executable will contain references to java libs, and will likely have certain libraries or files included in the same directory that indicate that it's java.
As indicated in other answers a managed assembly will show certain signs as well: you can open it in Reflector etc. While it is correct that c# and VB are "interchangable" once compiled, it is not true that they are identical. If you use Reflector to disassemble VB code you will quite often see that the assembly references the Microsoft.VisualBasic.dll assembly. You'll be able to tell the difference between Mono applications because they will most likely contain references to the mono assemblies.
Many compilers assemble and link code in certain ways, and leave footprints behind. For example, examining a window executable using "strings: tab in Process Explorer, you'll see a lot of strings. Using these you may be able to determine programming styles, methods called, error or trace methods withint the exe.
An example is that compilers use different mechanisms for localization: Microsoft stores localized strings in XML files or resource files. Other compilers will use a different tactic.
Another example is c++ name mangling. The CodeWarrior compiler uses a different algorithm to mangle the names of the member variables and functions of a call than Visual Studio.
I suppose you could write a book on the subject of accurately determining the lineage of any executable. This subject would probably be called "programming archeology".
You could try using Depends to see what runtime dependancies it has, which might give some clues.
The easiest way is to ask the developer of the program. It does not require any knowledge and utility programs.
Determine Delphi Application
Use eda_preview270.exe (from here) or some other spy tool and check the window class names. If they read like TButton or TfrmBlubb, it's a VCL app. If there is an "Afx" in them, it's probably MFC.
Compiled languages (by this I mean no scripting languages, or Java, .NET, etc.) are compiled into CPU assembly instructions, which is essentially a one-way conversion. It is not usually possible to determine which language a program was written in. However, using a dependency walker, you could potentially determine which runtime library the program was loading (if any) and therefore determine which language it used (e.g. MS Visual C++ 9 uses msvcr90.dll).
you can check is that a .net assembly or not by trying to open with ildasm.exe tool
PE Detective works best for me.
In general, you can't.
If you can load it into Reflector, you know it is a managed assembly.
That's a good question. There isn't any general way to tell, but I bet most compilers and libraries leave a mark in the resulting EXE file. If you wanted to spend a lot of time on it, you could gather a bunch of EXEs written in known languages and scan for common strings. I would image you'd find some.
Dependancy Walker, which someone else mentioned would be a good way to look for telltale dependencies, like versions of MSVCRT, etc
i'd try running the .exe thru a 'strings' program to get assorted hints.
If I remember correctly PE Explorer Disassembler gives some information about compiler that creates given not .net and java binary, for .net use Reflector or ILDAsm tool
The easiest way that I found (at least in computer games) was to look in the "redist" folder nested within the game's main folder. It might be obvious to some of you that are more experienced in programming yourself, but the specific purpose of the MSI in this folder is to allow the setup.exe file to automatically install the prerequisites for the game itself.
For example:
In Empire Total War, there is an MSI called "vcredist_x86-sp1.exe". This indicates that the game/program was written in Microsoft's "Visual C 2005" in the .NET Framework (usually).
In fact, if you open the MSI/EXE, the installer should immediately indicate the language it's written in and which version.
The reason I'm familiar is because I code in C# and VB in the .NET Framework and we auto-install the prerequisites for our business app.
Hope this helps!