Suructure of the folder tree of MASM

[Rockphorr]

LIB and INC folders in masm contain too more files.
May be separate them?
For example  dlls of kernel move to Kernel subfolder direcrtx to directx subfolder, etc.
I know that linux has standarded folder tree.

[Human]

then change to linux, dont use masm. i stoped using linux since redhat 8.0 when it become windows and only way to adminstrate it is xfree or edit .conf files like slackware, funny microsoft tries to do tools to admistrate system in cli, linux removes all them and do all like windows before. so why use 2 windows like systems?
c++ uses mostly only one dir incude and libs and thats all and thats best ways, why? its doesnt slow down anything because even if in include there thousend of files it doesnt matter. it includes only those you want

stupid question like topic.
what is suructure?
:P

[Rockphorr]

I think that there is a reason to create DIRECTX subdir (for example)  in \LIB and \INC and move here *.dll and *.lib of DIRECTX.
In source code i will write directx\some.inc

c++ uses mostly only one dir incude and libs and thats all and thats best ways, why? its doesnt slow down anything because even if in include there thousend of files it doesnt matter.

This has yet to be proved.

[hutch--]

There is an ancient definition known as Occam's razor which translates to "never do more than you need" to get something done. While you can create as many directories as you like for individual libraries and matching include files which is a common approach I use for testing new library components, with a set of mainly system DLL export libraries, there is little to gain by doing so but a progressively more complex layout for having bothered. A seperate INCLUDE and LIB directory seperate the files as required which is useful in their construction for system DLLs but there is little point of doing much more in an architecture meant for general purpose use.

[zcoder]

c++ uses mostly only one dir incude and libs and thats all and thats best ways, why? its doesnt slow down anything because even if in include there thousend of files it doesnt matter.

This has yet to be proved.

I will prove it, in a IDE where you put stuff like linclude \masm32\include\wsock32\wsock32.inc this will not slow down
the assembler becouse the path is right there, Now take an IDE like C where <wsock32.h> tells the IDE to
use the enviroment directorys for INCLUDE's it would have to look in ALL those folders slowing down the compile time.

And like me I have such a IDE like C but made for assembly, and that method would slow down the assemble time.


Zcoder....

[Mark Jones]

I've said this before in another thread, but it would be cool if an app were made which loaded \masm32\bin into a ramdrive, compiled and concatinated ALL the libraries to the ramdrive, then updated the paths to point to the ramdrive. Then compilation only requires ONE include, and no disk access is required!

Maybe someday I'll tackle a beast like this but way too busy right now.

[Rockphorr]

There is an ancient definition known as Occam's razor which translates to "never do more than you need" to get something done. While you can create as many directories as you like for individual libraries and matching include files which is a common approach I use for testing new library components, with a set of mainly system DLL export libraries, there is little to gain by doing so but a progressively more complex layout for having bothered. A seperate INCLUDE and LIB directory seperate the files as required which is useful in their construction for system DLLs but there is little point of doing much more in an architecture meant for general purpose use.

I don't offer to create very many subfolders.
I offer to create only real neddly floders.
Win32 is updating and upgrading in many branches.
It will be hard to find and update all files of any branch.
But I remember that you are head of MASM32 project and your solution is a law.