LB Booster
« Open reply to Carl Gundel »

Welcome Guest. Please Login or Register.
Jul 26th, 2017, 10:44am


Speed up Liberty BASIC programs by up to ten times!
Compile Liberty BASIC programs to compact, standalone executables!
Overcome many of Liberty BASIC's bugs and limitations!
LB Booster Resources
LB Booster documentation
LB Booster Home Page
LB Booster technical Wiki
Just BASIC forum
LB Umbrella forum
Liberty BASIC forum (the original)

« Previous Topic | Next Topic »
Pages: 1  Notify Send Topic Print
 thread  Author  Topic: Open reply to Carl Gundel  (Read 205 times)
Richard Russell
Administrator
ImageImageImageImageImage


member is offline

Avatar




Homepage PM


Posts: 1247
xx 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.
« Last Edit: May 23rd, 2017, 7:57pm by Richard Russell » User IP Logged

CryptoMan
New Member
Image


member is offline

Avatar




PM

Gender: Male
Posts: 45
xx 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.
User IP Logged

Richard Russell
Administrator
ImageImageImageImageImage


member is offline

Avatar




Homepage PM


Posts: 1247
xx 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. rolleyes

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.
« Last Edit: Jun 11th, 2017, 11:39pm by Richard Russell » User IP Logged

aurel
New Member
Image


member is offline

Avatar




PM


Posts: 7
xx Re: Open reply to Carl Gundel
« Reply #3 on: Jul 15th, 2017, 09:05am »

First thanks on this post and i agree with you
in complete
smiley

User IP Logged

http://basicpro.mipropia.com/smf/index.php
Pages: 1  Notify Send Topic Print
« Previous Topic | Next Topic »

Donate $6.99 for 50,000 Ad-Free Pageviews!


This forum powered for FREE by Conforums ©
Sign up for your own Free Message Board today!
Terms of Service | Privacy Policy | Conforums Support | Parental Controls