dear mikl et al ..
ive tried compiling tutorial16 with ml64 [version 9.00.30729.01] and linker obtained from the microsoft SDK Although this compiles OK it doesnt run It may be due to the associated dlls which are ms..80 and 90. I no longer have the ability to download vast amounts of stuff to obtain a working set. Would somebody be kind enough to email the appropriate dlls etc so that i can compile your examples.
Second question ... i am using linked lists of heaps in a 32 bit program and can accommodate about 12 million records and linked lines of data at which point im pretty much at the 2 gig limit for the program .. is the virtal program space extended for 64 bit as im unclear about this
regards mike burr
Hi, Mike burr!
I would like to ask you a few questions. You wrote "I have tried compiling tutorial16... Although this compiles OK it doesnt run" This means that the compilation and launch of lessons from 1-st to 15-th have been successful? Or your programing cycle started from the 16-th lessons? Can You show the contents of the bat-file for compiling and linking the asm-text of the program?
thanks for your prompt response Mikl .. i tried the compilation again with tut_22 just in case i had done something odd .. obviously i dont have stub.exe so i compiled without that directive and was getting an align 16 error which i thought odd "LNK4108 /ALIGN specified without /DRIVER or /VXD; image may not run " i realised then that the Version of CMD.EXE that id dumped in with the tut to run it might be an old pre 64 bit version. This canny hunch may have proved to be true even if the reasoning was in error ...but is a salutary warning to ALL SLACK-ALICE's like myself to be a little more careful ... so .. the compile is using your original .bat file minus the STUB and works fine ...
HOWEVER ...i still get the linker warning when compiling TUT_33 .. i thought i try an /IGNORE:LNK4108 command which didnt do anything [which is not surprising as i dint look to see if this was a properly formatted command ]
any way thanks for all your good work converting the examples ... the ms 80 and 90 dll's seem to work ok but i would be grateful if somebody could send me the 140 versions as i know ill be up to date ...i dont want Visual C and its too large to download as ive got a very limited download capacity on the dongle attached to the computer here .
ALSO does largeaddressware:YES mean that you get more the full 64 bit virtual address space as the reason for wanting to convert to 64 bit is so that i can use this if possible as my programs are currently limited to 2 gig [ i use Heap allocation for the data and working storage ...but run concurrent threads .. which is not for the faint hearted ]
This is probably also a question for Hutch etc
just tried tut_31a and that gives a load of error messages relating to LV_column and LV_item neither of which are in win64.inc but obviously are in windows.inc .. what is in and what isnt ??? what MASM32.COM really needs is a definitive set of inc libraries etc as this is all a bit haphazard ???
regards mike b
Hi, Mike burr!
I could send to you ml64 and the dll-s, but I need your e-mail address because I don't want litigations Microsoft against masm32.com
If you want to deal with Iczelion tutorials x64 -- It makes sense to start with the first lesson, and not with tut_16-th, tut_22-nd or tut_31_a-st
:biggrin:
> what MASM32.COM really needs is a definitive set of inc libraries etc as this is all a bit haphazard ???
Feel free to write them yourself, I don't get paid for producing include files and the version of win64.inc has many hours of work done on it to get most of its content up to date.
Hi, hutch--!
Do not be so serious about these words (https://wasm.in/styles/smiles_s/smile3.gif)
dear hutch and mikl
i certainly didnt mean anything derogatory. The MASM32.COM BIT IS SUPERB precisely because you can download the working set as a novice [like me a few years ago] and you can work through the examples knowing they work and mess around with them. The 64 bit doesnt seem to have that organisation. Im not sure whether thats because of distribution because its a Microsoft Proprietary product or that everybody is expecting Hutch to do everything, which certainly isnt very fair. Cant we all chip in somehow and make the equivalent for 64 working set that you have made for 32. I realise that Iczehelion and Mikl have gone to a lot of trouble to make the examples possible which im sure will have benefited everyone who looks at this site,[ along with the peles and japeth compilers and so on ...]
regards mike b
dear Mikl
i did compile a few of the very early ones but they were a bit too simple. I was looking for things which were closer in concept to the stuff i have here.
How do i send you my email address ???
regards mike b
Mike,
The 64 bit project is a work in progress and differing from the late 1990s where I worked with a lot of very skilled people to construct the early version, I have had to write all of the 64 bit code and structure myself and that includes rewriting a vast amount of the win64.inc file then testing it to make sure it was reliable.
> Cant we all chip in somehow and make the equivalent for 64 working set that you have made for 32
Probably not as the complexity would knock you over and one glitch and the assembler will pelt garbage at you. For the equates LV_column and LV_item you look them up and put them into your own source file and they are probably the same as the ones in the 32 bit windows.inc file.
I work on the 64 bit version because I need it myself and I am happy enough to share the stuff I have already done but it is advanced stuff where folks who want to develop in 64 bit MASM need to do their own investigations on extra or missing bits.
dear Hutch .. OK anyway as regards the LV 's thats exactly what i did but it is guesswork rather than certainty ... i have to add that although i struggled a little with the 32 bit at the very start there was so much stuff it was very easy to get going. I was using Ruby previously to try out mu number theory stuff which its surprisingly well suited to but its not as flexible or as fast as assembler plus its very easy to get quite a good GUI interface very quickly with such easy access to the Windows API's .. NO ONE has answered my last question yet though ... will a 64 bit program admit more than the current 2 gig limit in storage .. where can i find out about the compiler options too other than the scant help in ml54 itself ???in fact is there an ml64 manual of any kind as other people seemed to have written better ones than MS for the 32 bit compiler ???
regards Mike b
Hi, Mike burr!
I sent to you ml64, link, dll-s and another files. I renamed *.dll to *.d, *.exe to *.e, *.bat to *.b so to send attachments without problems. You will create folder masm64 and nested subdirectories: bin, lib, include, images, samples
The files you received are for the bin folder\masm64\bin
api-ms-win-crt-conio-l1-1-0.dll
api-ms-win-crt-convert-l1-1-0.dll
api-ms-win-crt-environment-l1-1-0.dll
api-ms-win-crt-filesystem-l1-1-0.dll
api-ms-win-crt-heap-l1-1-0.dll
api-ms-win-crt-locale-l1-1-0.dll
api-ms-win-crt-math-l1-1-0.dll
api-ms-win-crt-process-l1-1-0.dll
api-ms-win-crt-runtime-l1-1-0.dll
api-ms-win-crt-stdio-l1-1-0.dll
api-ms-win-crt-string-l1-1-0.dll
api-ms-win-crt-time-l1-1-0.dll
api-ms-win-crt-utility-l1-1-0.dll
asm2.bat
Bind.Exe
cvtres.exe
dumpbin.exe
hiew32.exe
link.exe
link.exe.config
ml64.exe
mspdbcore.dll
msvcdis140.dll
msvcp140.dll
pgodb140.dll
rc.exe
rcdll.dll
stubby.exe
vcruntime140.dllto fill the subdirectories lib and include you create a bat-file with the following contents@echo off
cls
set masm64_path=\masm64\
set FileName=user32
if exist %FileName%.inc del %FileName%.inc
if exist %FileName%.def del %FileName%.def
%masm64_path%bin\dumpbin.exe /EXPORTS %windir%\System32\%FileName%.dll /OUT:%FileName%.txt
@echo EXPORTS >> %FileName%.def
for /f "skip=16 tokens=1-4" %%a in (%FileName%.txt) do ( if "%%a"=="Summary" goto :exit
if "%%d"=="" ( @echo extern __imp_%FileName%_ordinal%%a:qword >> %FileName%.inc
@echo %FileName%_ordinal%%a TEXTEQU ^<__imp_%FileName%_ordinal%%a^> >> %FileName%.inc
@echo %FileName%_ordinal%%a=ordinal%%a @%%a NONAME >> %FileName%.def
) else ( if not "%%d"=="(forwarded" ( @echo extern __imp_%%d:qword >> %FileName%.inc
@echo %%d TEXTEQU ^<__imp_%%d^> >> %FileName%.inc
@echo %%d=__imp_%%d >> %FileName%.def )))
:exit
%masm64_path%bin\link -lib /DEF:%FileName%.def /OUT:%FileName%.lib /MACHINE:X64you willl substitute names "user32", "kernel32", "gdi32" etc. in line "FileName="
Mike,
> will a 64 bit program admit more than the current 2 gig limit in storage
If you build 64 bit apps with the /LARGEADDRESSAWARE option, you can exceed the 2 gig limit but it also prevents you from using some of the older mnemonic constructions. You get this from reading the "link /?" data.
YES the ml64 documentation is lousy, much of what is posted on the internet is wrong and most of the code is crap from folks who don't know how to write a prologue/epilogue in MASM.
These are the joys of working on a leading edge area, bad mannered tools, lousy documentation and people who don't know what they are talking about and the need to do everything the hard way as there is no other way.
Now as you are using the work that Mikl__ has done, you need to ask him about the methods to use with that system. He has done a lot of work with the tutorials and has been able to get a lot of code up and working.
2 relies in 1
Dear mikl
i tried to send you a program present using the same renaming strategy by which you sent me what i needed .. my pressy is a bit rubbish by comparison but ill post it here if i can figure out how to do it . Itll prob be in the wrong place here as its a quite large 32 bit program listing and a large prime number file [in label dd value format ]
Dear Hutch
why cant you and the other knowledgeable people send me roughly the information you think should go in a MASM 64 GUIDE and ill write it in a vaguely coherent form and maybe thatll help the direction of use of 64 so it can be a bit more standardised as it sounds like everybody is trying to do their own thing finding out how best to make use of 64 rather than one cohesive effort
ps funny enough all that strange looking Russian text is relatively translatable without Google .. once you know that a H is approximately a N(ye) in Oz and a Pi is a Fu etc you pretend youve got a Comedy Russian accent and many of the words come out in sort of strained Oz , the worlds a lot smaller than you think and a lot of fun too
regards Mike b
Quote from: hutch-- on October 07, 2017, 03:47:10 PM
If you build 64 bit apps with the /LARGEADDRESSAWARE option, you can exceed the 2 gig limit but it also prevents you from using some of the older mnemonic constructions. You get this from reading the "link /?" data.
I believe that when building 64-bit applications /LARGEADDRESSAWARE is the default. You have to explicitly use /LARGEADDRESSAWARE:NO on the linker command line for the LARGE_ADDRESS_AWARE flag being absent from the File Header.
dear Mikl
put an upload on here as thanks ... the show hide routine is fun and theres a list of primes embeded adequate for anyone wanting to find small components of numbers http://masm32.com/board/index.php?topic=6598.0 The bat etc i already have just wanted to eliminate as many variables as possible because i want to try and convert the stuff i have here as a major intention
dear awl37
i think youre correct as i used this to try and determine the address space limitations but reached no conclusion other than probably
Jose,
You are right until you accidentally use an instruction that the linker rejects unless you turn it off and with /LARGEADDRESSAWARE:NO you say bye bye to allocations larger than 2 gig. The suggestion to always use /LARGEADDRESSAWARE involves not writing instructions that do not work with it.
Mike,
Quote
why cant you and the other knowledgeable people send me roughly the information you think should go in a MASM 64 GUIDE and ill write it in a vaguely coherent form and maybe thatll help the direction of use of 64 so it can be a bit more standardised as it sounds like everybody is trying to do their own thing finding out how best to make use of 64 rather than one cohesive effort
I think I mentioned to you that I don't get paid for writing 64 bit MASM code and to add on top of the massive workload of writing, testing and developing code I simply do not need any more work in preparing data for other people who don't have the experience in doing this stuff. While I have a fair bit of work done in 64 bit MASM, it is still research done the hard way of write/test until you get it up and working, reliable and re-usable. I have in fact produced a help file that has some of the technical data that was developed by the write, test, disassemble but making CHM help files is a tedious task and you have to know what you are doing with the code properly to make the reference material reliable. The only thing worse than making CHM help files is fixing other people's misconceptions, lousy architecture and lack of understanding.
You are more than welcome to do your own research and development and I would hope you succeed but I am not going to waste my time contributing to an ill conceived idea of collectively working with people who have not done enough work to get this stuff up and going. I am going to continue to develop 64 bit MASM and will over time share it with other people. Long ago in the 1990s I worked with a number of people who were under corporate NDAs as well as a number of independent and highly skilled programmers and this got the earliest MASM32 up and going.
Quote from: hutch-- on October 07, 2017, 09:40:27 PM
The suggestion to always use /LARGEADDRESSAWARE involves not writing instructions that do not work with it.
That's right, this issue can happen in ASM. In HLL, we don't even think about that, we just assume that we can grab as much memory as we want (in theory of course).
Hi, Mike burr!
Your British English language is too arduous for my Google-translator and I not understood "Did I help you or didn't?"
dear mikl
563/5000
к сожалению, это не сработало ... даже не ml64 .. ошибка
enrty point not found .... ucrtbase terminate ...
не удалось найти в dll
api-ms - .. crt-runtime-l1 ...
вероятно, ошибка самосвала ...
но
Я поставил 140 ... dll в старую двоичную область
а также
компиляция затем дала те же результаты, что и использование jwasm64
эта ошибка является проблемой с temphls.inc
ошибка на линии 905 jj предложила возможный путь, но я считаю, что кто-то, вероятно, уже решил эту проблему
Большое спасибо за Вашу помощь
я использовал переводчик Google и держал свои фразы просто
this should read
sadly it would not run ... not even ml64 .. error
enrty point not found .... ucrtbase terminate ...
could not be located in the dll
api-ms-..crt-runtime-l1 ...
probably a dumpbin error ...
but
i put the 140 ...dll's into the old binary area
and
the compilation then gave the same results as using jwasm64
that error being a problem with temphls.inc
an error on line 905 jj has suggested a possible way around but i reckon somebody has probably already solved this problem
thanks so much for your help
i used google translator and kept my phrases simple
BTW i learnt to phonetically read [but not understand !!] the russian alphabet from the covers of the many Wonderful Vinyl LP's from Melodia featuring the GREAT RUSSIAN COMPOSERS
regards mike b
Hi Mike Burr!
Can you attach the asm-text of the program that you have problems?
Dear Mikl
its not the programs ... this is ML64 itself directly run eg CMD .. window .... enter ML64 /? result ucrtbase.terminate .. [ucrtbase.terminate can be clearly seen in the image so there is a linkage problem ] i did wonder whether there was a path problem
i have realised that the essence of the problem is that i do not understand the relationship between the Intel processor instructions , the compiler [both jwasm and MS] and the code im using
i started to look at Vasily's Temphls.inc and having previously thought that the MACROS facilitating the pre-compile were just to beautify the code i got a nasty shock
1) im working from a knowledge base of practically zero as i did when i started with the assembler and have just an old Borland Turbo Assembler 3.0 book and an even more flimsy knowledge of how a compiler works [and i will lay money that i am not the only one reading this to whom it applies hence Hutch's wise words ]
so ive started to look at the code for the jwasm compiler [ sadly japeths site appears to have gone but the code is still around ] and probably incorrectly at Vasily's temphls.inc [where i should look at the 32 bit stuff first] i got a complete shock ...
the reason for the shock was that i almost never look at code raw after its been compiled BECAUSE I WROTE IT SO I KNOW WHAT ITS DOING [supposedly]
its a lot like knowing about the top of an ice berg ||||
so ... im going to start with the first of your fine examples .. 2a and reduce vasilys temphls etc till i understand what each of the macros does in temphls ... oddly the enter leave prologue epilogue MACROS later on make more sense than for example early statements such as untilcond0 textequ <>
i expect itll be a horrible experience and some of the people on this site might be subject to some very stupid questions
regards mike b
and thanks so much for your help to date
just found your page on https://wasm.in/threads/....and its a better explanation than the Iczehelion ones [ which are excellent and very helpfull ]