This is a VO error I have quite often. The only thing which helps is leaving VO and restarting it. As this only takes a few seconds I usually don't care too much but I wonder if there's a way to prevent it:
Error in function LnkCreateView: Can't create file mapping for (....exe)
Causes are disk space, read access to cavo, exe not freed or repo not up to date
None are applicable. I e.g. regularly create a new repo in which I import a full export of AEF's from the previous repo.
This is usually an indication that Linker cannot allocate a contiguous block of memory for one of the sections in the exe file.
Did you change any of the values in the linker settings in either the project settings dialog or the default settings dialog.
You can either check the dialogs, or look for the VOLINK section in cavo28.cfg or your project file (voprj file in the repo folder)
XSharp Development Team
You must have changed these numbers. They are quite big:
BinarySize: 0xC000000 = 200Mb binary size.
ExeAtomTableSize: 0x4000000 = 64 Mb of Symbols in the symbol table
Text section: 0xE000000 = 230 Mb.
An exe produced with VO contains a couple of sections:
.text = the assembly code
. data = data
. idata = import table for code in other DLLs
. edata = export table for exported functions and data
. rsrc = resources (menu, form, images, string tables etc)
. symbol table
All of these together should not be bigger than the Binary Size.
Of course for some app you will have more code, for others more data, resources or symbols.
But it really does not make sense to have one of these bigger than the binary size.
I suggest you comment out all of this section and try to link again. I would not be surprised if it then just works.
XSharp Development Team
I tried this and indeed VO functioned error free. I started a few programs. To my surprise, only this morning it went wrong:
Maximum size (0x3000000) of section .text exceeded
and after adapting that:
Size of EXE File exceeds maximum size (0x4000000)
As it is difficult to determine which settings needed which values, I restored the section and brought down a few values which I hope are not critical and increased the one of the binary to 0xF000000 . I will have to do some hex adding to see if the total is now <the binary but for now I'll just wait to see if this solves it.
After 2 days with quite some VO programming I can say that I didn't see the problem once. So I guess your remark "All of these together should not be bigger than the Binary Size." seems to have solved the problem as normally I have this a few times a day.