In the program below, whare are WinTypes, WinProcs and what is the purpose of SW_NORMAL?
program ex;
uses Wincrt,WinTypes, WinProcs;
var
ch:string;
procedure exe (che:string);
begin
writeln('ecrire ch');
readln(che);
if ch ='oui' then
begin
WinExec('cmd /k "C:\TPW\exercice\project\site.html"', SW_NORMAL);
end;
end;
begin
exe(ch);
end.
The code is in Turbo Pascal 1.5.
Wintypes and winprocs are translated Windows 3.x headers that come with windows versions of Turbo Pascal and Delphi 1. In later Delphi versions these are aliased to the more "modern" (as in after 1995) win32 Windows unit.
SW_NORMAL is a parameter to winexec that has info about the window of the generate program.
You can look up Windows functions (even ancient ones like this) in MSDN, and this will give you a link for WinExec which links through to Showwindow for the various windows options and their explanation.
Your program is weird in the sense that it uses win 3.x apis to call a Windows NT+ "cmd.exe".
Related
I was trying to make my program accept input without the user having to press enter, so I tried the following:
mov ah,01h
int 21h
But it just crashes my program over an unhandled exception. This seems to be the way to do it according to much that I have read, so why isn't it working for me?
Now, I am fairly new to this language so I still do not exactly understand the process of how this piece of code works, so I would also appreciate what the logic is behind accepting input by pressing enter and accepting input without the user having to press enter.
MY OS is Windows, by the way.
Your code looks like MS-DOS-era assembly. VS2010 doesn't support generating DOS executables, and modern versions of Windows (the 64-bit kind) don't support running them, either. Looks like you were going by some old book or site, one that was written in late 80'es-early 90's. Back at that time, assembly was way more relevant and marketable as a job skill. Not so much these days, although some assembly knowledge won't hurt.
Decide what do you want to learn. If you want to learn modern assembly (and target Windows), get some recent guidance. The techniques are quite different, and int21h isn't among them :) If you're indeed after DOS-era assembly, set up a DOS virtual machine with DOSBox, and find some old free assembler. Visual Studio 2010 won't help you here. The latest version of Visual C++ that generated 16-bit executables was v1.5x.
Specifically why does your program crash. Int21h was how MS-DOS exposed its applciation program interface (API). Windows doesn't support it for Windows executables - there are other ways of invoking the API. When you assemble with Visual Studio 2010, you end up with a Windows executable, not a DOS one, and there's no option to generate a DOS one. As for the Windows executables, they're not supposed to invoke interrupts at all - that's a crash condition.
You need to obtain a tool set that can generate 16 MS-DOS programs. These should run on DOSBOX, or on a Virtual PC with MS-DOS installed on it. Microsoft included 16 bit tool sets up to Visual C / C++ 1.52, but Visual C / C++ 4.0 and 4.1 also contain the 1.52 16 bit tool set. The older version of the compilers would be named Microsoft C 8.xx or earlier version. I don't know if any the early versions of Visual Studio (2002 or 2003) include the 16 bit tool set.
Use the linker version 5.60 to generate 16-bit DOS applications. You can get this from:
http://download.microsoft.com/download/vc15/Update/1/WIN98/EN-US/Lnk563.exe
Dirk
I have a few things like running SFC, defrag, and reset the page file and so on, things that can be done within windows VBScript, I am just wondering if I can compile that code as a resource and call it as needed. Thanks.
Lee
You can use the Windows Script Host interfaces, IActiveScript and IActiveScriptParse, to execute Javascript/VBScript from memory. You can then compile your Javascript/VBScript into a resource, extract it at runtime, and then execute it when needed.
Update: have a look at this blog article:
Adding Active Scripting to your
Delphi Win32 application
And then look at this discussion to make it work in 64bit:
Writing a scripting host in Delphi XE2 64-bit
I have compiled a resource in a dll file in two steps
brcc32 Xresource.rc
dcc32 resource.dpr
resource.dpr is a delphi project containing
library resource;
{$R XResource.res}
begin
end.
The problem appears on some (not all) Chinese Windows (XP & 7). On these machines I can't read the strings from resource.
Any Ideea ? Should I compile it in a different way ?
Thank you.
With modern Unicode-ready versions you just keep strings into DFM.
you can also try using resourcestring keyword.
On Unix to Windows Porting Dictionary for HPC page for fork() it's written
There is no equivalent Windows API to
the Unix fork() or vfork(). The
Microsoft Subsystem for Unix-based
Applications (SUA or Interix) is a
Unix environment that has fork() and
vfork() properly implemented.
and further on the page there's example source code which uses... standard Win32 API CreateProcess function.
I'm confused.
Shouldn't the example use fork() to illustrate the statement about fork() being implemented by SUA/Interix?
If fork() is really implemented which header and lib files does it live in?
The page you're looking at is the *nix to Windows porting guide. It doesn't show you how to use fork() but the closest win32 equivialent, CreateProcess. The pages there documents which Win32 function you should use instead of Unix functions.
You'll need the subsystem for Unix and the SUA SDK to use fork(). There you'll get a *nix environment on Windows, fork() will be in the usual unistd.h library, and you'll link to libc.so (using gcc) to use it.
Can someone show me how to use "IShellExecuteHook.Execute" in Delphi please?
info: IShellExecuteHook::Execute Method
Description:
This method is called any time the ShellExecute or ShellExecuteEx functions are
called. This happens when a file is double-clicked in Explorer or when the Run dialog
box is used.
Thanks.
The following EDN link looks like it will give you what you need: How to hook ShellExecute calls (IShellExecuteHook)
Be aware that it won't work in 64 bit Windows because that requires 64 bit shell extensions and because Delphi only produces 32 bit images you would need to use a different language. I also note that IShellExecuteHook is deprecated as of Vista.