I added a few new functions to files.lib that I needed for a project. They are...

IsShortcut

Tests to see if the filename provided is a shortcut.
Parameters:
lpFilename = Pointer to a filename to be examined
Returns TRUE if the filename is a shortcut

ResolveLinkIndirect
Resolves a shortcut returning details about that shortcut. The information is passed
in a structure
Parameters:
pLinkInfo = Pointer to a LINK_INFO structure

LINK_INFO structure members:
pFilename Fully qualified path of the LNK file to be examined, cannot be NULL
pLinkTarget Pointer to a buffer of MAX_PATH to recieve the target, can be NULL
pIconLocation Pointer to a buffer of MAX_PATH to recieve the icon location, can be NULL
dwIconIndex Recieves the icon index (ignored if pIconLocation is NULL)
pDescBuffer Pointer to a buffer to recieve the description, can be NULL
cchDesc Size in bytes of the pDescBuffer buffer
pArgBuffer Pointer to a buffer to recieve the command line arguments, can be NULL
cchArg Size in bytes of the pArgBuffer buffer
pStartIn Pointer to a buffer of MAX_PATH to recieve the startup dir, can be NULL
dwHotkey Recieves the assigned hot-key scan code
dwShowCmd Recieves the show command

Set a buffer pointer to NULL if you do not need that information.
Returns S_OK or an OLE defined error code.

CreateLinkIndirect
Creates a shortcut, based on the information passed in a structure
Parameters:
pLinkInfo = Pointer to a LINK_INFO structure

LINK_INFO structure members:
pFilename Fully qualified path of the LNK file to be created, cannot be NULL
pLinkTarget Pointer to a path specifying the target, cannot be NULL
pIconLocation Pointer to a path where the icon is located, can be NULL
dwIconIndex Specifies the icon index (ignored if pIconLocation is NULL)
pDescBuffer Pointer a description, can be NULL
cchDesc ignored
pArgBuffer Pointer to a string of command line arguments, can be NULL
cchArg ignored
pStartIn Pointer to a path specifying the startup dir, can be NULL
dwHotkey Hot-key scan code (ie VK_S)
dwShowCmd Show command (ie SW_SHOWNORMAL)

Set a buffer pointer to NULL to skip that information
Returns S_OK or an OLE defined error code.

StripFilename
Returns the path portion of a file name in the buffer provided. The buffer must
be of the size MAX_PATH
Parameters:
pszBuffer = Pointer to a buffer in which to copy the path information
pszFilename = Pointer to a file path (this string is preserved)

Returns the offset of the file name portion of the path
ECX is preserved for loop functions


The lib with GoAsm source is available at my website. These functions have not been tested using MASM but should work fine with that assembler. Example of CreateShortcutIndirect...

FILESLIB = C:\GoAsm\Files.lib

CreateLinkIndirect = FILESLIB:CreateLinkIndirect

DATA SECTION
lnkfile DB "C:\TestLink.LNK",0
lnktarget DB "C:\RadASM\RadASM.EXE",0
lnkDesc DB "Description",0
lnkStrt DB "C:\RadASM",0
lnkIcoLoc DB "C:\WinNT\system32\SHELL32.dll",0
lnkArgs DB "/s",0

li LINK_INFO <>

CODE SECTION
invoke CoInitialize,0
mov [li.pFilename],offset lnkfile
mov [li.pLinkTarget],offset lnktarget
mov [li.pIconLocation],offset lnkIcoLoc
mov D[li.dwIconIndex],10
mov [li.pDescBuffer],offset lnkDesc
mov [li.pArgBuffer],offset lnkArgs
mov [li.pStartIn],offset lnkStrt
mov D[li.dwHotkey],VK_S
mov D[li.dwShowCmd],SW_SHOWMINIMIZED
invoke CreateLinkIndirect,offset li
Posted on 2004-12-26 14:35:21 by donkey
Thanks, man! I've been just implementing the shortcut stuff in one program through the old COM way. Thanks again!


P.S: Do you really have to pass pIconLocation or if NULL will the function automatically find the first icon in the file or the associated icon for this type and set it in the struct?



/siddhartha
Posted on 2004-12-26 22:43:33 by siddhartha
Hi,

If you pass NULL for pIconLocation then the first icon in the target file is assigned to the shortcut. BTW the lib does use COM to handle the shortcuts but with them you don't have to deal with it except to make sure that at some point before calling them you have to have made a call to CoInitialize in order to "turn on COM". If you're using them in MASM I would appreciate knowing if they work OK.

BTW, the LINK_INFO structure is defined in the link.inc file but here it is if you don't want to search for it:

LINK_INFO Struct

pFilename DD ?
pLinkTarget DD ?
pIconLocation DD ?
dwIconIndex DD ?
pDescBuffer DD ?
cchDesc DD ?
pArgBuffer DD ?
cchArg DD ?
pStartIn DD ?
dwHotkey DD ?
dwShowCmd DD ?
LINK_INFO ENDS
Posted on 2004-12-26 22:52:09 by donkey
OK. I'll give it a try after breakfast. Now I'm going to eat eat eat :)




/siddhartha
Posted on 2004-12-26 23:03:13 by siddhartha
For now it's working like a charm. I've got just to write masm-compatible inc's for this cute lib :)



/siddhartha
Posted on 2004-12-27 00:59:02 by siddhartha
This should cover all the PROTOs you need for MASM...

CheckFileName			PROTO	:DWORD,:DWORD

CountFileLines PROTO :DWORD
CountFileLinesMMX PROTO :DWORD
CRC32 PROTO :DWORD,:DWORD
InitCRC32Table PROTO
CreateDesktopLink PROTO :DWORD,:DWORD,:DWORD
CreateLink PROTO :DWORD,:DWORD,:DWORD
CreateLinkIndirect PROTO :DWORD
CreateSpecialFolderLink PROTO :DWORD,:DWORD,:DWORD,:DWORD
CreateStartmenuLink PROTO :DWORD,:DWORD,:DWORD,:DWORD
DateStamp2FileTime PROTO :DWORD,:DWORD
FileTime2DateStamp PROTO :DWORD
FindNameInPath PROTO :DWORD
GetCL PROTO :DWORD,:DWORD
GetFileExist PROTO :DWORD
GetFileInfo PROTO :DWORD,:DWORD,:DWORD,:DWORD,:DWORD
GetModulePath PROTO :DWORD,:DWORD,:DWORD
ReadFileLines PROTO :DWORD,:DWORD
RecurseFolder PROTO :DWORD,:DWORD,:DWORD
RegisterFileExtension PROTO :DWORD,:DWORD,:DWORD
ResolveLink PROTO :DWORD,:DWORD
ResolveLinkIndirect PROTO :DWORD
StripFilename PROTO :DWORD,:DWORD
IsShortcut PROTO :DWORD
Posted on 2004-12-27 06:59:16 by donkey
Thanks! Very kind :)



/siddhartha
Posted on 2004-12-29 00:45:22 by siddhartha
Donkey,

I just sniffed around your web-page, and want to confirm that your lib sources are free for any use?

I would like to use some of your research as resource objects in our OA32 package? Obviously full credit will be given to your and any authors noted in the sources. I just want to make sure your ok with the idea of me wrapping some of the routines into OA32 objects? Your GDI work will probably be used the most.

Regards,
:NaN:
Posted on 2005-01-14 16:42:11 by NaN
Hi NaN,

The lib files and any other code on my site are free for any use, including comercial software. So yes, you can use them for anything you like. There are a few functions that I have farmed from example code and the author is named, in all of those cases I was confident that the code had no stings attached, but the majority of the functions were written by me or translated from free C source.

I would ofcourse be pleased and proud that you thought my little projects worthy of your attention and would ask that I could post a link when you are done.
Posted on 2005-01-14 18:24:13 by donkey
Not a problem. I certainly will let you know. I'll set you up with a private screening if you'd like ;)

The version currently on BiteRiders site will be updated soon, as there is another version close to being ready that is far more powerful. As such im trying to beef up the package with usefull objects to help simplify and manage certain aspects of windows, like GDI. My hope is a well designed object structure can be both reusable and trustworthy not to cause memory leaks. The framework of this GDI object i have in mind is ready, but your work is the meat of it all ;) . After all, its still gotta do something ;)

Regards,
:NaN:
Posted on 2005-01-15 20:55:31 by NaN