by Contributed | Sep 23, 2020 | Uncategorized
This article is contributed. See the original author and article here.
Yesterday, Brad Anderson announced that App Assure now includes Windows 10 on ARM64 personal computers (PCs). App Assure launched two years ago to provide customers with the confidence that your apps will work on Windows 10 and Office 365 (now Microsoft 365 Apps). If customers run into issues, our App Assure engineers help you to fix those issues. This is part of the FastTrack benefit, which comes at no additional cost with your eligible Microsoft 365 and Windows 10 plans of 150+ licenses.
Last year, App Assure expanded to include Windows Virtual Desktop (WVD) and Microsoft Edge, and now, we’re excited to provide application compatibility assistance for Windows 10 on ARM64 PCs. Originally, the desktop version of Windows 10 only ran on PCs powered by processors developed by Intel and AMD (x86 or x64) because they were optimized for performance. In contrast, ARM processors are often used in mobile devices where size, power consumption, and speed matter. In addition to Microsoft’s Surface Pro X, other manufacturers have started releasing ARM-based PCs, often built with Qualcomm’s Snapdragon chips. These devices have beneficial[i] features including all day battery life and support for mobile data networks.
An emulation layer built into Windows 10 on ARM enables the rich ecosystem of x86 Win32 applications to run unmodified. This means most 32-bit apps will install and run on ARM64 PCs without issue. However, we know that some of you may still have concerns about software compatibility, especially for those applications with kernel mode drivers (such as some third-party antivirus software) since they interact with core operating system components, which cannot be emulated.
For Windows 10 on ARM64 devices running version 1709 and later, App Assure is here to help. Our application compatibility promise is that Microsoft is committed to helping you ensure your apps work on the latest versions of our software. If you encounter issues, we’ll help you resolve them at no additional cost. Please note that there are a few instances where we have limitations: apps that rely on software drivers that aren’t compatible with ARM64 devices, use OpenGL or OpenCL, or are only available in 64-bit (x64) [1].
How do we keep this promise?
If you do encounter an app compat issue on an ARM64 PC, App Assure engineers will work with you to help you resolve the issue. Our experts will:
- Help you troubleshoot and identify a root cause
- Provide guidance to help you remediate the application compatibility issue
- Engage with third-party independent software vendors (ISVs) on your behalf to remediate some part of their app, so that it’s functional on the most modern version of our products
- Work with Microsoft product engineering teams to fix product bugs
We’re committed to not only helping you find a remediation for your app compat issue, but also going the extra mile by working with our engineering teams to find and fix the root cause, thus continuing to improve our products.
Do I have an ARM PC?
The following are some of the available or announced ARM64 PCs (as of September 2020):
- Surface Pro X
- Samsung Galaxy Book S
- Samsung Galaxy Book2
- Asus NovaGo
- HP Envy x2
- Lenovo Flex 5G
- Lenovo Yoga C630 WOS
- Lenovo Miix 630
- Acer Spin 7
- Huawei Matebook E (2019); only available in China
How do I get started with App Assure?
App Assure is available at no additional cost for eligible Microsoft 365 and Windows 10 plans of 150+ licenses. Visit aka.ms/AppAssureRequest to submit your request for assistance which will be assigned to your dedicated App Assure Manager. To learn more about App Assure compatibility assistance visit here. You can also watch the 2020 Microsoft Ignite Skilling Session on App Assure here.
[i] https://docs.microsoft.com/en-us/windows/uwp/porting/apps-on-arm
by Contributed | Sep 23, 2020 | Uncategorized
This article is contributed. See the original author and article here.
Introduction
Application scalability is very important for business success. Companies spend millions in ideation, software development, testing, and deployment to provide value to their customers. These customers then will use the app, but not in a regular basis. We might expect spikes during holidays, weekends, during the morning, etc.… In these cases, if the app is not ready to scale, then much of the investment might be lost.
In this workshop we will see the different solutions to scale applications in Kubernetes. We will explore 3 different solutions: Pods scalability, Node scalability and the Virtual Node. We’ll explore these options with a complete demo for each solution.
Setting up the environment
We will need a Kubernetes cluster; we are using Azure Kubernetes Service (AKS) which is a managed k8s cluster.
$ # Create an AKS cluster and a resource group
$ $aksRg="aks-demo"
$ $aksName="aks-demo"
$ #create a Resource Group
$ az group create -n $aksRg -l westeurope
$ # Create an AKS cluster with 2 nodes
$ az aks create -g $aksRg `
-n $aksName `
--node-count 2
$ # Connect to the AKS cluster
$ az aks get-credentials -g $aksRg -n $aksName
Then, we need to deploy a sample PHP application into k8s. This app will do some heavy calculations. The following yaml file creates a Deployment that will create a single Pod. And exposes it using a service object.
# deploy-svc.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
name: php-apache
spec:
selector:
matchLabels:
run: php-apache
replicas: 1
template:
metadata:
labels:
run: php-apache
spec:
containers:
- name: php-apache
image: k8s.gcr.io/hpa-example
ports:
- containerPort: 80
resources:
limits:
cpu: 500m
requests:
cpu: 200m
---
apiVersion: v1
kind: Service
metadata:
name: php-apache
labels:
run: php-apache
spec:
ports:
- port: 80
selector:
run: php-apache
Let’s deploy the deployment and service into Kubernetes and check the deployed pod.
$ kubectl apply -f deploy-svc.yaml
deployment.apps/php-apache created
service/php-apache created
$
$ kubectl get pods
NAME READY STATUS RESTARTS AGE
php-apache-79544c9bd9-vlwjp 1/1 Running 0 15s
- Pod scalability
Now, we have one single Pod deployed. Suppose we have lots of load/requests for one single pod and we need to scale out. Kubernetes have a built-in support for scalability in its core features. This could be done with 2 options. The first option is manually setting a hard number of replicas for the pods in the YAML file or by command line. The second option uses HPA. Next, we’ll explore these options.
The Deployment we created earlier have replicas set to 1. We can change that using the kubectl scale command as in the following:
# Note 1 single Pod is deployed as per Deployment/Replicas
$ kubectl get pods
NAME READY STATUS RESTARTS AGE
php-apache-79544c9bd9-vlwjp 1/1 Running 0 13m
$
$ # Manually scale Pods
$ kubectl scale --replicas=2 deployment/php-apache
deployment.apps/php-apache scaled
$
$ # Note 2 Pods are now deployed as per Deployment/Replicas
$ kubectl get pods
NAME READY STATUS RESTARTS AGE
php-apache-79544c9bd9-ggc77 1/1 Running 0 55s
php-apache-79544c9bd9-vlwjp 1/1 Running 0 14m
Manual scalability is just fine for two reasons. First, if we know ahead of time when the load will go up or down. Second, if it is fine to handle it manually. But, in real life, the spike can arrive at any moment. Thus, we should automate how the system will react.
- Pod auto-scalability using HPA
Scalability is one of the great features in Kubernetes. It could be achieved by scale out or scale in. This means increasing or decreasing the number of instances of a Pod. Kubernetes will manage how the load balancing between these Pods. This scalability could be automated by using HorizontalPodAutoscaler (HPA). The HPA will watch for CPU and Memory utilization metrics and decide to scale out or in. The metrics are exposed by the Metrics Server (https://github.com/kubernetes/metrics).
Let’s analyse the following example. This HPA will watch for the average CPU utilization for the Pods of the stated Deployment. The CPU average utilization should be around (and not exactly) 50%. When that is above 50%, the HPA will increase by one the number of replicas for the Deployment. If the average still above 50%, the HPA will increment the replicas again. The same process will be repeated until we either reach the 50% or the maximum number of allowed replicas (maxReplicas).
Scale in will be triggered when average CPU utilization is below 50%. Thus, the HPA will decrease the number of replicas until it reaches the targeted utilization or minimum number of allowed replicas (minReplicas).
The HPA will override the number of replicas stated in the Deployment configuration (replicas: 1) in respect to minReplicas: 3.
# hpa.yaml
apiVersion: autoscaling/v2beta2
kind: HorizontalPodAutoscaler
metadata:
name: php-apache
spec:
minReplicas: 3
maxReplicas: 10
scaleTargetRef:
apiVersion: apps/v1
kind: Deployment
name: php-apache
metrics:
- type: Resource
resource:
name: cpu
target:
type: Utilization
averageUtilization: 50
This HPA is based on CPU average utilization. But we can also use Memory utilization. These metrics are built in. In addition to that, we can extend these metrics by implementing the external or custom metrics server API. There are many implementations to get metrics from Prometheus (https://github.com/DirectXMan12/k8s-prometheus-adapter/blob/master/docs/walkthrough.md) or Azure Application Insights and Azure Monitor (https://github.com/Azure/azure-k8s-metrics-adapter). This enables scenarios like scalability based on Queue length, number of HTTP requests per second, etc.…
Let’s now deploy the HPA and check the created Pods.
$ # Create the HorizontalPodAutoscaler (HPA)
$ kubectl apply -f hpa.yaml
horizontalpodautoscaler.autoscaling/php-apache created
$
$ # Note 3 Pods are now deployed as per HPA minReplicas
$ kubectl get pods
NAME READY STATUS RESTARTS AGE
php-apache-79544c9bd9-ggc77 1/1 Running 0 4m33s
php-apache-79544c9bd9-vlwjp 1/1 Running 0 18m
php-apache-79544c9bd9-zmffh 1/1 Running 0 63s
$
$ # Check the current status of autoscaler
$ kubectl get hpa
NAME REFERENCE TARGETS MINPODS MAXPODS REPLICAS AGE
php-apache Deployment/php-apache 0%/50% 3 10 3 2m39s
To test the HPA, we will increase the CPU utilization for the Pods. To do that, we will create 10 Pods that will send infinite HTTP/GET requests to the application Pods by using the script: ‘while true; do wget -q -O- http://php-apache; done’. The file have is the following content:
# load-generator-deploy.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
name: load-generator
spec:
selector:
matchLabels:
run: load-generator
replicas: 2
template:
metadata:
labels:
run: load-generator
spec:
containers:
- name: load-generator
image: busybox
args: [/bin/sh, -c, 'while true; do wget -q -O- http://php-apache; done']
Let’s deploy the testing Deployment into Kubernetes. And after a few seconds we check the created Pods and the HPA status. Note we have now 10 instances of the application Pod created by the HPA.
$ kubectl apply -f load-generator-deploy.yaml
deployment.apps/load-generator configured
$ # Few seconds later
$ kubectl get pods
NAME READY STATUS RESTARTS AGE
load-generator-6d74bb99d5-6njgd 1/1 Running 0 9m27s
load-generator-6d74bb99d5-qn8pt 1/1 Running 0 9m27s
php-apache-79544c9bd9-2clfz 1/1 Running 0 20s
php-apache-79544c9bd9-925qp 1/1 Running 0 2m17s
php-apache-79544c9bd9-fl9hp 1/1 Running 0 5s
php-apache-79544c9bd9-hsn25 1/1 Running 0 5s
php-apache-79544c9bd9-kzscp 1/1 Running 0 5s
php-apache-79544c9bd9-lmxv7 1/1 Running 0 2m7s
php-apache-79544c9bd9-pwj5d 1/1 Running 0 20s
php-apache-79544c9bd9-r5487 1/1 Running 0 20s
php-apache-79544c9bd9-x59wz 1/1 Running 0 2m7s
php-apache-79544c9bd9-x9ptv 1/1 Running 0 5s
$ kubectl get hpa
NAME REFERENCE TARGETS MINPODS MAXPODS REPLICAS AGE
php-apache Deployment/php-apache 58%/50% 3 10 10 17m
This was how to scale an application on the Pod level. Next, we’ll demo scalability on the VM or Node level.
- Cluster node scalability
Scaling out the number of Pods is useful and efficient. But it is limited by the capacity available for the cluster. To solve this problem, AKS has a nice feature to scale out and scale in based on the number of VM or Node instances. This will add capacity to the cluster allowing for even more Pod scalability.
Like with Pods scalability, AKS can scale either manually or automatically. Let’s explore these options in the following sections.
- Cluster node manual scalability
We have created the cluster with only 2 nodes. But we can increase or decrease that value at any time. In this demo we’ll set the number of instances to 3 and we should see a third node attached to the cluster in a few minutes. This could be done using the Azure portal:

And here is how to do that using the command line:
$ az aks scale `
--resource-group $aksRg `
--name $aksName `
--node-count 3
$ kubectl get nodes
NAME STATUS ROLES AGE VERSION
aks-agentpool-51725664-vmss000000 Ready agent 32h v1.17.7
aks-agentpool-51725664-vmss000001 Ready agent 32h v1.17.7
aks-agentpool-51725664-vmss00000d Ready agent 8m42s v1.17.7
Note here we are using the Azure CLI instead of the kubectl. That is because the cluster scalability is implemented by the cloud provider and not by Kubernetes itself.
Manual scalability is fine for some cases. But in real life, we need to be proactive. That is why we can automate this task. The next section will show you how.
- Cluster node auto-scalability
AKS have a built in API that is surveilling the Scheduler API for any Pods that could not be scheduled due to cluster capacity or due to maximum number of allowed Pods per Node. And it will talk to the Azure ARM to provision and attach a new VM/Node to the cluster. The same process will run in a loop until it reaches the maximum number of allowed instances.
When the load goes down and Pods instances will be decreased, the VMs will be removed progressively in few minutes.
To demo how this works, we’ll increase the load on the application Pods by increasing the replicas of the load generator Pods to 100. And we will increase the maxReplicas of the HPA to 1000. Let’s edit the values in the YAML configuration files then deploy the changes.
$ kubectl apply -f load-generator-deploy.yaml
deployment.apps/load-generator configured
$ kubectl apply -f hpa.yaml
horizontalpodautoscaler.autoscaling/php-apache configured
$ kubectl top nodes
NAME CPU(cores) CPU% MEMORY(bytes) MEMORY%
aks-agentpool-51725664-vmss000000 1769m 93% 1786Mi 39%
aks-agentpool-51725664-vmss000001 1945m 102% 1780Mi 39%
aks-agentpool-51725664-vmss00000d 2010m 105% 1400Mi 30%
$ kubectl get hpa
NAME REFERENCE TARGETS MINPODS MAXPODS REPLICAS AGE
php-apache Deployment/php-apache 116%/50% 3 1000 50 86m
$ kubectl get pods
NAME READY STATUS RESTARTS AGE
load-generator-6d74bb99d5-2gjtn 1/1 Running 0 3m8s
<OTHER_PODS_REMOVED_FOR_BRIEVETY>
php-apache-79544c9bd9-xdlg7 1/1 Running 0 101s
php-apache-79544c9bd9-zj66j 0/1 Pending 0 101s
<OTHER_PODS_REMOVED_FOR_BRIEVETY>
Many Pods should be created to handle all the load, but that was stopped by the cluster capacity. Note how the Nodes CPU utilization is nearly 100%. And we still have Pods in Pending state. So, let’s leverage the AKS auto scalability.
We can do that using the Azure Portal as following:

And we can also configure scalability using the command line. In the following example we are enabling cluster autoscaler for AKS and we are setting min and max nodes count.
$ az aks nodepool update `
--resource-group $aksRg `
--cluster-name $aksName `
--name agentpool `
--enable-cluster-autoscaler `
--min-count 3 `
--max-count 10
$ # After few (5) minutes
$ kubectl get nodes
NAME STATUS ROLES AGE VERSION
aks-agentpool-51725664-vmss000000 Ready agent 34h v1.17.7
aks-agentpool-51725664-vmss000001 Ready agent 34h v1.17.7
aks-agentpool-51725664-vmss00000d Ready agent 125m v1.17.7
aks-agentpool-51725664-vmss00000e Ready agent 11m v1.17.7
aks-agentpool-51725664-vmss00000f Ready agent 10m v1.17.7
aks-agentpool-51725664-vmss00000g Ready agent 11m v1.17.7
aks-agentpool-51725664-vmss00000h Ready agent 10m v1.17.7
aks-agentpool-51725664-vmss00000i Ready agent 6m17s v1.17.7
aks-agentpool-51725664-vmss00000j Ready agent 6m32s v1.17.7
aks-agentpool-51725664-vmss00000k Ready agent 6m18s v1.17.7
$ kubectl get hpa
NAME REFERENCE TARGETS MINPODS MAXPODS REPLICAS AGE
php-apache Deployment/php-apache 102%/50% 3 1000 144 3h1m
Note that now we are running 10 Nodes in the AKS cluster because we have lots of Pods to be scheduled and we have set the maximum number to 10.
The HPA shows that the average CPU utilization is above the target. It needs to create even more Pods and Nodes. So, we can set the –max-count to a higher number like 100. In some extreme scenarios this might not be enough. A simple solution to this would be scaling up the VMs in the Node Pool.
- Virtual Node
Cluster autoscaler is a great feature to manage scalability. The Nodes will be ready in typically 2 to 5 minutes before the Pods could be scheduled. In some scenarios, these few minutes are like eternity. We need a faster solution for scalability. Here is where the Virtual Node comes in to play. The Virtual Node can schedule these Pods in just a few seconds.
The Virtual Node uses the Azure Container Instance (ACI) which is the Azure offering for Serverless Containers. The promise of ACI is that it can run a high number of containers in just few seconds without worrying on the infrastructure behind. Virtual Node extends AKS capacity with ACI.
The integration could be achieved using the Azure portal as following:

We can also set it up using the command line as performed in this link: https://docs.microsoft.com/en-us/azure/aks/virtual-nodes-cli.
After the creation of the cluster with 3 VMs and the Virtual Node enabled, we can see that there is a 4th Node named virtual-node-aci-linux. As the name states, it is a virtual node. It is not a VM. It is a connection to ACI, attached to the cluster as a Node that have ‘unlimited’ capacity.
$ kubectl get nodes
NAME STATUS ROLES AGE VERSION
aks-agentpool-10295500-vmss000000 Ready agent 79m v1.17.7
aks-agentpool-10295500-vmss000001 Ready agent 80m v1.17.7
aks-agentpool-10295500-vmss000002 Ready agent 79m v1.17.7
virtual-node-aci-linux Ready agent 43m v1.14.3-vk-azure-aci-v1.2
$ kubectl top nodes
NAME CPU(cores) CPU% MEMORY(bytes) MEMORY%
aks-agentpool-10295500-vmss000000 134m 7% 982Mi 21%
aks-agentpool-10295500-vmss000001 83m 4% 1115Mi 24%
aks-agentpool-10295500-vmss000002 52m 2% 913Mi 20%
virtual-node-aci-linux <unknown> <unknown> <unknown> <unknown>
We can schedule an application on the ACI by adding nodeSelector and tolerations. Here is an example file:
# virtual-node.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
name: aci-helloworld
spec:
replicas: 1
selector:
matchLabels:
app: aci-helloworld
template:
metadata:
labels:
app: aci-helloworld
spec:
containers:
- name: aci-helloworld
image: microsoft/aci-helloworld
ports:
- containerPort: 80
nodeSelector:
kubernetes.io/role: agent
beta.kubernetes.io/os: linux
type: virtual-kubelet
tolerations:
- key: virtual-kubelet.io/provider
operator: Exists
A full tutorial on how to work with Virtual Node is available in the following link:
docs.microsoft.com/en-us/azure/aks/virtual-nodes-portal.
Conclusion
AKS brings many options for application scalability that can work together in order to manage application scalability.
Disclaimer
The sample scripts are not supported under any Microsoft standard support program or service. The sample scripts are provided AS IS without warranty of any kind. Microsoft further disclaims all implied warranties including, without limitation, any implied warranties of merchantability or of fitness for a particular purpose. The entire risk arising out of the use or performance of the sample scripts and documentation remains with you. In no event shall Microsoft, its authors, or anyone else involved in the creation, production, or delivery of the scripts be liable for any damages whatsoever (including, without limitation, damages for loss of business profits, business interruption, loss of business information, or other pecuniary loss) arising out of the use of or inability to use the sample scripts or documentation, even if Microsoft has been advised of the possibility of such damages.
by Contributed | Sep 23, 2020 | Uncategorized
This article is contributed. See the original author and article here.
Recently we received such kind of issue that, when you simply just open a connection to SQL Server, you can see there was DTC transactions enlisted.
However, this only happened for the SQLOLEDB drivers, the SQL Native Client doesn’t have same behavior.
The minimum reproduce code :
using System;
using System.Collections.Generic;
using System.Data.Common;
using System.Linq;
using System.Text;
using System.Threading.Tasks;
using System.Transactions;
using static System.Console;
using System.Data.SqlClient;
namespace DTCTest
{
class Program
{
const string connStrGoodOleDB = “Provider=SQLOLEDB;DataTypeCompatibility=80;SERVER=MYTESTLAB;UID=testlogin;” +
“PWD=Password01!;APP=SQLOLEDBAPP;WSID=;DATABASE=TEST”;
private static object writer;
public static DbProviderFactory GetOleDbFactory()
{
return System.Data.OleDb.OleDbFactory.Instance;
}
static void Main(string[] args)
{
using (TransactionScope scope = new TransactionScope())
{
using (DbConnection connection = GetOleDbFactory().CreateConnection())
{
connection.ConnectionString = connStrGoodOleDB;
connection.Open();
scope.Complete();
}
}
WriteLine(“Complete”);
ReadKey();
return;
}
}
}
As you can see the above code only opened a connection, but in SQL Server profile trace, it showed I have DTCTransaction for SQLOLEDBAPP

Then I collected process monitor, and checked the stack of the whole process, found it was due to the System.Data.Oledb.OledbConnections, in the Open() function, it will check several condition, if meet, then it will automatically Enlist the transaction, and finally went to the DTC transactions related call.
And one of the conditions check was OLEDB Services, so I searched for it and found we already had a document noted this issue:
https://docs.microsoft.com/en-us/dotnet/framework/data/adonet/distributed-transactions
“You can disable auto-enlistment in existing transactions by specifying Enlist=false as a connection string parameter for a SqlConnection.ConnectionString, or OLE DB Services=-7 as a connection string parameter for an OleDbConnection.ConnectionString. “
This is also notified in below doc
https://docs.microsoft.com/en-us/sql/relational-databases/clr-integration-data-access-transactions/transaction-promotion?view=sql-server-ver15
You may not notice this connection string parameter, since it was not noted in the connection string part. So the solution is easy, just change my connection string as below you will get it resolved
const string connStrGoodOleDB = “Provider=SQLOLEDB;DataTypeCompatibility=80;SERVER=MYTESTLAB;UID=testlogin;OLE DB Services=-7;” +
“PWD=Password01!;APP=SQLOLEDBAPP;WSID=;DATABASE=TEST”;
by Contributed | Sep 23, 2020 | Uncategorized
This article is contributed. See the original author and article here.
Today, I’d like to introduce current status of Small Basic Online. At first, I will introduce fixed issues this year. Second, I’ll tell what is the difference between Small Basic Online (SBO) and Small Basic Desktop (SBD). At last, I will show some ideas to write in SBO.
Fixed issues 2020 in SBO
Following issues have been fixed this year. SBO issues are managed in GitHub.
- #152 Array index is not case insensitive.
- #150 Array entry never removed
- #134 Level 2 Tutorial Should Work (same as #106 and #112)
- #133 Level 1 Tutorial should work
- #129 Some of spaces will be lost in text literals
- #127 Page does not load on Mac+Safari
- #126 Default of FontBold is “False”
- #122 TextWindow.ReadNumber Doesn’t allow negative or decimal numbers
- #121 Text.Append does not append all printable character strings
- #112 GraphicsWindow.KeyDown event never be called
- #107 Turtle appears not on the trailing line on Chrome & Edge browsers
- #106 GraphicsWindow.LastKey always return null
- #58 GraphicsWindow.DrawImage doesn’t show the image
- #14 Turtle graphic missing on Edge browser
Changes in SBO
There are many changes in SBO from SBD. SBO is still beta. So, some may be fixed but some will remain as the difference.
New features
- Most important point is SBO allows us to program with only browser such as Edge and Chrome. This means SBO runs in not only Windows but other operating systems.
- 11 new features (Libraries Pane, Debug Mode, Updated Sample Program, New Icon Designs, Advanced Error Handling, Auto Filling, Hover Hints, Save & Open, TXT File Format, Open Source on GitHub, Double Display) are described in Ed’s “NEW UPDATES: Small Basic Website 2.2 & Small Basic Online 1.0“.
- Error messages are detailed in here.
- Shortcuts for keyboard are detailed in here.
Extensions cannot be used
Extensions such as Kinect for Small Basic and LitDev cannot be used.
Initial value of variable
The initial value of the variable is “”. But reference to the variable without initializing causes compile error in SBD, while no error in SBO.
Array initialization
In SBD, Not = “False = True; True = False;” could initialize the array Not, but in SBO, the variable Not simply contains the above string.
Specifying transparent color
In Small Basic v1.2, the alpha value for opacity was specified as “#aarrggbb”, but in SBO v1.0 it becomes “#rrggbbaa”.
Features not implemented
The following functions cannot be implemented in SBO (online). Writing in code will result in a syntax error of The library member’ObjXXX.MbrXXX’ cannot be used in the online editor. Please download the desktop editor to use it..
- File.AppendContents()
- File.CopyFile()
- File.CreateDirectory()
- File.DeleteFile()
- File.DeleteDirectory()
- File.GetDirectories()
- File.GetFiles()
- File.GetTemporaryFilePath()
- File.InsertLine()
- File.LastError
- File.ReadContents()
- File.ReadLine()
- File.WriteContents()
- File.WriteLine()
- ImageList.LoadImage()
The following features are not yet implemented in SBO v1.0. I can’t press the button.
The following features are not yet implemented in SBO v1.0. Writing in code results in a syntax error of The library member’ObjXXX.MbrXXX’ was available in older versions only, and has not been made available to this version yet..
- Desktop.Height
- Desktop.SetWallPaper()
- Desktop.Width
- Dictionary.GetDefinition()
- Dictionary.GetDefinitionEnglishToEnglish()
- Dictionary.GetDefinitionEnglishToFrench()
- Dictionary.GetDefinitionEnglishToGerman()
- Dictionary.GetDefinitionEnglishToItalian()
- Dictionary.GetDefinitionEnglishToJapanese()
- Dictionary.GetDefinitionEnglishToKorean()
- Dictionary.GetDefinitionEnglishToSimplifiedChinese()
- Dictionary.GetDefinitionEnglishToTraditionalChinese()
- Dictionary.GetDefinitionFrenchToEnglish()
- Dictionary.GetDefinitionGermanToEnglish()
- Dictionary.GetDefinitionItalianToEnglish()
- Dictionary.GetDefinitionJapaneseToEnglish()
- Dictionary.GetDefinitionKoreanToEnglish()
- Dictionary.GetDefinitionSimplifiedChineseToEnglish()
- Dictionary.GetDefinitionTraditionalChineseToEnglish()
- File.GetSettingsFilePath()
- File.ReadLine()
- File.WriteLine()
- Flickr.GetPictureOfMoment()
- Flickr.GetRandomPicture()
- Dictionary.GetDefinition()
- GraphicsWindow.CanResize
- GraphicsWindow.Left
- GraphicsWindow.Title
- GraphicsWindow.Top
- Program.ArgumentCount
- Program.Directory
- Program.GetArgument()
- TextWindow.CursorLeft
- TextWindow.CursorTop
- TextWindow.Left
- TextWindow.Pause()
- TextWindow.Title
- TextWindow.Top
Fonts
SBO has only Arial (Helvetica), Consolas, Courier New (Courier), Roboto and Times New Roman (Times). Details are described here.
Read-only GraphicsWindow size
The following properties are now read-only in SBO v1.0. Attempting to assign a value results in a syntax error Property’ObjXXX.PrpXXX’ cannot be assigned to. It is ready only..
- GraphicsWindow.Width
- GraphicsWindow.Height
Shapes size
When I made a square with Shapes.AddRectangle (100, 100), it was 100 x 100 pixels in size, including the thickness of the pen. On the other hand, when it was made with GraphicsWindow.DrawRectangle (10, 10, 100, 100), it was larger by the thickness of the pen. In SBO, the latter is unified, and if the pen thickness is 2 pixels, both will draw a square of 102 x 102 pixels.
Turtle design
The design of the turtle has changed. Especially the size has increased.
Turtle trails
The turtle trails are the same as Shapes in SBD, and the one created later was displayed in the foreground, but in SBO, the turtle trails are always in front of Shapes.
New programming style
Based on the above changes, I would like to explain the points about programming in the new Small Basic.
Make your own title
Neither GraphicsWindow.Title nor TextWindow.Title can be changed, so if you want to display the title, use Shapes.AddText, TextWindow.WriteLine, etc. to display it in the window.
Sample program XMC184-3 below has own title.

Ingenuity that does not depend on window size
There is a concept of responsive design so that the homepage can support devices of various sizes. Since SBO cannot specify GraphicsWindow.Width or GraphicsWindow.Height and is affected by the window size of the browser, it is a good idea to adopt the idea of responsive design. Specifically, it monitors GraphicsWindow.Width and GraphicsWindow.Height so that it will be repositioned on the screen when it changes.
Following program CVF012 will run in both SBO and SBD.

Conclusion
This time, as far as I know, I wrote about the changes in SBO and new programming styles based on it, but I will continue testing SBO and write a lot of programs for SBO from now on, so I will update this article as needed. Thanks.
by Contributed | Sep 22, 2020 | Uncategorized
This article is contributed. See the original author and article here.
Earlier this year, we did a survey to find out how IT departments are being affected by the COVID-19 outbreak, besides the obvious effect of organizations shifting to a remote workforce. 2/3 of respondents told us that their IT budget was decreasing. Yet at the same time, years of digital transformation are taking place in a timespan of months. Many organizations also told us that they see an opportunity to consolidate onto Microsoft products; but it’s difficult to find the time to plan these moves. They told us that their time is split between many things today: managing their tenant, providing end-user support, troubleshooting and resolving issues, managing change, and discovering features.
In a brand-new video, Karissa Larson, a Senior Program Manager on the Microsoft 365 admin center team, talks about how you can improve IT efficiency and agility and maintain visibility through delegation. For example, you can empower users by enabling features such as self-service password reset (SSPR). We’ve been promoting SSPR for a while because we know it saves time and money for every organization that enables it. In fact, it can potentially save your organization a lot of time and money. That’s just one form of delegation that makes an admin’s life easier.
In addition to delegation, we’re focused on reducing the amount of time it takes you to perform every day and not so everyday actions. You told us that you spend a lot of time in the Microsoft 365 admin center looking for things instead of doing things. So we built a whole new search experience that shows you not just new results such as navigation items in the admin center, but also relevant and recommended documentation related to your search. Karissa describes the new search experience and gives a look at what’s coming for search by the end of 2020. Karissa also talks about the work we’re doing to enable you to monitor VIP, or priority accounts, and to help you with domain and DNS records management.
Flexibility is all about seamless integration with tools you use today. Karissa describes integrations that provide you with quick admin access across Azure, Teams, and Exchange through Microsoft Cloud Shell, the ability to sync message center posts to Microsoft Planner, and service incident integration with ServiceNow.
I don’t want to steal any thunder from Karissa and team, so watch the video, which is packed with demos on everything I’ve mentioned. Then, complete our survey and give us feedback and help us prioritize our work. You can also register your interest in joining a virtual roundtable session that will take place in October.
Recent Comments