66 replies to this topic

[sambul61]

Olof doesn't claim on that page that all linked from it utilities were written by him in full or in part. The word "compiled" does not reliably indicate that either, if at all. Meanwhile, the titles of software written by MS are assumed copyright protected by default.

[Olof Lagerkvist]

Olof doesn't claim on that page that all linked from it utilities were written by him in full or in part. The word "compiled" does not reliably indicate that either, if at all. Meanwhile, the titles of software written by MS are assumed copyright protected by default.

The dosdev published on my page was written by me and the dosdev published by Microsoft was written by someone else. All I know is that I called my tool dosdev a few years before Microsoft published their dosdev. This should make it impossible for Microsoft to claim any rights to the title "dosdev" in Sweden, were I publish my tools. I could of course rename my dosdev tool to make things more clear, but so far this is just second time in all these years that the question has come up. So I don't think it is much of a problem, after all.

[sambul61]

Of course, it would never come up if not mentioned here, but... since (developed by MS):

DOSDEV.EXE is a very thin wrapper around the DefineDosDevice( ) Win32 API. Fortunately, this API is well-documented on MSDN, and here are its parameters:

Given a device, the DefineDosDevice function defines, redefines, or deletes MS-DOS device names. These "MS-DOS" device names are nothing more than symbolic links in the Object Manager namespace - i.e. symbolic links that reside in the ? namespace (this is the user-mode representation) which is equivalently represented as ??... namespace prefix in kernel mode.

May be you would clarify the difference btw your tool and the one of MS?

What's more important, I suspect NTFS Symbolic Links be its internal features, not supported by DOS. Does that mean that DOSDEV simply assignes a compatible with DOS name for a Windows device in a form of NTFS symbolic link? Anything special about DOS compatible names - why using DOSDEV is beneficial to Mklink and such?

[Sophia]

I could of course rename my dosdev tool to make things more clear

No need - we can call yours simply dosdev and if anyone needs to specifically refer to "the other one", they can call it Microsoft DosDev

[Wonko the Sane]

Meanwhile, the titles of software written by MS are assumed copyright protected by default.

Really?

Since when?

Last time I checked you could trademark a word, BUT NOT copyright one, even if you invented it.
http://www.templeton.../copymyths.html

BTW DOS does NOT support NTFS, the "dosdevices" is not really related to DOS (in the sense of MS-DOS).



Wonko

[sambul61]

Interesting site linked, written by a re-known expert just like yourself.

Wonko In-Sane - the famous deliverer of Insightful-Sanity^® lessons series (also marketed as In-Sanity^® Non-Sense Advice^© Service). I like that...

Btw, the above cited quote can be interpreted in various ways - use your imagination.

[Wonko the Sane]

Well. maybe a quote from the "facts" published on the US Gov site:
http://www.uspto.gov...asics/index.jsp

http://www.uspto.gov...rrect_links.pdf

may help:

TRADEMARK, COPYRIGHT, OR PATENT
What is a trademark or service mark?
• A trademark is a word, phrase, symbol, or design, or a combination thereof, that identifes and
distinguishes the source of the goods of one party from those of others.
• A service mark is the same as a trademark, except that it identifes and distinguishes the source
of a service rather than goods. Troughout this booklet, the terms “trademark” and “mark”
refer to both trademarks and service marks.
Do Trademarks, Copyrights, and Patents protect the same things?
No. Trademarks, copyrights, and patents protect diferent types of intellectual property. A trademark
typically protects brand names and logos used on goods and services. A copyright protects an
original artistic or literary work. A patent protects an invention. For example, if you invent a new
kind of vacuum cleaner, you would apply for a patent to protect the invention itself. You would
apply to register a trademark to protect the brand name of the vacuum cleaner. And you might
register a copyright for the TV commercial that you use to market the product.

You cannot have a copyright on a single word, but you can ask to have one registered and/or make it a trademark, if some conditions apply.

But if you are happy thinking that

the titles of software written by MS are assumed copyright protected by default

I am happy for you , only you should avoid posting this nonsense .


Wonko

[Olof Lagerkvist]

Of course, it would never come up if not mentioned here, but... since (developed by MS):

DOSDEV.EXE is a very thin wrapper around the DefineDosDevice( ) Win32 API. Fortunately, this API is well-documented on MSDN, and here are its parameters:

Given a device, the DefineDosDevice function defines, redefines, or deletes MS-DOS device names. These "MS-DOS" device names are nothing more than symbolic links in the Object Manager namespace - i.e. symbolic links that reside in the \\?\ namespace (this is the user-mode representation) which is equivalently represented as \??\... namespace prefix in kernel mode.

May be you would clarify the difference btw your tool and the one of MS?

Yes, I could add a note about that. But they do pretty much the same thing, so even if someone is looking for one and get the other, it will most probably solve what is needed to be solved anyway.

What's more important, I suspect NTFS Symbolic Links be its internal features, not supported by DOS. Does that mean that DOSDEV simply assignes a compatible with DOS name for a Windows device in a form of NTFS symbolic link? Anything special about DOS compatible names - why using DOSDEV is beneficial to Mklink and such?

The symbolic links I am talking about in this thread are symbolic links in kernel object namespace. They just link to something else, but symbolic links in a special object directory called \?? (or \DosDevices) are the "DOS compatible device names" such as drive letters, COM1 for \Device\Serial0 etc. These "DOS compatible device names" are the device names Win32 applications can access directly through Win32 API (kernel32.dll and everything on top of that). With the dosdev tool (any of the two) you can assign your own symbolic links in \?? directory to make other things directly accessible to Win32 applications. Inside the Windows kernel and through the native API in ntdll.dll, these symbolic links are not really needed because their targets are directly accessible anyway.

What you are talking about on the other hand are two other kinds of symbolic links. One is the "Shell Link object", also called "shortcuts", something that lives in shell32.dll. The other is the "NTFS reparse point" of type "link". If you link one file to another, they will point to the same storage in the filesystem. But if an application, when updating file contents, first delete the file and then create a new with same name, they will not be linked any more.

One way around this is to use the "linkd" tool from Microsoft or my "junc" tool to link the directories holding the file that should be linked together and make these directory links point to a common directory. That way applications can delete and to whatever they like with the files there because when they create a new file it will actually be created in the directory pointed to, which will still be the same for all users. I don't know if this is suitable for your particular application, but sometimes it is useful to know this possibility as another option.

[sambul61]

Olof

Thanks a lot!

I'll explore linkd or junc (nice name - definitely distinct ) tools for this purpose. The described scenario with Opera should probably affect you too, as I suspect many people in Sweden prefer Opera to other browsers (most in Norway). I don't think however, a soft symbolic link is a shell link object as opposed to a regular shortcut - its rather a file system object IMHO.

[sambul61]

Wonko

I appreciate delivering one of your In-Sanity^® series lessons, BUT :

1) you should learn to make delivery of a lesson, when someone placed an Order requesting it. Otherwise it feels rude and intrusive.

AND

2) you must learn reading attentively such Order Notes people address to you, like: "the above cited quote can be interpreted in various ways - use your imagination".

Once you comprehend the issue the best you can, and use your imagination to full extent (however severely impaired), please avoid delivering anymore your patented nonsense.

[Olof Lagerkvist]

Olof

Thanks a lot!

I'll explore linkd or junc (nice name - definitely distinct ) tools for this purpose. The described scenario with Opera should probably affect you too, as I suspect many people in Sweden prefer Opera to other browsers (most in Norway).

I have very little experience of Opera, pretty much never used it. I use Mozilla-based browsers or IE most of the time.

I don't think however, a soft symbolic link is a shell link object as opposed to a regular shortcut - its rather a file system object IMHO.

That is right. A soft symbolic link is still in the second category of the two link types I wrote about that you had mentioned in this thread, as opposed to Shell Link objects that are in the first category. Soft symbolic links are implemented as NTFS reparse points, just like junction points for directories. But still, if an application delete the link and create a new file, the link is gone.

[sambul61]

One way around this is to use the "linkd" tool from Microsoft or my "junc" tool to link the directories holding the file that should be linked together and make these directory links point to a common directory. That way applications can delete and to whatever they like with the files there because when they create a new file it will actually be created in the directory pointed to, which will still be the same for all users. I don't know if this is suitable for your particular application, but sometimes it is useful to know this possibility as another option.

Apparently MS set the rule in Win 7 & Vista to replace a path set in a symbolic (file) link to a target file with the path to the link itself, if it's referred to via another symbolic (folder) link. That's why Opera replaces the link with the file, it doesn't delete the link. They set the rule, giving no background and/or documenting it. Its hard to say what's the logic behind it, but may be you can clarify a possible reason?

Could you illustrate your above suggestion by an example? I.e., Opera Profile is supposed to be installed on C: drive. I replaced it with 3 symbolic folder links, pointing to Profiles 1,2,3 on K:. All 3 Profiles start as identical, but overtime will accumulate differences. But certain files and folders inside them I need synced (while the rest MUST remain different). Now I can launch Opera instance by a shortcut, pointing to Profile 1 or 2 or 3 on C:.

Lets talk about a single file for simplicity, which I want to keep synced in all 3 Profiles: Bookmarks.adr. Now, could you illustrate your junc approach using this example? Also, will it work with Win7 64-bit?

[Wonko the Sane]

@sambul61
II perfectly know that is of no use telling you when you post false, misleading info or absurd statements , you will never learn to think and check before posting such deceptive products of your fertile mind, let alone admit that you were going completely off target or off topic.

I am doing a service to the Community as some of the less experienced members may actually got misdirected by the FUD you so aptly spread on the board .

This way everyone is warned and can take his/her own steps to verify the info.


Wonko

[sambul61]

Olof

If my above example is not good for the your suggested approach, may be there is a different suggestion? In any case, could you give a code sample, how your above approach works?

The dosdev published on my page was written by me and the dosdev published by Microsoft was written by someone else.

Since you published a number of interesting software titles on your webpage, I assume they were all written by you and hence copyright, unless expressly stated otherwise? It looks like some titles presented free alternatives to similar fee based MS packages? Do you plan to update them for Win 7, or may be just update your site, indicating Win 7 support for each utility where applicable?

[Olof Lagerkvist]

Olof

If my above example is not good for the your suggested approach, may be there is a different suggestion? In any case, could you give a code sample, how your above approach works?

Say you have a directory "abc" under each user's profile directory, C:\Users\user1\abc,C:\Users\user2\abc and C:\Users\user3\abc. Now, if you want all these directories to be shared between all users you could for example:

* Move files in one of the directories to a new common directory, for example C:\common\abc.
* Delete all existing files in each user's own "abc" directory.
* Type:
linkd C:\Users\user1\abc C:\common\abc
linkd C:\Users\user2\abc C:\common\abc
linkd C:\Users\user3\abc C:\common\abc

After this operation you could access directory C:\common\abc through subdirectory "abc" in each user's profile directory. Because the directory itself is linked and not the files within it, it does not matter whether or not an application removes or do whatever with a file it updates in the directory. When a new file is created in the linked subdirectory it will actually be created in target common directory.

Something like that.

[Wonko the Sane]

Since you published a number of interesting software titles on your webpage, I assume they all were written by you, unless expressly stated otherwise? It looks like some titles presented free alternatives to somewhat similar fee based MS packages?

Isn't "my" an express statement of ownership and authorship?
Or distributing the Source code be proof enough of authorship?
Like:
http://www.ltr-data.se/index_en.html/

Free software download
You may also like to take a look at my free open source programs. It is a large collection of tools, mostly for simplifying Windows administration and support. These tools could also be seen as examples of what kind of specialized programs I can write or modify for your needs, so if you have any questions about these programs, error reports or ideas about modifications please send me an e-mail.
Click here for my open source tools and utilities

And:
http://www.ltr-data.se/opencode.html/

Some of my programs listed here are written many years ago and some are new, but most of them are now recompiled with MSVC++ compiler. Source code for the utilities and many other small test applications are available here as a 7-zip archive,

Or are you implying that besides (according to you) mis-representing the Author of the tools Olof additionally stole the Source Code and distributes it in an unauthorized manner?


What happens if you run (example) dosdev /?

C:\>dosdev /?
DOSDEV is a user interface for the Win32 API functions DefineDosDevice() and
QueryDosDevice(), used to define, redefine, or delete MS-DOS device names in
Windows NT/2000/XP/2003 or MS-DOS drive aliases (SUBST) in Windows 95/98/ME.

Freeware by Olof Lagerkvist, © 1997-1999.
http://www.ltr-data.se olof@ltr-data.se

Wonko

[sambul61]

Olof

Thanks, that will work like you described. One can use Mklink or Link Shell Extension instead of linkd (which is hard to get and was designed for Win2K) to add such Symbolic Folder Links as well I assume? My above example calls for a different approach, since some folders and files in each Opera Profile must remain different, such as (Web) Cache folder content and some others. May be you have a suggestion for that scenario, how to keep only certain file titles synced inside each abc folder? I now wonder, if they only can be transferred to a Common folder as you suggested...but, the problem is, this NTFS Symbolic Links handling rule will apply.

[Olof Lagerkvist]

Since you published a number of interesting software titles on your webpage, I assume they all were written by you, unless expressly stated otherwise?

Yes, of course. If nothing else said, they are written by me. For example for the "cut" utility I state "My Win32 port of the BSD cut utility" so that is an example of open source software not written by me but ported to Win32 by me.

It looks like some titles presented free alternatives to somewhat similar fee based MS packages?

Yes pretty much like that these days. Back in my first university years 1997-2000 many of them were written to do things from command line or batch files that could not be done from command line with MS official tools available at that time. Over the years MS have been a lot better in providing command line tools so in many cases there are nowadays MS official alternatives available.

Do you plan to update them for Win 7, if needed, or may be just update your site, indicating Win 7 support for each utility where applicable?

Could be something for the future. I would say most of the tools should work correctly on Win 7 but since I have not tested most of them on Win 7 I have not written anything about Win 7 either.

[sambul61]

Since kernel mode symbolic links seems to have a different role compare to user mode links (if I get it correctly from above), may be you can separate this thread into 2, if you feel the need? The new thread may be called: Creating Symbolic Links with LTR Data utilities - something like that. The question of symbolic links detail usage is rarely addressed on this forum if at all, so I suspect this thread will get interest from many NTFS explorers.

It might be a good idea to clean it up along the way from some unrelated In-Sanity^® brand "staff", or even put it in a historical 3rd thread entitled... Quasi-legal and Pseudo-judicial Aspects of Software Development (In-Sanity^® Defense). Someone might be interested to exploit other legal topics as well, since many people here are engaged in code writing.

[Olof Lagerkvist]

Olof

Thanks, that will work like you described. One can use Mklink or Link Shell Extension instead of linkd (which is hard to get and was designed for Win2K) to add such Symbolic Folder Links as well I assume?

These links are called Junction Points, or at least were called so back in Win 2000. They can be used in more recent versions of Windows as well. There is a new kind of folder links nowadays that works pretty much in the same way, also implemented as NTFS reparse points, for example C:Documents and Settings folders are linked to C:Users in that way.

My above example calls for a different approach, since some folders and files in each Opera Profile must remain different, such as (Web) Cache folder content and some others. May be you have a suggestion for that scenario, how to keep only certain file titles synced inside each abc folder? I now wonder, if they only can be transferred to a Common folder as you suggested...but, the problem is, this NTFS Symbolic Links handling rule will apply.

I don't know of any way to do exactly that.

[Sophia]

Could someone please help me out once more with the various "paths" that exists in Windows? If anyone has a link to where it is described, that would be fantastic.

Anyway, here's the question:

I understood the distinction between "?" and "??" paths styles (Win32 vs. NT). But what about a "." path? For example ".C:"... when I pass both .C: and ?C: into CreateFile(), it seems to work in the same way, but are they really the same?

[Wonko the Sane]

Could someone please help me out once more with the various "paths" that exists in Windows? If anyone has a link to where it is described, that would be fantastic.

Some are talked about here:
http://reboot.pro/2425/
you will ned to use the converter to read the botched codebox contents :
http://reboot.pro/15275/


Wonko

[Olof Lagerkvist]

Could someone please help me out once more with the various "paths" that exists in Windows? If anyone has a link to where it is described, that would be fantastic.

Anyway, here's the question:

I understood the distinction between "\\?\" and "\??\" paths styles (Win32 vs. NT). But what about a "\\.\" path? For example "\\.\C:"... when I pass both \\.\C: and \\?\C: into CreateFile(), it seems to work in the same way, but are they really the same?

The \\.\ prefixed paths are something half-ways the conversion from Win32 paths to native paths. It is an intermediate step where you can still use some Win32 specific syntax such as current/parent directory symbols (. and ..) that cannot be used in native paths. With \\?\ prefix on the other hand, no Win32 specific syntax can be used because the system takes the path as is without any conversion except replacing \\?\ with \??\ when converting to native path.

The system routine that handles path conversion is RtlDosPathNameToNtPathName_U. I don't have any links to information about this off hand, but perhaps you could Google on that function name or look in the WDK/IFS kit documentation.

[sambul61]

It would be nice to give a definition of (NTFS or DOS or NT kernel ?) "Native Pass".

I wonder, why ImDisk doesn't use Windows Volume Manager - it would allow to have GUIDs assigned to mounted by it drives. I remember having an issue with some drives not showing up in Disk Management Console (if it has the same cause). Don't recall now why it was a big headache, but still interesting, if there are any advantages & drawbacks for ImDisk in using the Volume Manager & assigning a GUID to a mounted drive, generally following this standard Win pass?

For example, in some iSCSI configs, writing to local volumes may be blocked at certain situations by iSCSI Server, but it may not work properly with local volumes not having GUID assigned, so it becomes a major security issue.

[Olof Lagerkvist]

I wonder, why ImDisk doesn't use Windows Volume Manager - it would allow to have GUIDs assigned to mounted by it drives. I remember having an issue with some drives not showing up in Disk Management Console (if it has the same cause). Don't recall now why it was a big headache, but still interesting, if there are any advantages & drawbacks for ImDisk in using the Volume Manager & assigning a GUID to a mounted drive, generally following this standard Win pass?

There are quite a lot of control requests and callbacks to handle to fully support Volume Mount Manager interaction. Also, ImDisk development started in a time where support for Windows NT 4.0 and earlier had priority and they did not have Volume Mount Manager and volume GUIDs at all. I would say that the easiest way today to correctly support Volume Mount Manager would be to start off with a new driver development that can for example emulate a SCSI miniport and enumerate virtual devices on that so that the ordinary disk.sys driver used in Windows can handle all the complicated stuff, which it is really good at and probably not worth it to try to duplicate.