From: Aleksei Guzev <aleksei.guzev@...>
Date: 2001-10-05T22:51:53+09:00
Subject: [ruby-talk:22128] Re: The Windows question still remains...



# -----Original Message-----
# From: Martin Kahlert [mailto:martin.kahlert@infineon.com] 
# Sent: 5 ??????? 2001 ?. 15:52
# To: ruby-talk ML
# Subject: [ruby-talk:22126] Re: The Windows question still remains...
# 
# 
# Hi,
# 
# On Fri, Oct 05, 2001 at 04:22:17PM +0900, Aleksei Guzev wrote:
# > Demanding binary compatibility will deny corssplatformness, 
# because no 
# > one knows surely what kind of processor do I use ;) If all 
# of you are 
# > speaking of binary compatibility I would leave the discussion...
# 
# Note: This thread contains Windows in the subject line.
# So crossplatfomness is not an issue here. (Or is Windows 
# crossplatform?) If you develop an extension, which is 
# crossplatform, then it should be compilable on e.g. Unix, 
# too. So avoid all Vendor extensions for example noreturn and 
# also the infamous declspec stuff or at least use defines in 
# the sources. If you develop a Windows extension (e.g. 
# OLE,...) it will work on Windows i gues that 99.9999999% of 
# your extension's users will not have a compiler at all. So on 
# Windows, binary compatibility is an issue. We should try hard, that:
# - The ruby core compiles cleanly on VC++ and Borland and mingw and ...
# - This core ruby should be able to run some sort of common 
# ruby scripts
# - The produced ruby executable can load foreign binary 
# extension libs downloadable
#   from RAA. Thus they may not rely on other vendors DLLs because of
#   Windows's strange DLL handling and they must not rely on 
# any Compiler
#   specific initialization routines only provided by the 
# compiler used for
#   your extension. Thus you are left with that, a common 
# Windows system 
#   provides.
# 
# The only source code problem i see is the availability of up 
# to date API headers for the compilers.
# 


But why they discuss cygwin or mingw. While there is no need of
portability there was no need of POSIX etc. I use mswin Ruby without
cygwin or mingw installed on computer. This works fine. Moreover I'm
free to use all the Windows features. That's why I started translating
Windows API to Ruby. I do not wish a new API to windows, threads  etc,
but I'd like to access the Windows' functions as they were inteded to be
accessed. It's not a good idea to use an additional layer to access
Windows API. 

Can anybody tell why my module built for mswin Ruby does not work with
cygwin installation? Or it should work?
The module provides access to some Windows API fnctions.