Author |
Topic: Open reply to Carl Gundel (Read 817 times) |
|
Richard Russell
Administrator
member is offline
 
Posts: 1348
|
 |
Open reply to Carl Gundel
« Thread started on: May 23rd, 2017, 6:57pm » |
|
Carl has been posting at the Liberty BASIC Yahoo! group about the upcoming release of LB 4.5.1. I'm a member of that group, but moderated, so here is the reply I would have posted if I could:
Carl Gundel: Quote:| I did some research into this and learned that Microsoft loads certain things into specific memory locations as a security measure to prevent some malware from loading. This is very bad software design on Microsoft's part. This is unfortunate and essentially breaks their own memory API. |
|
I guess you're talking about ASLR (Address Space Layout Randomization). The problem of LB 4.5.0 failing to allocate 1 Gbyte of contiguous address space can happen whether or not ASLR is enabled. It is, as you say, caused by "very bad software design" but the software concerned is Liberty BASIC not Windows!
Right from the beginning of 32-bit Windows (i.e. Windows 95) - long before ASLR was even thought of - attempts to allocate large amounts of contiguous address space have been prone to failure. This is primarily because DLLs (both system DLLs and third-party DLLs) incorporate a 'preferred' load address and will be loaded at that address if it is available. Loading DLLs therefore fragments the address space; for example on my PC a Brother printer driver DLL is responsible for LB 4.5.0 not running.
It has therefore been the case 'forever' that competently-written Windows software should not rely on allocating large amounts of contiguous address space. For example BBC BASIC attempts to allocate 512 MBytes initially but will automatically fall back to smaller amounts if that allocation fails; 'LB Booster' allows the user to determine the size by editing the .ini file. Although reducing LB 4.5's attempted allocation from 1 Gbyte to 768 Mbytes will increase the likelihood of it succeeding, it certainly won't eliminate the problem.
Hardly anybody ever complained about LB 4.04's allocation of 70 Mbytes or so being too small. You could have increased it to, say, 128 Mbytes with no significant risk, but instead your lack of understanding of Windows fundamentals led you to increase it too much, and it is still set far too high.
Richard.
|
|
|
|
CryptoMan
New Member
member is offline
Gender: 
Posts: 46
|
|
Re: Open reply to Carl Gundel
« Reply #1 on: Jun 11th, 2017, 06:14am » |
|
Why would anyone need to allocate 1 Gb contiguous memory with LB in the first place?
I think it is absurd. What kind of application will use it?
Maybe, I am old school started with a 16 Kb IBM PC and handled serious banking systems with 1 Mb RAM, can not grasp the need for such memory.
Seriously 70 Mb was enough but say you need to make some image manipulation on RAW image files, maybe increase it to 128 Mb but 1 Gb or more can be needed for video content but why copy all file to memory?
Say you allocated 1 Gb with LB, is it fast enough to handle such huge manipulation with LB?
I agree with you.
|
|
 Logged
|
|
|
|
Richard Russell
Administrator
member is offline
Posts: 1348
|
|
Re: Open reply to Carl Gundel
« Reply #2 on: Jun 11th, 2017, 5:54pm » |
|
on Jun 11th, 2017, 06:14am, CryptoMan wrote:Why would anyone need to allocate 1 Gb contiguous memory with LB in the first place?
I think it is absurd. What kind of application will use it? |
|
I think Carl was just greedy. His lack of understanding of Windows fundamentals led him to conclude that it was OK to allocate that much contiguous memory, and he wanted to use it as a 'headline grabbing' enhancement for LB 4.5 (even if nobody actually needed it). A cynic might suggest he hoped it would distract from all the bugs LB 4.5 doesn't fix. 
Quote:| 1 Gb or more can be needed for video content but why copy all file to memory? |
|
Absolutely, and in any case even LB 4.04 can if necessary allocate huge amounts of memory using API calls (e.g. GlobalAlloc or MapViewOfFile). Arguably, LB 4.5 allocating 768 Mb or 1 Gb for itself actually makes things worse, because far less memory is now available for those API calls to grab, and a program which (say) relies on mapping a large file into memory may run successfully in LB 4.04 but not in LB 4.5.
Carl should have swallowed his pride, learned the true reason for the allocation failures (rather than trying to blame Microsoft) and reduced it to something like 128 Mbytes in LB 4.5.1.
Richard.
|
|
|
|
|
