[M3devel] NT386 environment variables (new NT386 snapshots)

[Randy Coleburn]

Jay:
 
Here are my results using the program you supplied:
 
1.  cm3 v4.1, VS 2005, GUI mode, get a pop-up dos window, but program crashes
 
2.  cm3 v4.1, VS 2005, console mode, program crashes
 
3.  cm3 v.d5.7.0, VS 2008 GUI mode, get a pop-up window but it disappears too fast to see any contents
 
4.  cm3 v.d5.7.0, VS 2008 console mode, program crashes
 
Regards,
Randy

>>> Jay <jayk123 at hotmail.com> 5/9/2008 3:44 AM >>>
 > these problems (pixmaps, buildstandalone, environ vars, serial i/o, etc...
 
 Ok, here is the story with environment variables.

I tested 3.6 and current, gui and console.

This is the program:

C:\dev2\j\m3\3>type src\m3makefile

import ("m3core")
import ("libm3")
m3_option ("-gui")     twiddle this line in and out with a comment
implementation ("Main")
program ("pgm")
 
C:\dev2\j\m3\3>type src\Main.m3
MODULE Main;
IMPORT IO;
IMPORT RTArgs;
 
BEGIN
(* IO.Put just crashes in 3.6 gui apps *)
  IO.Put(RTArgs.GetArg(2));
  IO.Put(RTArgs.GetEnv(2));
 
(* use this for gui apps *)
  EVAL RTArgs.GetArg(2);
  EVAL RTArgs.GetEnv(2);
END Main.

In 3.6 console apps, RTArgs.GetEnv returns garbage. That makes sense from the code.
In current console apps, GetEnv works.
In current gui apps, GetEnv access violates, or returns an invalid pointer.
  This also makes sense from the code.

Randy, does this actually work for you?
I'd be quite surprised.
I haven't tried 4.1 yet, just 3.6 and current.

I will apply an easy fix.

 - Jay

Date: Thu, 8 May 2008 16:17:37 -0400
From: rcoleburn at scires.com 
To: m3devel at elegosoft.com 
Subject: Re: [M3devel] new NT386 snapshots

Jay:
 
I have both console and gui programs built using 4.1 that do pull stuff out of the environment.  I've not noticed any problems with either mode.
 
>From my perspective, the old 4.1 seems more reliable than the current system in a number of respects.  I have a new project with a hard deadline that I would like to use the new cm3 system for, but until these problems (pixmaps, buildstandalone, environ vars, serial i/o, etc.) can be resolved, I'm going to keep using 4.1 for my production work.
 
Regards,
Randy

>>> Jay <jayk123 at hotmail.com> 5/8/2008 2:46 PM >>>
http://modula3.elegosoft.com/cm3/uploaded-archives/ 
 
http://modula3.elegosoft.com/cm3/uploaded-archives/cm3-std-WIN32-NT386-d5.7.0.zip 
http://modula3.elegosoft.com/cm3/uploaded-archives/cm3-min-WIN32-NT386-d5.7.0.zip 
http://modula3.elegosoft.com/cm3/uploaded-archives/cm3-std-WIN32-NT386-d5.7.0-symbols.zip 
 
These should have:
  latest quake extensions 
  set relation fixes 
  other set fixes revealed through dynamic linking of one regression test 
  hypothetical ability to cross-build to AMD64_LINUX, AMD64_DARWIN  
  one jmpbuf size for all NT386 configurations (NT386, NT386GNU, NT386MINGNU) 
 
Built with Visual C++ 9.0 Express, so you'll want:
http://www.microsoft.com/downloads/details.aspx?familyid=9B2DA534-3E03-4391-8A4D-074B9F2BC1BF&displaylang=en 
 
 
Still more work to do though, e.g. assertion failures in unit tests, pixmap..
 
Fuller disclosure:
Something is leaking memory on my system such that "everything" starts "failing" and I have to reboot.
This isn't Modula-3 related.
Hopefully these files aren't damaged as a result.
Must be some buggy driver or something..
 
Aside:
 The environment variable thingy has been bugging me a long time and I finally looked deeper at it.
It appears broken in CM3 4.x. I didn't check 3.x yet.
I'm still mulling a fix, and haven't run a repro of the break, but it's not a big deal either way.
Basically console apps use main that takes char** and gui apps use WinMain that doesn't get environment variables but the generated code calls GetEvironmentStrings() which returns null separated strings.
Must be that hardly anyone uses environment variables in Modula-3 on Win32 for this to have lingered so long, at least gui apps.
 
 - Jay
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20080510/500567a1/attachment-0002.html>