Win_Lnk

back to the download page

Contents

Overview

State of development

Installation

Deinstallation

The extensions  in detail

For Programmers

Changed Functions

Overview

Win_Lnk served originally only to use the Windows links under  MagicPC as real symbolic links. More and more other MagicPC extensions are also inserted. To do that some GEM-DOS-and AES routines are adjusted. In order to bend the BS routines Trapper is used.

 

State of development

This is one of the first public versions, so there still might be some errors.

Installation

To install this programm you have to copy unlnk.dll in the MPS Folder (which might have to be created) in the MagicPC-Folder.  Win_Lnk.prg should be placed either in the Auto-Folder, Start-Folder or be called by the Autoexec.bat, but it can also be started as a normal programm. But regardless of how it is started, Traper has to be active already!
The different parts of win_lnk can be deactivated separatly. For this you need a win_lnk.ini. Normaly it has to be in the same folder as win_lnk.prg. Or if it is started from autoexec.bat or similar, it has to be in the root folder of the boot partition, so normaly in C:\. For more details see the win_lnk.ini added.

Deinstallation

If you restart Win_Lnk when it is already active,you can deinstall it. But this might take time, if some reserved memory is still in use (Pexec,...). This is only true, if both instances of win_lnk have the same version number. But if for example a win_lnk 1.05 is running and you start a 1.06, than 1.05 is replaced by 1.06

The extensions  in detail

  1. Use Windows links under MagicPC as full symbolic links. The purpose was that MagicPC behaves as much as possible as Magic. This, however, in such a way that it is based on the possibilities of Windows. How to use symbolic links under MagicPC is explained in the Magic documentation. However, there are some specific differences. You can define links under Windows or MagicPC Some things wich are possible under Windows would not be possible under Magic and thereby might couse problems. The main problem are doubly defined names. For further details see. under Dreaddir (297) and Dxreaddir (322) . My advice, omit such things.
  2. Win_lnk offers a possibility to define Environment variables under Windows and to use them under MagicPC. This is mainly usefull with multiuser-Windows variants, because one can define the variable there differently for every user. Details see under Pexec (75) and shel_envrn (AES 125)
  3. To start Windows programs from MagicPC there is MPC_ACC.ACC. However, this has the disadvantage that it forgets to adjust the paths. Windows program gets the MagicPC - paths. Now WIN_LNK offers the possibility to run Windows programs like normal programs. The ACC is required no more. By defining an Environment string one can determine  which programs WIN_LNK should let run by Windows. This happens in magx.inf in the Root directory. Should for example only *.exe be started by Windows, you have to add this line:
    #_ENV WinExeExt=.EXE;
    To add more extensions these are simply added seperated by a point. In addition, you have to tell your Shell that it should treat these files like programs. This happens in Jinnee, e.g., under Other / settings. There select on the left side programs and add the extension, e.g., *.exe. as GEM-Programs (I never saw Jinnee in english)
  4. MagicPC can connect the clipboards on Atari side with the Windows side. Unfortunately, this functions in the direction Atari-> Windows only once. This can be correct by WIN_LNK. Up to now WIN_LNK only supports( like MagicPC ) only texts. Win_lnk ignores the setting of MagicPC if the Windows - clipboard should be used. Who does not want it it must deactivate it at both places.
  5. Égale: To reduce the problems of Égale with the casesensitivity of file names, I patched it. In addition to the patched version, some OS-functions had to be changed to. this can either be done with the separate dir_lwr or with win_lnk. For more details see dir_lwr

For programmers

Logfile

From V 0.32 a log file can be written from the Windows side.
This Function can be (de)activated in two ways:

  1. by defining DOLOG (#define DOLOG) both in win_lnk.c and in unlnk.cpp.
  2. by restarting Win_Lnk, there you can also deinstall Win_Lnk.

As from version 1.0 DOLOG is normaly undefinde.So if you want to use it you have to insert the #define.. The reason that I deactivated it was that this function caused as many errors as it helped to solve. For the loging to work either the system variable LOGDIR or TEMP must be defined (on the Windows side!)! Alternatively one can also debug MagicPC  ( Task manager.) Then, if DOLOG is definded but the loging is disabled, TRACE prints into the debug window. Because some MagicPC versions have problems with this Debug-dll, I add only the release version. To the reactivate the log one must recompile the dll anyhow.

changed functions

In parentheses} the Gemdos-function numbers are given. The functions are listed In groups. Single functions can appear several times.

 

Fcreate(60) Fopen(61), Pexec(75) and Fattrib(67)

If these functions are applied to a link, this is followed. Indeed only if it hasīnt the extension .lnk. Because the Fileselector, Fsfirst/Fsnext, and D(x)readdir the LNK cut that extension off,  this is the normal case. In addition, in Pexec Windows environment variables are added, see afterwards and it can instruct Windows to start Windows programs. Fcreate and Fopen are also changed for transferring of the clipboard see below.

Pexec(75) and shel_envrn(AES 125)

A problem of MagicPC is that it has no multi user abilities. An important point, are user dependent environments. Above all e.g., HOME. However, depending of the Windows version under which MagicPC runs this might be offered by the host system. So why not just transmit the environments from windows to MagicPC. Iīll explain it most simply by an example. If we would like to define HOME on the Windows side, then add the following line to Magx.inf:

    #_ENV HOME=%WIN%

If HOME is used now, Win_Lnk recognizes that it should take the definition of HOME from Windows. However, if for some reasen HOME should have different values under both systems, then one can choose on Windows any other name, e.g., HOME_MP. Then add the following line to Magx.inf:C.

    #_ENV HOME=%WIN%:HOME_MPC

In the 1st case one must define HOME and in the 2nd HOME_MPC under Windows. Environments can be retrieved under MagicPC in 2 ways, either by shel_envrn that of the Shell, or from the own basepage. The latter is given down with pexec or is defined newly. Therefore, both ways are suported. The syntax must be kept exactly, thus no additional blanks or similar. Win_lnk tries to interprete the variable as a filepath and if necessary transfer it from the Windows path system to the MagicPC System. So define Pathes under Windows as Windows knows them.

Fcreate(60) Fopen(61) Fclose(62) und Fdelete(65)

if scrap.txt (in the suitable Directory) is opened in write mode(Fopen or Fcreate) win_lnk memorises the handle. If this file is closed later, win_lnk will copy the content to the Windows clipboard.

Fcntl(260) cmd=0x4600

Here the S_IFLNK bit is set if necessary

 Fxattr(300)

According to the Flag links are followed or not. Folder links are always followed.

Freadlink(303)

 returns the target of a link

Dreaddir(297) und Dxreaddir (322)

If a file is recognized as a link, the extension .lnk will be removed. If then the filename is not unique any more a ~L will be added to the file name. In addition, in mode S_IFLNK is set. Letīs say there are the following 3 files in a directory::

  1. file1.txt.lnk
  2. file1.txt
  3. file2.txt.lnk

if in 1) only the .lnk would be removed, 1) and 2) would not be distinguishable any more.
Therefore, D(x)readdir changes the names to:

    file1~L.txt
    file1.txt
    file2.txt

Dopendir(296) Dclosedir(299)

These both functions react as before, but since D(x)readdir needs some parameter from Dopindir, I save them here. And since this memory has to be freed sometime, I also had to change Dclosedir.

Fsnext(79) and Fsfirst(78)

The goal was to return short file names (8.3) for links which however have the right extension. The normal Fsnext would return always a *.lnk. A problem are files which exist once as normal files and once as a link. In addition, the change of the extension had to be reversible. Here an example:


In a directory there are the following files:

  1. liesmich.txt
  2. liesmich.txt.lnk
  3. liesmich
  4. liesmich.lnk
  5. readme
  6. readme.lnk
  7. lizemoi.txt.lnk
  8. lizemoi.lnk
  9. cat.prg.lnk

All lnk files are links. The normal Fsfirst would return these 9 names:

  1. liesmich.txt
  2. liesmi~1.lnk
  3. liesmich
  4. liesmich.lnk
  5. readme
  6. readme.lnk
  7. lizemo~1.lnk
  8. lizemoi.lnk
  9. catprg~1.lnk

The file 2) wouldīnt  be recognizable for an editor as a text file, and the files 4), 6), 7) 8) and 9) would have extensions meaningless to most users and programs.  Therefore, the new Fsfirst/Fsnext routine return these names:

  1. liesmich.txt
  2. liesmi~B.txt
  3. liesmich
  4. liesmich.~L
  5. readme
  6. readme~L
  7. lizemo~B.txt
  8. lizemoi.~L
  9. catprg~B.prg

Should these files be opened later, e.g., with Fopen, Win_Lnk recognizes the ~ followed by a letter and knows that these are accordingly manipulated file names. And it can reconstruct the original 8.3 short names. "~L" and ". ~L " will get simply be eliminated ~A to ~J will be replaced by ~0 to ~9. In addition, if an extension exists it will be replaced by lnk or otherwise .lnk will be added. What I realy donīt like is case 4) but methode 6) is not aplicable for files with nomes of more than 6 chars. 9) is also not very nice.

fsel_input (AES 90) and fsel_exinput(AES 91), rsrc_load (AES 110), shel_find(AES 124) and shel_write (AES 121)

have automatically adapted themselves so to speak, they probably internaly call other changed Gemdos functions.

Fdelete(65), Frename(86)

If source file is a link, this one (the lnk file) will be deleted or renamed.

Fsymlink(302)

Here I have wrote a all new routine which accesses the Windows routines. The link target is followed if necessary. So no links on links are created. This is the way Windows does it, and because MagicPC should follow the rules of Windows in itīs file system, I just did it in the same way.

Dpathconf(292)

here only directory links are followed.

 Dcreate(57), Ddelete(58) und Dsetpath(59)

If these return an EPTHNF error it will be tried to follow a link and then if necessary to call the function again.