<html>
<head>
<style>
.hmmessage P
{
margin:0px;
padding:0px
}
body.hmmessage
{
FONT-SIZE: 10pt;
FONT-FAMILY:Tahoma
}
</style>
</head>
<body class='hmmessage'> > The bad news is that now I am getting a command window<BR>
> opening up in addition to the GUI window when the program runs. <BR>
> This behavior does not occur on v4.1. <BR>
<BR>
Randy I've experimented with -gui. Just a few minutes, but I've covered all of the ground I can think of, except I only used -gui and not an m3makefile.<BR>
>From what I see, it all works as it should.<BR>
<BR>
Here is my little program:<BR>
<BR>
C:\dev2\j\m3\3>type Main.m3<BR>MODULE Main;<BR>IMPORT IO;<BR>IMPORT WinBase;<BR>
BEGIN<BR> (* IO.Put("Hello\n"); *)<BR> WinBase.Sleep(10000); (* 10 seconds *)<BR><BR><BR>
IF I uncomment out the IO.Put, and use -gui, then there is a "popup", and hello is printed there.<BR>
If I don't have the IO.Put however, no popup.<BR>
<BR>
Is anything appearing in your console window? Or it is just empty?<BR>
Are you maybe running processes from your app? Or running them from Explorer?<BR>
I am running just one Modula-3 test app, from cmd.<BR>
<BR>
It is possible that 4.1 does not bring up a console if you use stdout/stderr?<BR>
There is specific code in the current code to do this.<BR>
I don't have 4.1 handy..ok, I have 3.6.<BR>
<BR>
This appears to have been a deliberate change.<BR>
<BR>
3.6<BR>
C:\net\modula3\m3\libm3\src\os\WIN32\ProcessWin32.m3(185):PROCEDURE GetFileHandle(hd: WinDef.DWORD; ds: FileWin32.DirectionSet): File.T =<BR><BR>
PROCEDURE GetFileHandle(hd: WinDef.DWORD; ds: FileWin32.DirectionSet): File.T =<BR> VAR h := WinBase.GetStdHandle(hd);<BR> BEGIN<BR> IF (h = NIL)<BR> OR (h = LOOPHOLE (WinBase.INVALID_HANDLE_VALUE, WinDef.HANDLE)) THEN<BR> RETURN NIL;<BR> END;<BR> TRY RETURN FileWin32.New(h, ds)<BR> EXCEPT OSError.E => (* not available *)<BR> END;<BR> RETURN NIL;<BR> END GetFileHandle;<BR><BR>
<BR>
vs.<BR>
<BR>
current<BR>
<BR>
C:\dev2\cm3\m3-libs\libm3\src\os\WIN32\ProcessWin32.m3(231):PROCEDURE GetFileHandle(hd: WinDef.DWORD; ds: FileWin32.DirectionSet): File.T =<BR><BR>
PROCEDURE GetFileHandle(hd: WinDef.DWORD; ds: FileWin32.DirectionSet): File.T =<BR> VAR h := WinBase.GetStdHandle(hd);<BR> BEGIN<BR> IF (h # NIL)<BR> AND (h # LOOPHOLE (WinBase.INVALID_HANDLE_VALUE, WinDef.HANDLE)) THEN<BR> TRY RETURN FileWin32.New(h, ds)<BR> EXCEPT OSError.E => (* not available *)<BR> END;<BR> END;<BR><STRONG> (* if we can't get the standard handles, we might be a GUI program<BR> so we'll lazily allocate a console if needed. *)<BR> RETURN LazyConsole.New (hd, ds);<BR></STRONG> END GetFileHandle;<BR>
<BR>
<BR>
Ok, this change came in in the upgrade from Critical Mass 4.1 to 5.1.<BR>
4.1 being as I understand the actual one and only commercial release.<BR>
5.1 I guess being the then current but unreleated Critical Mass tree.<BR>
<BR>
<A href="http://dcvs.elegosoft.com/cgi-bin/cvsweb.cgi/cm3/m3-libs/libm3/src/os/WIN32/ProcessWin32.m3.diff?r1=1.1.1.1;r2=1.1.1.2;f=u">http://dcvs.elegosoft.com/cgi-bin/cvsweb.cgi/cm3/m3-libs/libm3/src/os/WIN32/ProcessWin32.m3.diff?r1=1.1.1.1;r2=1.1.1.2;f=u</A><BR>
<BR>
Please advise.<BR>
<BR>
Also, to double check that things are working, run link -dump -headers foo.exe | findstr /i "subsystem entry"<BR>
<BR>
GUI apps should show:<BR>
<BR>
<BR>C:\dev2\j\m3\3>link -dump -headers NT386\prog.exe | findstr /i "subsystem entry"<BR>
1C60 entry point (00401C60) _WinMainCRTStartup<BR> 2 subsystem (Windows GUI)<BR>
<BR>
console apps should show:<BR>
<BR>
C:\dev2\j\m3\3>link -dump -headers NT386\prog.exe | findstr /i "subsystem entry"<BR>
1BE1 entry point (00401BE1) _mainCRTStartup<BR> 3 subsystem (Windows CUI)<BR><BR>
C for console/commandline, G for gui/graphical.<BR>
<BR>
If that is not what you are seeing, let's delve into that.<BR>
If my test program always brings up a popup, when compiled with -gui, with the IO.Put commented out, let's delve into that.<BR>
If your console is empty, let's look into that.<BR>
If you console has output in it, well, I'm inclined to say you are seeing improved correct behavior, but we can debate it, I guess.<BR>
<BR>
- Jay<BR><BR>
<BLOCKQUOTE>
<HR id=EC_stopSpelling>
From: jayk123@hotmail.com<BR>To: rcoleburn@scires.com; m3devel@elegosoft.com<BR>Subject: FW: [M3devel] pixmap problem<BR>Date: Thu, 8 May 2008 19:21:49 +0000<BR><BR>
<META content="Microsoft SafeHTML" name=Generator>
<STYLE>
.ExternalClass .EC_hmmessage P
{padding:0px;}
.ExternalClass body.EC_hmmessage
{font-size:10pt;font-family:Tahoma;}
</STYLE>
truncated again...<BR><BR><BR><BR><BR>
<BLOCKQUOTE>
<HR id=EC_EC_stopSpelling>
From: jayk123@hotmail.com<BR>To: rcoleburn@scires.com; m3devel@elegosoft.com<BR>Subject: RE: [M3devel] pixmap problem<BR>Date: Thu, 8 May 2008 18:57:08 +0000<BR><BR>
<STYLE>
.ExternalClass .EC_hmmessage P
{padding:0px;}
.ExternalClass body.EC_hmmessage
{font-size:10pt;font-family:Tahoma;}
</STYLE>
Randy, At first very quick glance, this stuff looks ok.<BR>CM3-IDE probably doesn't really understand the config file, similar to m3cgcat's partial misunderstanding.<BR> (Which is why I keep TARGET declared in NT386* instead of just NT386.common.)<BR>PKG_USE is defined I think, but it takes a really accurate understanding of Quake to get it.<BR> <BR>The entry/subsystem stuff also seems complete but I didn't try examples yet.<BR>Sorry, didn't give this all much time yet.<BR>I did get me to look at the environment variable bug that's been sitting there forever, with a bogus fix..<BR> <BR>Can CM3-IDE default PKG_USE to CM3_ROOT + "/pkg"? Or INSTALL_ROOT + "/pkg"? Or whatever?<BR>That is what it always is, in anything that is checked in or that cminstall will give you.<BR>It takes hand editing of cm3.cfg to get anything else I think.<BR> <BR>Or CM3-IDE users can just edit the file some. Not a lot. But some.<BR>Given an incomplete understanding of the config files, probably putting in CM3-IDE wants but under if FALSE will perhaps work.<BR>Personally I wasn't impressed with Reactor... VC5 find-in-files gets me all I need. Anything besides plain text search doesn't scale..<BR> <BR> - Jay<BR>
<BLOCKQUOTE>
<HR id=EC_EC_EC_stopSpelling>
From: jayk123@hotmail.com<BR>To: rcoleburn@scires.com; m3devel@elegosoft.com<BR>Subject: RE: [M3devel] pixmap problem<BR>Date: Tue, 6 May 2008 03:38:03 +0000<BR><BR>
<STYLE>
.ExternalClass .EC_hmmessage P
{padding:0px;}
.ExternalClass body.EC_hmmessage
{font-size:10pt;font-family:Tahoma;}
</STYLE>
Randy, don't worry.<BR>Two of these problems are trivial to fix -- PKG_USE and popups.<BR>The pixmap one will need debugging.<BR> <BR> - Jay<BR><BR>
<BLOCKQUOTE>
<HR id=EC_EC_EC_EC_stopSpelling>
Date: Mon, 5 May 2008 23:28:10 -0400<BR>From: rcoleburn@scires.com<BR>To: m3devel@elegosoft.com; jayk123@hotmail.com<BR>Subject: RE: [M3devel] pixmap problem<BR><BR>
<DIV>Jay:</DIV>
<DIV> </DIV>
<DIV>Ok, I've copied your NT386 config stuff into the bin folder and I've copied NT386 to bin\cm3.cfg.</DIV>
<DIV> </DIV>
<DIV>The good news is that my -gui mode programs now link and run. The bad news is that now I am getting a command window opening up in addition to the GUI window when the program runs. This behavior does not occur on v4.1. The command window seems to be the stdout/stderr of the GUI program.</DIV>
<DIV> </DIV>
<DIV>Also, more bad news, the pixmap problem is not solved.</DIV>
<DIV> </DIV>
<DIV>And more bad news, your config stuff breaks the CM3-IDE program which needs to find certain definitions in cm3.cfg like PKG_USE, etc.</DIV>
<DIV> </DIV>
<DIV>Regards,</DIV>
<DIV>Randy<BR><BR>>>> Jay <jayk123@hotmail.com> 5/5/2008 10:47 PM >>><BR>Randy, Yes.<BR>The NT386 config files are all checked in.<BR>You can use them verbatim. You don't need cminstall, I never use it, and you shouldn't need to edit the config files at all, any edits I make, I check in, and should be usable on all machines.<BR>As long as you set %PATH%/%INCLUDE%/%LIB%.<BR>If I'm wrong, I'd like to know why and try to fix.<BR> <BR>Consider the config files just part of cm3.exe.<BR>Not generally to be changed locally. Unless, well, unless you intend to, and you should strive to make one form that is usable by all.<BR> <BR> - Jay<BR><BR><BR></DIV>
<BLOCKQUOTE>
<HR id=EC_EC_EC_EC_EC_stopSpelling>
Date: Mon, 5 May 2008 22:42:30 -0400<BR>From: rcoleburn@scires.com<BR>To: jayk123@hotmail.com<BR>Subject: RE: [M3devel] pixmap problem<BR><BR>
<DIV>Jay,</DIV>
<DIV>When you say "took the updated config file", what do you mean? Are you saying I need a different cm3.cfg file?</DIV>
<DIV>Regards,</DIV>
<DIV>Randy<BR><BR>>>> Jay <jayk123@hotmail.com> 5/5/2008 9:54 PM >>><BR>And you took the updated config file?<BR>The way you can tell is that, roughly speaking, hand.obj should be in NT386\_m3responsefile0.txt.<BR>Or _m3responsefile1.txt, or, well, somewhere.<BR>Anyway, I think I saw the attachment, I can check later..and with 4.1 as I said..<BR> <BR>I can see about making the fix not depend on config file changes...but it's not terrible asis, and I'd really like to merge more of the quake code into cm3.exe..<BR> <BR> - Jay<BR><BR></DIV>
<BLOCKQUOTE>
<HR id=EC_EC_EC_EC_EC_EC_stopSpelling>
Date: Mon, 5 May 2008 21:18:12 -0400<BR>From: rcoleburn@scires.com<BR>To: m3devel@elegosoft.com<BR>Subject: Re: [M3devel] pixmap problem<BR><BR>
<DIV>Jay:</DIV>
<DIV> </DIV>
<DIV>I've updated my sandbox via CVS and I've rebuilt everything.</DIV>
<DIV> </DIV>
<DIV>I rebuilt the TestPixmap program, but it still does not work properly when the buildstandalone() directive is used.</DIV>
<DIV> </DIV>
<DIV>Regards,</DIV>
<DIV>Randy<BR><BR>>>> Jay <jayk123@hotmail.com> 5/5/2008 7:04 PM >>><BR>Thanks. I'll look into this tonight probably, as well as with 4.1 assuming I can find my binaries and source for it (probably).<BR><BR>COULD BE the pixmap problem is something else and 4.1 also has the problem I fixed. We'll see. No need to speculate (unless I can't find my 4.1).<BR><BR> - Jay<BR><BR><BR></DIV>
<BLOCKQUOTE>
<HR>
Date: Mon, 5 May 2008 10:59:27 -0400<BR>From: rcoleburn@scires.com<BR>To: jayk123@hotmail.com<BR>CC: m3devel@elegosoft.com<BR>Subject: RE: [M3devel] pixmap problem<BR><BR>
<DIV>Jay:</DIV>
<DIV> </DIV>
<DIV>The TestPixmap.zip is attached.</DIV>
<DIV> </DIV>
<DIV>I will attempt to update all my sources and try again.</DIV>
<DIV> </DIV>
<DIV>Not sure what you mean when you say that I must use your config files or edit what I am using. Please elaborate.</DIV>
<DIV> </DIV>
<DIV>The pixmap problem does not occur on 4.1.</DIV>
<DIV> </DIV>
<DIV>Regards,</DIV>
<DIV>Randy<BR><BR>>>> Jay <jayk123@hotmail.com> 5/4/2008 11:46 AM >>><BR>Randy, Please try with /current/ source, as of this morning Sunday May 4 -- the changes are ALL in NT386.common, so you MUST use MY config files, which are checked in verbatim, or you should be able edit whatever config files you are using.<BR> <BR>(It's not really a config file issue, don't blame the general confusion people have with them.)<BR> <BR>I'll try to try later, but I don't have the source right now, gotta look on other machines, and I think it's on a machine on loan.<BR> Or send it to me again.<BR>I'd also like to know if this worked with 4.1, or with any release that offered dynamic linking to m3core.dll, on Windows.<BR> I recall a claim that it did. If today's change fixes it, I should be able to investigate 4.1.<BR>3.6 did not have such linking.<BR>If today's change does not help, well, I still plan on debugging it at some point..<BR> <BR>If you aren't current and getting so is difficult, just send the attachment again, it's easy for me to test.<BR> <BR>Thanks,<BR> - Jay<BR><BR></DIV>
<BLOCKQUOTE>
<HR id=EC_EC_EC_EC_EC_EC_EC_EC_stopSpelling>
From: jayk123@hotmail.com<BR>To: hosking@cs.purdue.edu; rcoleburn@scires.com<BR>Date: Sat, 19 Jan 2008 08:52:08 +0000<BR>CC: m3devel@elegosoft.com<BR>Subject: Re: [M3devel] pixmap problem<BR><BR>
<STYLE>
.ExternalClass .EC_hmmessage P
{padding:0px;}
.ExternalClass body.EC_hmmessage
{font-size:10pt;font-family:Tahoma;}
</STYLE>
I can repro the two different behaviors on XP.<BR>I was going to try on PPC_DARWIN but I guess Tony's info suffices.<BR> <BR>I tried rolling hand.c back to before I changed (months/year ago), since it is involved in bit twiddling, no change, phew.<BR> <BR>Debugging here is a big humungous pain.<BR>NT386 has good stacks and line numbers, but no locals or type info, I'd really sometime like to get Codeview info into those .objs...I think it is documented well enough, but still not necessarily easy, or maybe have a C generating backend partly for this reason (and to bring up more targets, using native tools), and function calls in disassembly I think don't resolve; NT386GNU can't yet build this, though it will soon, but I'm not familiar with gdb and there appears to be no type info. I'm building m3gdb right now, I don't know if it will work, I hope it has type info, and I'm not familiar with the relevant code. In gdb I struggle just to view bytes in memory, add numbers to addresses and see those, etc. I think for MY problem, I'm going to link in C code to dump the structs. There is tracing code and I enabled it, but even it crashes in Text_Length. At least MY problem crashes, hopefully near the problem, whereas your problem goes all the way through to completion with no stopping to hint where the problem is. Darn it. :) on the mock rudeness and :( on the lack of a crash.<BR> <BR>You write the bundle out and it matches, so that doesn't rule out bundles as being the problem? (darn)<BR>And bundles look pretty simple, a bundle is just a generated source file with a constant in it.<BR>Maybe newline problems? That wouldn't make sense. I just downloaded some program that might let me separately view the ppm, maybe it'll reveal something.<BR> <BR>The bad behavior has like regularly spaced solid color veritical bars a few pixels side across the whole picture, and regularly spaced vertical stripes from the correct picture alternating with that. Perhaps someone with ppm/bitmap/graphics experience has seen this behavior and it results from some common pixmap mismanagement we could look for?<BR> <BR>I have to say this is very surprising.<BR> <BR>I always wondered, and now I pretty much assume -- Modula-3 never imports/exports data in its dynamic linking, right? It alway imports/exports functions, right?<BR>On Windows, functions have an optional optimization, but data must be handled differently at compile time if it is going to be dynamically imported.<BR>For functions, if you don't apply the optimization at compile time, the linker will just generate a single instruction thunk instead.<BR> <BR>That is, given a symbol Foo, there is a symbol __imp__<FONT face="">Foo</FONT> that is a pointer to the actual foo in another .dll/.so.<BR>The loader only patches pointers, one per import if you build your .dll correctly, it doesn't patch instructions or code strewn throughout a .dll, just one contiguous array of pointers. MAYBE they don't have to be contiguous for each .dl you import from.<BR> <BR>That is, if call msvcrt!fopen, msvcrt!fclose, kernel32!Sleep, my .dll/.exe typically has an array:<BR> <BR>pointer to msvcrt!fopen<BR>pointer to msvcrt!fclose<BR>null<BR>pointer to kernel32!Sleep<BR> <BR>But perhaps kernel32.dll's pointers and msvcrt.dll's pointers need not be adjacent.<BR> <BR>So, going back, my point/question is that, if the compiler knows the function is imported, it can call through __imp__Foo instead of calling Foo.<BR>But if it calls Foo and you import Foo, the linker will create the function Foo that just jmps through __imp__Foo.<BR>That doesn't work for data though. There's no ability to intervenve like that.<BR>So for imported data, the compiler must generated a read and dereference of the pointer __imp__<FONT face="">Foo for accesses to Foo, if Foo is to be imported.</FONT><BR>Data imports may be faster when appropriate, but for this reason, I'd say they aren't worth it.<BR>And for this reason, I HOPE Modula-3 never imports/exports data.<BR> <BR>Oh, you could, for data, always reference the pointer __imp_Foo, and if non materializes, create one.<BR>However that would suck perf in order to make an uncommon case work.<BR>I hope Modula-3 doesn't do that either. :)<BR>Though I guess since this global data in question...maybe it is rare???<BR> <BR>Later,<BR> - Jay<BR><BR><BR>
<HR id=EC_EC_EC_EC_EC_EC_EC_EC_stopSpelling>
<BR>> From: hosking@cs.purdue.edu<BR>> Date: Sat, 19 Jan 2008 03:09:47 -0500<BR>> To: rcoleburn@scires.com<BR>> CC: m3devel@elegosoft.com<BR>> Subject: Re: [M3devel] pixmap problem<BR>> <BR>> Looks fine to me on I386_DARWIN.<BR>> <BR>> On Jan 19, 2008, at 12:31 AM, Randy Coleburn wrote:<BR>> <BR>> > <TestPixmap.zip><BR>> <BR><BR><BR>
<HR>
Need to know the score, the latest news, or you need your HotmailŪ-get your "fix" <A href="http://www.msnmobilefix.com/Default.aspx" target=_blank>Check it out.</A> </BLOCKQUOTE></BLOCKQUOTE></BLOCKQUOTE></BLOCKQUOTE></BLOCKQUOTE></BLOCKQUOTE></BLOCKQUOTE></BLOCKQUOTE></body>
</html>