Command line has a string limitation as mentioned on msdn and here.
I tried the workaround suggested on msdn, writing the arguments to a file. But, I am unable to pass the arguments from a file.
Edit :
I need to run the bcp utility, in order to export (huge) data to flat files.
The executable you're running has to support this explicitly. For example, the C# compiler allows you to write
csc #foo
to load some options from a file called foo. I don't believe this can easily be "fixed" without support from the command you're running though... it's possible that you could write a small wrapper program which loaded the file and started the process itself. However, you'd have to be careful in terms of security handles, propagating console input and output etc. If you're in control of the application in question, you'd be much better off putting support in directly.
Related
I'm working on a plugin for a very niche CAD application that our company uses. The development environment is entirely based on Emacs and everything should be done through it.
In this case, code should be edited, navigated, compiled and debugged using Emacs. There is no separation from Emacs and the actual language compiler (from what we know so far - there is no compiler.exe).
Since my team is not a fan of Emacs we are trying to get rid of this dependency so we can use whatever editor we want an compile/interact with the application without Emacs, but looks like this is very hard because everything is built inside it, even go-to definition, find all references all and sorts of commands.
These are all defined in hundreds of .el files (LISP) that are called using custom commands from Emacs.
However, when calling "Run this file" for example, said file is ran inside the application and correctly executed so my question is: what mechanisms could be used used for this to happen? I don't expect precise answers as I can't share the name of the actual CAD application or anything else, but it would be really helpful to understand what options are possible so I can investigate them.
In summary, whenever I "Run this file" the actual application is started by Emacs by calling the command line and the actual file gets executed inside the application. Looks like the contents of the Emacs buffer are passed to the application somehow. This "how" is what I'm trying to find.
Thanks for any help.
When we build a project, we can define that under which subsystem we want to run our program in windows. But how it would affect the output exe file. Or in other words when we call a CreateProcess() API we just pass it an exe file, So which header inside the exe file, it
checks to determine that which subsystem going to handle this process? Or it uses some other method in order to accomplish it?
i guess, i will look into EXE header
Look
http://www.delorie.com/djgpp/doc/exe/
http://www.fileformat.info/format/exe/corion-mz.htm
Tools update:
I like:
http://www.heaventools.com/PE-file-header_viewer.htm
http://www.mitec.cz/exe.html
You Can:
http://blogs.msdn.com/b/securitytools/archive/2010/01/28/how-to-view-the-header-of-an-exe-dll.aspx
online :http://exe.urih.com/
In the primary header of executable, that information is present. As you are talking about .exe(or rather binary), linker stage is performed. Linker is part of OS, and every OS has a code number through which it is recognized as its binary.
As in case of windows and CreateProcess(), consider reading this
I am working on an Automation project which i coded fully in TCL. A part of the project demands to read a Microsoft Word Document and modify a line in that Word Document using TCL Script. I tried with tcom packages but i faced problem while making changes to that document since the word document gets corrupt. So guys if anybody can help me i will be very thankful.
Note : The script can also be in Shell. In that case i will invoke the shell script from my tcl script.
Thanks
tcom is a windows only extension to allow Tcl to interact with COM objects. To automate Microsoft Word using tcom you are actually running the Word executable so this can only be done on Windows.
To do this on unix, you will need to find some unix application that can modify Word documents for you. Tcl will not have any unix extensions that can do this and the file format you have to operate on will depend on the version of Word used. If the file is a docx file then that is actually a zip format file with XML documents in it. You can use the zipvfs subcomponent of the tclvfs extension to mount the zip document and then you could use tdom (tcl XML document object model extension) to examine and modify the XML stream in place. For previous versions of word that used structured storage documents you face an uphill struggle to handle the format on non-windows systems.
Manipulating MS Office documents on Unix is a bit of a pain, and there are no Tcl packages for doing so (as far as I know). Your best bet might be to use something like Apache POI for the integration work, and driving that Java library either as an external process (i.e., write a small Java app that integrates) or by running your Tcl inside a JTcl interpreter within the Java process.
I work on software that requires access to DLLs, usually wants environment variables set a certain way, and can take command line parameters. I'm generally opposed to setting/modifying system-wide environment variables for the purpose of launching these apps, since I might want to use different dependencies (different dlls), etc. and I don't want to accidentally get the wrong DLL loaded.
Up until now, I've been generating the visual studio .vcproj.user files and matching batch files from cmake ( see here for my script ) that extends the path to include the path to my dlls, sets any other environment variables as needed, and launches the application, forwarding all the command line arguments. (I do the same on Linux, but it's simpler because of RPATH). When we want to launch with a command line argument that wasn't just a file we could drop on the batch file, what we did is copy the batch file and edit the command to add our argument. (It's all GUI applications, but config files/flags can be passed on the command line)
This has become quite a hassle for me and my colleagues, and we end up with a ton of batch files, named similarly and difficult to maintain. It's not really a great interface for starting but there's a lot of apps we either use or develop that are like this, so it's a common task.
My question is this: I'd like a nicer way to configure dynamic library search paths, process-local environment variables, working directory, executable, and arguments for starting a program than hand-editing a batch file every time. I've done some digging to try to find one, but haven't been successful - "launcher" tends to bring me to "search-as-you-type" tools for frequently-used apps, and "command line argument" tends to find recommendations to use batch files. (It's not a windows-specific issue, either, but the dynamic library path stuff is less problematic during the code/compile/run cycle)
I've made a quick mockup of what I'm envisioning: it seems like the kind of thing that has to exist somewhere. Do you know of a tool similar to this (preferably cross-platform, and open source is even better)? It doesn't need all bells and whistles I put in the mockup, but that's what I'd build if I had time to build it myself. Thanks!
My windows co-workers were asking me if I could modify my non-windows binary files such that when their "Properties" are examined under Windows, they could see a "Version" tab like that which would show for a Visual Studio compiled exe.
Specifically, I have some gzipped binary files and was wondering if I could modify them to satisfy this demand. If there's a better way, that would be fine, too.
Is there a way I could make my binaries appear to be exe files?
I tried simply appending the VS_VERSION_INFO block from notepad.exe to the end of one of my binaries in the hope that Windows scans for the block, but it didn't work.
I tried editing the other information regarding Author, Subject, Revision, etc. That doesn't modify the file, it just creates another data fork(what's the windows term?) for the file in NTFS.
It is not supported by windows, since each file type has their own file format. But that doesn't mean you can't accomplish it. The resources stored inside dlls and exes are part of the file format.
Display to the user:
If you wanted this information to be displayed to the user, this would probably be best accomplished with using a property page shell extension. You would create a similar looking page, but it wouldn't be using the exact same page. There is a really good multi part tutorial on shell extensions, including property pages starting with that link.
Where to actually store the resource:
Instead of appending a block to the file, you could store the resource into a separate alternate data stream on the same file. This would leave the original file stream non corrupted on disk and not cause its primary file size to change.
Alternate data streams allow more than one data stream to be associated with a filename. Each stream is identified by a colon : at the end of the filename and an identifier.
You can create them for example by doing:
notepad test.txt:adsname1
notepad test.txt:adsname2
notepad test.txt
Getting the normal Win32 APIs working:
If you wanted the normal API to work, you'd have to intercept the Win32 APIs: LoadLibraryEx, FindResource, LoadResource and LockResource. This is probably not worth the trouble though since you are already creating your own property page.
Can't think of any way to do this short of a shell extension. The approach I've taken in the past is a separate "census" program that knows how to read version information from any kind of file.
Zip files can be converted into exe files by using a program that turns a zip file into a self-extracting zip (I know that WinZip does this, there are most likely free utilities for this also; here's one that came up on a search but I haven't actually tried it). Once you've got an exe, you should be able to use a tool like Resource Hacker to change the version information.
It won't work. Either Windows would have to know every file format or no file format would be disturbed if version information were appended to it.
No, resource section is only expected inside PE (portable executable; exe, dll, sys).
It is more then just putting the data inside the file, you have a table that points to the data in the file header.
What you can do if you have NTFS drive, is to use NTFS stream to store custom properties this way the contact of the binary file will remain the same, but you will need to use a custom shell extension to show the content of the stream.