That might have been true in the past. like win3.11 and propaganda spread by nix folks when using fat.
Both Os'es and and their filesystems (ext & ntfs) supports a wide variety of linking methods.
It is not propaganda, for a long time Windows was weak in some area, looong time after Windows 3.11 and FAT, and some habits of Microsoft did have a negative impact.
For your information, I have more than 30 years in IT, all the way to MS-DOS (effectively, even before, the first computer I used was a ZX Spectrum, but that, was before my first professional experience), through *nix, Windows from 3 up to 2019 and 11, Mac OS (from well before the X, and also the X), etc. using them in parallel and working on their integration, so I am talking from experience.
The four elements that made it anyway get ahead in the market where: 1) easier for the standard users to use compared with *nix (remembering at first *nix meant Unix, and Linux at the start was definitively not for the non-technical people); 2) retrocompatibility (included with hardware), though that broke at time (e.g. Windows 8, which effectively did not manage to eliminate Windows 7 also for that reason); 3) could be used with a variety of hardware and was not linked to proprietary harwdare like Mac OS (disadvantage, Mac hardware was more "plug and play" well before MS started even using that expression, advantage, cheaper hardware as one could get it from many sources without need for them to pay MS the way Apple kept tight control and high profit margins); 4) starting with NT 4 (could be said 3.51, but that was till "meh" on that aspect) and up, thinking explicitly to make user friendly tools to manage the enterprise environment centrally, which meant to do the basics the learning curve for admins was not so steep and they had pre-made tools available (e.g. no need for a separate LDAP, it came integrated); 5) probably the most important of all, the fact MS had agreements to have it distributed to come with new computers, so people would basically have at home a computer with the same, or a similar ("home" but often also "pro" at home, pro+server or enterprise+server at the office, putting aside the n variants linked licensing and functions activated/disabled) OS that at the office, with an interface roughly similar for the main functions, which created a loop, easier penetration in companies because people have it at home, easier penetration at home because people are used to it at the office.
The last point was actually what started the whole fortune of Microsoft and Bill Gates as individual, way back with MS-DOS: if IBM had not been looking for an alternative OS (for licensing issues) for their PC, MS would not be what it is today.
Of course if you are an evangelist (it was actually a job title in Microsoft, my guess is that someone must after have realised in Europe people would laugh about it, and especially in some type it would not do a good impression at all, or anyway someone I knew who had it managed to convince them, so they changed it) converted to the Microsoft religion
, there is no debate, but I am not religious about OSes.
lets not talk about powershell. its an abomination ;D
I did not like much the separate 7.1, but powershell was one of the smartest idea they had.
I was able to build a domain with different servers for different functions and populate an AD using a sysprep image and some powershelle scripts in three to four hours without need for any extra tools, doing disaster recovery became much easier and more effective, scripting and scheduling maintenance functions without need to use third tools, though operations on the exchange much faster, and made much more effective to do a bunch of remote management functions.
The object-oriented admittedly gets a bit to get used to, and some aspects of the way it manages references and some commands are not forcibly intuitive as name or syntax for me (though that can be me) which at time is a bit frustrating, but the copying the piping from bash was a great idea.
They saw something that worked well, so they were smart enough to have the humility to pick it up, and did not even need to pay a license to use the idea, which of course was also great for them.
Pr0GamerJohnny , if the move of the content is from one directory with the entire library, to one directory with the entire library, even on another disk, it is not necessary to do any of the more convoluted methods, neither the linking of n00bi, nor the stuff with disks and drive letters I described.
You can just move the stuff over to the new library directory, change one thing in the Daz to tell it when the library is located (the paths in the "content directory manager" button in the "content" tab in the preferences), one thing in the DIM configuration (if using DIM) to tell it the assets install path (in the "advanced settings" "installation" tab, "contents path shortcut" ), and one thing in the install manifest directory content (if using DIM), and be basically ready to go.
The last step is not strictly mandatory, but if then you want to update and/or remove the old assets with DIM, is preferable - when installing a package, DIM copies the manifest file to its manifest directory, but in its copy of the manifest file, it adds the indication of the absoute path of installation.
So if you move everything from e.g. c: to e:, and want to be able to do all the management of those assets with DIM, it is better to modify the copy of the manifest files made by DIM changing the drive letter (there are tools that help you do that for all at once, or can be done also with powershell, search on the Internet).
Even if you reinstall DAZ, that will not screw up the library, there is a misunderstanding, must be remembered there three elements (forgetting about Iray and eventual additionals/corollary software life Facegen): Daz Studio itself; the postgresql database that manages the content of the library; the library itself meant as "folders and files on the disk(s)".
If one uses DIM to install assets, four elements, because you must add up DIM.
Daz Studio in reality does nothing on the library itself, unless you start going in the "content library" tab and play in the first three elements there ("daz studio format" "poser format" and "other import format"), which effectively give access to the file system.
In case of a a problem with the Daz setup itself can lose you the configuration of Daz studio and of the plugins and having to reinstall also all the plugins.
The library is logically managed by the database, postgresql, which is independent.
That is what allows you to see stuff in the "smart content", but also in the "categories" and "products" in the "content library" tab in Daz Studio - in the content library tab you can recognised it also because the little icon on the left of those labels is the icon of database.
Daz studio just asks the database, and the database does it, even when you edit the categories, is the database that really does it, not Daz Studio.
I had to delete and reinstall Daz after a screwed up update, and did not have any problem with the library, the problem was the configuration of daz, custom actions, the plugins I had to reinstall, etc. but there was no problem with the database, because the database data directory and the database were not touched.
The "real" or "physical" content of the library (files on the disk) is managed using DIM or the other utility (though notice Daz used to say one can either use DIM or the other way, and should not use both, or at least, not try installing/managing the same content with both).
So, even if the Daz Setup screws up something, or you delete by mistake the DAZ studio directory, your library will still be safe in principle, however, it can be good to save from time to time the content of the database used by Daz Studio, at the very least, brutally the files (not the best DBA advice, but for certain scenarios, the simplest and still effective), so even if you have a crash of the system disk, you don't need to reinstall the whole library (assuming it is not on the C: drive, of course).
The default database library is C:\Users\your_username\AppData\Roaming\DAZ 3D\cms.
It can be moved to another disk, but if the Daz support has no clue about a problem, will say they cannot support you because your database directory is not standard or even try to say you have to reinstall the whole library because the database path is not standard (happened to me, turned out the problem was just a morph, solved myself with help from Internet, luckily I knew enough to know the Daz helpdesk was bullshitting).
