LB Booster
General >> General Board >> Startup problem
http://lbb.conforums.com/index.cgi?board=general&action=display&num=1467122050
Startup problem
Post by Richard Russell on Jun 28th, 2016, 1:54pm

Right back to Windows 95 there has been no guarantee that large amounts (e.g. 1 Gbyte) of contiguous virtual address space would be available. DLLs contain a 'preferred' load address, and (at least in versions of Windows up to XP) may end up being loaded somewhere near the middle of the user address space, thus carving it into two. It may only take one such DLL to make it impossible to allocate 1 Gbyte, as LB 4.5.0 attempts to do.

Carl seems to be unaware of this, and is now blaming ASLR (Address Space Layout Randomization) for LB 4.5.0 failing. I'm not at all sure that ASLR can ever affect the amount of contiguous address space, but even if it can it was introduced in Windows Vista so is hardly something new. Whether it's the loading of DLLs at 'inconvenient' addresses or a side-effect of ASLR, fragmentation of the user address space is a phenomenon that any competent Windows developer should be aware of.

Carl appears to be now proposing that he should reduce the amount of requested contiguous memory from 1 Gbyte to 768 Mbytes, and whilst this would certainly help it's not a sufficiently large reduction to guarantee that it will succeed in all circumstances. Far better, in my opinion, to reduce it to 512 Mbytes or even less, or to make it configurable (as LBB does) or to make it adaptive to the amount of contiguous memory available (as BBC BASIC does).

And as for ASLR being a "weird stunt" (Carl's phrase) in fact it's a security measure designed to foil malware attacks, specifically 'buffer overflow' exploits. Another feature of Windows designed to protect your PC is DEP (Data Execution Prevention) and of course LB (and executables compiled using LB) will not run with DEP fully enabled. sad

Richard.
Re: Startup problem
Post by Richard Russell on Jun 28th, 2016, 9:38pm

I've been reading Carl's responses at the LB forum with increasing disbelief. His understanding of the basic principles of virtual memory and what governs the availability of contiguous address space seems to be very poor.

I suspect this is what comes of programming in a high-level language like SmallTalk; it isolates you too well from the underlying hardware and Operating System. Programming in assembler and (to a lesser extent) C, as I do, forces you to know how things work 'under the hood'.

The practical, and trivial, solution to the LB 4.5.0 memory allocation problem is to reduce the amount of contiguous address space requested from 1 Gbyte to, say, 256 Mbytes to be on the safe side. This would still be plenty of memory for any conceivable LB program.

But Carl seems to be resisting this solution, perhaps because he is so convinced that the problem is Microsoft's fault rather than his own (he refers to their "hackish attempts at security" and not having "made their memory manager smart enough," which are nonsense).

Richard.
Re: Startup problem
Post by RobM on Jun 28th, 2016, 11:54pm

Quote:
The practical, and trivial, solution to the LB 4.5.0 memory allocation problem is to reduce the amount of contiguous address space requested from 1 Gbyte to, say, 256 Mbytes to be on the safe side. This would still be plenty of memory for any conceivable LB program.

I never understood why he made such a large jump from 70mb (which worked fine for 99.9% of LB users) to 1gb. Even with my limited knowledge of what goes on behind the scenes in Windows I would have expected it to cause a problems.
Re: Startup problem
Post by Richard Russell on Jun 29th, 2016, 08:50am

on Jun 28th, 2016, 11:54pm, RobM wrote:
I never understood why he made such a large jump from 70mb (which worked fine for 99.9% of LB users) to 1gb. Even with my limited knowledge of what goes on behind the scenes in Windows I would have expected it to cause a problems.

For me the puzzle is not so much why Carl made such a big change in the first place (evidently he is not naturally cautious like you and me!) but why he didn't reverse it - or at least reduce it - as soon as reports of problems started to come in, which was immediately after LB 4.5.0 was released.

He seems to have used the memory allocation problem as an excuse for not releasing a Pro version of LB 4.5.0 (leaving his 'elite' users in the lurch ever since) rather than simply fixing it, which I'm assuming would have been a five-minute job of changing the amount of memory requested and recompiling LB.

But there are so many things about Carl that totally mystify me I probably shouldn't be surprised about this one.

Richard.
Re: Startup problem
Post by RobM on Jun 29th, 2016, 5:58pm

It is odd that he didn't fix or change it right away. As you say it shouldn't take long to do. Hopefully he gets it fixed faster than what it took to fix the file dialog laugh