SHA 256 With Indy - indy

I am trying to use the SHA-256 encryption function, but with no success.
I need to get a hash of a string and a file.
I'm using Delphi 10.1 Berlin, and Indy for Hash.
My code:
uses System.Classes, IdHashSha, System.SysUtils;
function GetHashF(_filename: string): string;
var
sha: TIdHashSHA256;
fs: TFileStream;
begin
if TIdHashSHA256.IsAvailable then
begin
sha:= TIdHashSHA256.Create;
try
fs:= TFileStream.Create(_filename, fmOpenRead);
try
Result:= sha.HashStreamAsHex(fs);
finally
sha.Free;
end;
finally
fs.Free;
end;
end;
function GetHashS(_string: string): string;
var
sha: TIdHashSHA256;
begin
if TIdHashSHA256.IsAvailable then
begin
sha:= TIdHashSHA256.Create;
try
Result:= sha.HashStringAsHex(_string);
finally
sha.Free;
end;
end;
end;
But whenever I do this, it returns a clean string ("") for both function.
I used the breakpoint to check if it is passing from IsAvaible, and it is not.
What is going on?

At this time, Indy only implements a few hashing algorithms natively, but that does not include SHA-256 (I have created a ticket for that feature).
For algorithms not implemented natively, Indy allows you to hook in an external hashing implementation of your choosing to provide the actual hash functionality. You are seeing IsAvailable return false because you have not done that hookup yet.
You can use any hash implementation you want, as long as you assign appropriate wrapper functions to the following callbacks in the IdFIPS unit:
IsHashingIntfAvail
UpdateHashInst
FinalHashInst
And for SHA-256 specifically, also:
GetSHA256HashInst
IsSHA256HashIntfAvail
By default, Indy can use OpenSSL as a hashing library:
add the IdSSLOpenSSLHeaders unit to your uses clause
call IdSSLOpenSSLHeaders.Load() at runtime
deploy the OpenSSL binaries with your app executable.
IdSSLOpenSSLHeaders.pas hooks up relevant OpenSSL functions for the IdFIPS callbacks.

Related

How do I run an external application with Free Pascal/Lazarus?

How do I run an external application with Free Pascal/Lazarus (using Windows)? I found the "official" reference page, with several implementations and examples. Although I'm sure it works for many people, I, with my current knowledge level, am some what lost (I don't have much routine programming with Free Pascal yet, and other examples I found on the web didn't work for me).
Is there a "clear" example that helps me to do the "first steps"? Thanks.
If you don't need piping you can just use execute process.
uses sysutils;
begin
executeprocess('notepad.exe',['document.txt']);
end.
Here's a working example (source) using TProcess:
uses Process;
var
RunProgram: TProcess;
begin
RunProgram := TProcess.Create(nil);
RunProgram.CommandLine := ‘Path and Name of Program’;
RunProgram.Execute;
RunProgram.Free;
end;
For example, this will open the application "MS Notepad":
uses Process;
var
RunProgram: TProcess;
begin
RunProgram := TProcess.Create(nil);
RunProgram.CommandLine := ‘notepad.exe’;
RunProgram.Execute;
RunProgram.Free;
end;

Open file in OS X

In Delphi, I would like to open a file in OS X. My approach is as follows:
const
Filename = 'test.bmp';
procedure SaveAndOpen;
begin
Chart.SaveToBitmapFile(Filename);
{$IFDEF MSWINDOWS}
ShellExecute(0, 'open', Filename, '', '', SW_Normal);
{$ELSE}
_System(Filename);
{$ENDIF}
end;
But nothing happens. What am I doing wrong?
This article from Embarcadero's Malcolm Groves covers this topic: Opening files and URLs in default applications in OS X.
In summary, all you need is this:
uses
Macapi.Appkit, // for NSWorkspace
Macapi.Foundation; // for NSSTR
....
var
Workspace: NSWorkspace; // interface, no need for explicit destruction
....
Workspace := TNSWorkspace.Create;
Workspace.openFile(NSSTR(FileName));
For sake of completeness, should you wish to open a URL rather than a file, then you call openURL instead:
Workspace.openURL(NSSTR(URL));
Regarding your Windows code, I would recommend not using ShellExecute. That function does not have reasonable error reporting. Use ShellExecuteEx in its place.
And finally, you should probably abstract this functionality away so that it can be re-used by other parts of your program. You want to write that IFDEF as few times as possible.
You must add the open verb like so
_System(PAnsiChar('open ' + Filename));

how to internationalize a delphi application [duplicate]

This question already has answers here:
Closed 10 years ago.
Possible Duplicate:
Translate application
What is the best way to internationalize my application written in delphi xe2 ?
I've seen the stringtable resource but I'm worried because I've got the feeling that the implementation could be time consuming and laborious.
Are there other equally valid methods to do this?
Maybe not the best tool for translations, but I'm using GNU Gettext for many years.
The process is quite simple:
You run dxgettext to extract strings
You translate or give for translation the files
I personally love poEdit tool to translate and manage translation repository
Optional : You merge your translation files into the final EXE
OR you put the translation files in subdirectories and that's it !
http://dxgettext.po.dk/
Update:
1/ GNU Gettext is included in JCL/JVCL library, you just need to activate this option at startup.
2/ Gnu Gettext can translate everything in the library, as VCL, JCL/JVCL also ! It's not just limited to your code !
One option is to use the Integrated Translation Environment in Delphi:
http://docwiki.embarcadero.com/RADStudio/XE3/en/Localizing_Applications_by_Using_Translation_Manager_Overview
Here you can find two articles about this theme:
Multilingua application with GNU gettext
Multilingua application with standard method (IDE)
You can find other methods and commencial components (i have used TsiLang components -excellent library-)
A Greeting.
I don't know is this the best way of internationalize an application, but for me it worked. It's a kind of home made.
I created an xml file, which is the dictionary containing the translations, but you can use any other format, from json, to xls (maybe this is the best). Than implemented a class which read the translations from this file, and a way to register procedures in case of the language is changed runtime, which is I think a good feature.
TDictionary = class
private
fOnChanged: TSignal;
fLanguage: String;
procedure setLanguage( const Value: String );
public
procedure loadFromFile( filename: string );
function getTranslation( id: string; lang: string = '' ): string;
property language: String read fLanguage write setLanguage;
property onChanged: TSignal read fonChanged;
end;
...
function TDictionary.getTranslation( id: string; lang: string = '' ): string;
begin
if lang = '' then
lang := Language; // use the default lang.
// read the translation from the file.
end;
procedure TDictionary.setLanguage( const Value: String );
begin
fLanguage := Value;
onChanged.Execute;
end;
TSignal is a class which register methods, and if you call Execute executes all the registered methods, Maybe in xe2 you have something built in for this, in delphi7 I had to create this class myself, but it's fun to implement.
in a form's createForm:
procedure TMyClass.doTranslate( dictionary: TObject );
begin
with dictionary as TDictionary do
begin
caption := dictionary.getTranslation( 'myclass.caption' );
button.caption := dictionary.getTranslation( 'some id' );
end;
// or you can go through Controls array, and automate the assignment.
end;
procedure TMyClass.FormCreate(Sender: TObject);
begin
Dictionary.onChanged.register( doTranslate );
doTranslate( dictionary );
end;
procedure TMyClass.FormDestroy(Sender: TObject);
begin
Dictionary.onChanged.deregister( doTranslate );
end;
As you can see, this is not a working example what you can copy and paste, I just wanted to show you the idea behind. if something is not clear, comment it, and I can extend my answer.
Some notes:
I think it's important to have the translations in utf8 format.
using xls makes the localizers live easier, and your too, if they ruin your xml file (If the translator is not prof., It can happen that you get back your xml file in microsoft word format)
you can put your dictionary file into resource, and load from there.
Pros
This way you can change the language runtime
if you need another language, you just need to edit the dictionary file.
Cons
If you have many forms, it's a nightmare to connect all the labels, buttons, etc, but you can automate it in smart ways.
It slows down your app a little, but not much, if changing your app language is not happening so often.
There is a product called sisulizer, it works after you have build the executable fies I think. Haven't tried it but I've read a lot about it.
Have a look at this

How to get the sort order in Delphi as in Windows Explorer?

Summarization:
The terminology that I have been
looking for seems to be "natural
sort".
For behaviors in operating systems:
For Windows (version >= XP), Windows Explorer utilizes natural
sort.
For Linux terminals: use "ls -v" instead of plain "ls" to get natural
sort.
For programing in Delphi, use StrCmpLogicalW Windows API to get natural sort.
For programing in Delphi & Kylix & Lazarus, use hand-crafted functions to get
natural sort:
(1) Delphi wrapper for Natural Order String Comparison by Martin Pool.
http://irsoft.de/web/strnatcmp-and-natsort-for-delphi
(2) Codes of alphanum sorting algorithm in other languages from davekeolle site.
http://www.davekoelle.com/alphanum.html
(3) Other knowledgable pages:
http://www.codinghorror.com/blog/2007/12/sorting-for-humans-natural-sort-order.html
http://objectmix.com/delphi/722211-natural-sorting-optimizing-working-solution.html
http://groups.google.com/group/borland.public.delphi.language.delphi.general/browse_thread/thread/1141d49f8bbba577
http://objectmix.com/delphi/401713-alphanumeric-sort-routine-delphi.html
==========================
The following file names will be ordered in the Windows Explorer as shown below:
test_1_test.txt
test_2_test.txt
test_11_test.txt
test_12_test.txt
test_21_test.txt
test_22_test.txt
If, for example, I put them in a TStringList instance and call Sort, the sorted order is as below:
test_1_test.txt
test_11_test.txt
test_12_test.txt
test_2_test.txt
test_21_test.txt
test_22_test.txt
And for record, the above file names will be ordered in the rxvt terminal of Cygwin or xterm terminal of Linux distributions such as CentOS as shown below:
test_11_test.txt
test_12_test.txt
test_1_test.txt
test_21_test.txt
test_22_test.txt
test_2_test.txt
Could you help to comment on how to understand this difference of sorting behaviors? Furthermore, is it possible to get the same order as in Windows Explorer? Any suggestion is appreciated!
PS: My Windows locale is set to Chinese but I would think the same for English locale.
StrCmpLogicalW is able to handle numbers, the other alternative is CompareString
Thanks to Anders - the answer is StrCmpLogicalW; I have not found it's declaration in Delphi 2009 sources, so I declared it myself in the test below:
type
TMyStringList = class(TStringList)
protected
function CompareStrings(const S1, S2: string): Integer; override;
end;
function StrCmpLogicalW(P1, P2: PWideChar): Integer; stdcall; external 'Shlwapi.dll';
function TMyStringList.CompareStrings(const S1, S2: string): Integer;
begin
Result:= StrCmpLogicalW(PChar(S1), PChar(S2));
end;
procedure TForm11.Button2Click(Sender: TObject);
var
SL: TMyStringList;
begin
SL:= TMyStringList.Create;
try
SL.Add('test_1_test.txt');
SL.Add('test_11_test.txt');
SL.Add('test_12_test.txt');
SL.Add('test_2_test.txt');
SL.Add('test_21_test.txt');
SL.Add('test_22_test.txt');
SL.Sort;
Memo1.Lines:= SL;
finally
SL.Free;
end;
end;

Do Windows shortcuts support very long argument lengths?

I am trying to create a shortcut (on the Desktop) that contains a long argument string (> MAX_PATH).
The MSDN documentation clearly states that for Unicode string the string can be longer than MAX_PATH.
The resulting shortcut is cut exactly after MAX_PATH characters (that is the Path + the Arguments).
Is there something wrong with my implementation or is this some Windows limitation?
procedure CreateShortcut(APath: WideString;
AWorkingDirectory: WideString; AArguments: WideString; ADescription: WideString;
ALinkFileName: WideString);
var
IObject : IUnknown;
ISLink : IShellLinkW;
IPFile : IPersistFile;
begin
IObject := CreateComObject(CLSID_ShellLink);
ISLink := IObject as IShellLinkW;
ISLink.SetPath( PWideChar(APath));
ISLink.SetWorkingDirectory(PWideChar(AWorkingDirectory));
ISLink.SetArguments( PWideChar(AArguments));
ISLink.SetDescription( PWideChar(ADescription));
IPFile := IObject as IPersistFile;
IPFile.Save(PWideChar(ALinkFileName), False);
end;
PS: OS is Windows XP (and above).
It turns out that this issue is in fact solely a limitation in the Explorer shell dialog. The generated shortcut file does not have a 260 character limitation. It's simply that the dialog refuse to display a Target with more characters than that. Presumably it calls GetPath with a fixed length buffer.
procedure TForm11.Button1Click(Sender: TObject);
var
sl: IShellLinkW;
pf: IPersistFile;
begin
CoCreateInstance(CLSID_ShellLink, nil,
CLSCTX_INPROC_SERVER, IID_IShellLinkW, sl);
sl.SetPath('c:\desktop\test.bat');
sl.SetWorkingDirectory('c:\desktop\');
sl.SetArguments(PChar(StringOfChar('x', 300)+'_the_end'));
pf := sl as IPersistFile;
pf.Save('c:\desktop\test.lnk', False);
end;
My test.bat looks like this:
echo %1> test.out
The resulting test.out goes right the way to _the_end!
Thanks all who contributed to this thread - it helped me immensely.
However, if I may, I would like to add the below information I discovered in crafting my solution:
On Windows 7 Enterprise ~SP1, it would seem that using VBS to create the shortcut there is still a limit on maximum characters in (at least) the arguments field. I tested up to 1023 chars before it got trunicated. I presume the same limit would apply to the Delphi method likewise.
On Windows XP Professional ~SP3, while the VBS method will create a shortcut longer than 260 characters (lnk file contains the data), it seems to trunicate it at about this number when executing it.

Resources